Prismor: a runtime control plane that gates AI agent tool calls before they run

The gap Prismor targets: agents act, but nothing checks the action

Endpoint and OS security tools watch the kernel and the filesystem. Prismor's README argues they lack the context to judge an agent's intent, and that is the opening this project aims at. An agent that reads .env while debugging looks identical at the syscall level to an agent exfiltrating credentials. The difference is intent, and intent lives in the tool call, not the syscall.

Prismor therefore intercepts at the tool-call layer. The README lists the concrete failure classes it is built around: prompt injection from a file, issue or web page; irreversible destructive commands; secret exfiltration; privilege escalation through sudoers or CI config edits; dependency manipulation; and installing a vulnerable package while optimizing for velocity. It is aimed at engineers running coding agents against repositories they care about, and at teams who need a record of what an agent did and who approved it.

How the control plane sits between the agent and the tool

The repository ships an immunity-agent.pth file at the top level, plus adapters/ and a prismor/ package, and pyproject.toml notes that framework adapters ship inside the package as prismor.<framework>. That layout points to a two-part design: a Python-level interception layer that loads into the agent's process, and a policy engine that decides what happens to each call.

The README describes two operating modes, observe and enforce. In observe mode the agent runs normally and activity lands in a local dashboard. In enforce mode a call can be approved, blocked, or routed to a human in the loop. Policies are user-authored, and the README calls the system "highly customizable based on user's own policies." Alongside the policy engine there is a supply-chain component with install-time enforcement and IOC handling, and a semantic prompt-injection guard whose LLM layer can route to any provider through litellm when the Claude Code CLI is not present. Telemetry is described as a hash chain by default, upgraded to Ed25519 signed receipts on enrolled devices when the cryptography dependency is installed.

Agent coverage is broad by design. The README lists Claude Code, Codex, Gemini CLI, Cursor, GitHub Copilot, OpenCode, Pi Agent, Kiro, Kimi Code, Trae, Google Antigravity, plus Grok Build, Crush, OpenHands, Qwen Code, Continue CLI, Goose, Hermes, OpenClaw, Devin CLI, Factory Droid and Aider, with AGENT_INTEGRATIONS.md holding the full matrix. Treat that matrix as the thing to check, not the icon row.

Install and a first run: pip install prismor, then prismor setup

The README's quick start is two commands and claims a 30-second path. The first pulls the package from PyPI; the second runs the setup flow that wires Prismor into your agent harness.

pip install prismor
prismor setup

After setup, the README points to a local self-serve dashboard for agent activity. That dashboard is where observe-mode sessions and any human-in-the-loop approvals surface, so the first useful exercise is to run a normal agent task and watch which tool calls get recorded.

The README flags two situations that need the longer guide rather than the two-liner: PEP 668 systems, where pip refuses to install into a managed environment, and secret-cloaking setup. Both are covered in docs/installation.md, which also documents curl and git-clone alternatives to pip and a Skill-based onboarding path through SKILL.md.

Optional extras are declared in pyproject.toml. The base install pulls only pyyaml and tomli (the latter only below Python 3.11). The signing extra adds cryptography for Ed25519 receipt signing; the semantic extra adds litellm for the LLM layer of the prompt-injection guard on hosts without the Claude Code CLI. Framework extras such as langchain, crewai, openai-agents and browser-use exist so a single command pulls both Prismor and the framework.

pip install "prismor[signing]"
pip install "prismor[semantic]"
pip install "prismor[langchain]"

The project requires Python 3.8 or newer and classifies itself as Development Status 4 - Beta on POSIX and macOS. Windows is not in the classifier list, so plan accordingly.

Where Prismor is the wrong layer, and what it will not catch

Prismor gates tool calls. Anything that does not present as a tool call to a supported harness is outside its reach. An agent that talks to a third-party API over a connection your policy does not model, or one running in a container where the .pth hook never loads, produces no interception point.

The semantic prompt-injection guard has a documented dependency split. On hosts with the Claude Code CLI it uses that path; elsewhere it needs the semantic extra and litellm, which means an extra dependency and an external model provider in the loop. That is a real trade-off: you are adding a network call and a provider relationship to your security path, and the README does not describe what happens to the guard when the provider is unreachable.

The receipt story is similarly tiered. Without cryptography installed, telemetry is a keyless hash chain. A hash chain detects tampering but does not prove who produced the record. If your compliance argument depends on non-repudiation, the base install does not give it to you.

Finally, the project is in Beta and the release cadence is fast: v1.49.3, v1.50.0 and v1.51.0 all landed within a week of each other in September 2026. Fast iteration on a security control means your pinned version matters more than usual.

Prismor against a plain sandbox or container policy

The obvious alternative is not another agent-security product; it is the sandbox you already have. Docker, seccomp profiles, a restricted user account or a throwaway VM all constrain what an agent can do, and they do it below the agent's own process, so nothing in the agent can route around them.

The difference in approach is where the decision is made. A container policy decides at the syscall and namespace boundary, using rules that cannot read intent. Prismor decides at the tool-call boundary, where the payload is a structured command with arguments and the policy can reason about what the agent is trying to accomplish. That is why Prismor can offer human-in-the-loop approval for a single call and a dashboard of agent activity; a seccomp profile cannot ask a question.

The trade-off runs the other way too. A sandbox holds even if the agent is compromised, misconfigured, or running a harness Prismor has never heard of. Prismor's coverage is only as wide as AGENT_INTEGRATIONS.md, and its hook is Python-level, so a non-Python harness is a different problem. The honest reading is that these are complementary: the sandbox is the floor, Prismor is the policy layer that makes the floor usable without blocking every legitimate action.

Maintenance, upgrades and the Apache-2.0 terms

The repository is not archived, and the last push was on 2026-09-15, two days before this writing, with v1.51.0 released on 2026-09-14. That is an actively moving codebase, and it means the upgrade cost is real rather than theoretical. The CHANGELOG.md at the repository root is the file to read before bumping, and the three releases in the week before this writing suggest you should pin a version and move deliberately rather than tracking main.

The dependency surface is small by default, which keeps upgrades cheap: pyyaml, plus tomli on Python below 3.11. The extras are where cost accumulates. The semantic extra pulls litellm, the signing extra pulls cryptography, and each framework extra pulls the framework itself, so an environment with several adapters enabled has several independent upgrade tracks to reconcile.

On licensing: the package metadata and the LICENSE file both state Apache-2.0, and pyproject.toml declares license-files = ["LICENSE"]. Apache-2.0 permits commercial use and modification and includes an explicit patent grant, with the usual requirements around preserving notices and stating changes. This is a description of what the repository declares, not legal advice; if you are embedding Prismor in a distributed product, have your own counsel read the LICENSE file rather than this paragraph.

Editorial conclusion

Adopt Prismor if you run coding agents against real repositories and want a local, policy-driven checkpoint before shell commands, file writes or package installs execute; the Apache-2.0 licence and pip-only install keep the evaluation cost low. Skip it if you need a hosted fleet console with a vendor SLA, or if your agents never touch a shell or filesystem. Verify first that your specific harness appears in AGENT_INTEGRATIONS.md, that your Python version satisfies the >=3.8 floor in pyproject.toml, and whether you need the signing or semantic extras, since the base install ships only pyyaml and tomli.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. PrismorSec/prismor on GitHub
3. Project website
4. README
5. Releases