AI coding agents now write files, install packages, fetch remote resources, and run shell commands on their own. We kept watching teams adopt them faster than their security controls could keep up, and the gap kept showing up in the same place: the moment an agent turns a plan into an action.
That is why we built Prismor. The open source runtime ships as immunity-agent, lives on the developer’s machine, and watches the tool-call boundary in real time. When an agent tries to run a destructive command, install a poisoned package, expose a secret, or follow a hostile MCP instruction, Prismor can stop the action before it lands.
Why we built it
We tried scanner-shaped approaches first. They were useful, then they ran out of road. A scanner can tell you that a package is risky, that an MCP server looks strange, or that a config file holds a secret. Those are real findings. They still arrive before or after the moment that matters.
Agents move inside the session. They decide, they call tools, and they chain one action into the next without waiting for a human checkpoint. By the time a traditional control notices that rm -rf ran, that a publish token left the machine, or that a poisoned install script executed, the agent already got what it wanted. We wanted a control that sits where the decision becomes execution.
That boundary turned out to be the right one. It is specific enough to catch real damage, early enough to stop it, and close enough to the developer that we could keep the whole system local-first. That last part mattered. Security teams need evidence. Developers need to know their code and secrets are not being piped to somebody else’s cloud.
How Prismor works
Prismor installs lightweight hooks into the agent workflow and evaluates every tool call before it executes. Shell commands, file writes, package installs, MCP interactions, network egress, and secret handling all pass through the same decision point. The runtime can observe, warn, or block based on policy.
On a single machine, that means you can install immunity-agent and get useful protection immediately. For teams, prismor-web adds the control plane around it: device enrollment, signed policy distribution, redacted telemetry, exemptions, and org-wide visibility into what agents are doing across managed repositories.
The design constraint from the start was trust. Policies are signed. The runtime verifies them before applying them. Local protection keeps working if the control plane is unavailable. Telemetry can be redacted at the source. A fresh install stays useful even if you never enroll a device. Those choices make the system easier to adopt because they respect the environment it is trying to protect.
We also wanted one runtime to cover the whole surface. Teams do not need another pile of point products for prompt injection, secret cloaking, supply-chain checks, MCP vetting, and audit trails. The agent sees one workflow. Security should too.
What it protects
Prismor was built for the failures we kept seeing in real agent workflows, the quiet ones that start as convenience and turn into blast radius.
- Destructive tool use. Commands that wipe files, rewrite permissions, force pushes, or alter system state can be stopped before execution.
- Secret exposure. Prismor can cloak sensitive values before they reach the model, the shell, or logs that hang around longer than anyone expects.
- Supply-chain abuse. Package installs, postinstall hooks, and suspicious dependency behavior can be inspected while the agent is still trying to pull them in.
- MCP and prompt injection risk. Untrusted tool descriptions, hostile server instructions, and poisoned resources can be caught at the point where the agent tries to act on them.
- Policy drift across a team. Signed policy, scoped exemptions, and enrolled devices give security teams a way to standardize what safe agent behavior looks like without turning every laptop into a support ticket.
What teams should do
If your team is already building with AI coding agents, the right move is to put a control at the action layer now. Start small and make it real:
- Install the runtime locally. Start with
pip install immunity-agentand runimmunity setupto hook it into the agents your team already uses. - Begin in observe mode. Watch what your agents actually do before you tighten policy. Most teams learn something useful in the first session.
- Turn on enforcement for the obvious high-risk actions. Destructive shell patterns, secret exfiltration paths, unsafe installs, and untrusted remote execution paths should not wait for a postmortem.
- Enroll devices when the team grows. Use the control plane for signed policy rollout, redacted telemetry, and device-level visibility once agent usage spreads past a couple of laptops.
- Treat MCP and agent tooling like supply chain. Review what gets installed, what gets permission to execute, and what the agent is allowed to trust by default.
The larger shift here is simple: AI coding agents changed where security has to sit. The useful control point is no longer the code after it lands or the endpoint after the action fires. It is the moment an agent reaches for a tool. Teams that secure that moment will ship faster with fewer surprises. Teams that skip it will keep learning about agent risk from the cleanup.