Prismor: four ways to get in front of an agent's tool calls

Two commands install it, and the runtime pulls two dependencies

The quick start is sized in seconds and takes two commands:

pip install prismor
prismor setup

Everything else is pointed at a separate installation guide, which also covers onboarding through a Skill, curl and git clone, systems that need PEP 668 externally-managed-environment handling, and secret-cloaking setup. The dependency picture is unusually small for a security control plane. The project metadata declares Python 3.8 or newer and lists exactly two runtime requirements, PyYAML, and tomli but only on interpreters below 3.11, and the plain requirements file is reduced to PyYAML alone. Everything else is an optional group: a development group, a signing group pulling cryptography, a semantic group pulling litellm, and one group per supported framework. The readme used for the package index is also a separate file, PYPI.md, distinct from the repository README.

The LLM proxy covers agents that cannot be hooked

Most of the enforcement mechanisms assume the agent exposes a hook. This one does not, and it is the most interesting design decision in the project. Instead of instrumenting the agent, you point the agent at `prismor proxy` using `ANTHROPIC_BASE_URL`, `OPENAI_BASE_URL`, or the Google Gen AI SDK's `HttpOptions(base_url=...)`, and the claim is that nothing else about the agent changes. The mechanism is normalisation: every tool call the model proposes, whether it arrives as Anthropic's `tool_use`, OpenAI's `tool_calls` or Gemini's `functionCall`, is reshaped into the same event that a Bash hook would produce, and is then judged by the same rule. The awkward case is handled explicitly, since streamed calls are held until they can be judged rather than passed through unexamined. That means an agent you could not modify at all still gets policy evaluation, at the cost of intercepting its model traffic.

The MCP gateway fronts every other MCP server you use

The gateway is a single connector that sits in front of all the rest. Each `tools/call` is policy-evaluated before it is forwarded, and each response is injection-scanned before the model sees it, with the stated purpose being that a poisoned tool result never becomes context. That second half matters as much as the first, because tool output is one of the easiest ways to get instructions into an agent's context after the fact. Migration is a single command, `prismor mcp-gateway install`, which moves an existing `.mcp.json` behind it. Alongside the gateway sit the MCP guardrails, which let you block a specific MCP server or a specific tool, or require human approval before the agent calls it, with the rule written by you rather than chosen from a preset list.

The inference hook moves the decision off the user device

This mechanism is positioned as making Prismor the security server behind Claude Enterprise. The flow is that Anthropic sends every governed prompt, from claude.ai, Claude Code and Cowork, to `prismor inference-hook serve`, which runs your policy against the transcript and answers allow or deny before the model runs. Three properties are stated and each one is a design decision worth noting: the requests are signed using Standard Webhooks, the service is fail-closed, and there is a shadow mode. The claim attached to shadow mode is that nothing needs to be installed on user devices, which is the practical point of doing enforcement server-side rather than locally. A companion command, `prismor inference-hook test`, sends signed sample frames so you can confirm the wiring before trusting it.

Prompt guardrails are plain-language rules in the agent's context

Not every control is a block. Prompt guardrails add plain-language rules to the agent's own context, with the example given being never push to main. They are set per agent in the console and tuned per session, and the behaviour is specified usefully: a running session picks up an edit on its next prompt, so a rule change does not require restarting the session. The rest of the capability list is split by layer. Supply chain covers install-time enforcement, indicator-of-compromise matching and risk scoring. Network isolation covers policy-driven egress control, detection of raw IP access, and tunnel blocking. The skill scanner looks at MCP servers and skills for risk across the supported agents. And tool tags classify tools by capability, which is the primitive the other rules would be written against, although the capabilities list in the documentation is cut off mid-word.

Coverage is claimed per agent and per framework, in two separate files

The agent list is long and split across two places. Eleven are shown as logos on the front page, Claude Code, Codex, Gemini CLI, Cursor, GitHub Copilot, OpenCode, pi, Kiro, Kimi Code, Trae and Google Antigravity. A longer tail is listed in text: Grok Build, Crush, OpenHands, Qwen Code, Continue CLI, Goose, Hermes, OpenClaw, Devin CLI, Factory Droid and Aider, with AGENT_INTEGRATIONS.md named as the full coverage matrix. A separate file, LLM_FRAMEWORK_COVERAGE.md, covers frameworks rather than harnesses. The packaging reflects the same split: framework adapters ship inside the package under a per-framework namespace, and the extras exist only to pull the framework itself, which is what makes installing the LangChain, CrewAI, OpenAI agents or browser-use integration a one-liner rather than a fork.

Telemetry receipts are signed, with a keyless fallback

Two optional dependencies exist for reasons that are worth reading in the metadata rather than guessing at. The signing extra pulls cryptography and is described as providing Ed25519 receipt signing for enrolled devices, with the receipts characterised as tamper-evident and non-repudiable telemetry receipts. Without the extra, telemetry falls back to what is called a keyless hash chain, which is a weaker property, so the distinction matters if you are collecting records as evidence. The semantic extra pulls litellm and provides the LLM layer of the semantic prompt-injection guard, specifically on hosts that do not have the Claude Code CLI available, routing to whichever provider litellm can reach. Both extras are opt-in, which keeps the default install small at the cost of two features being off until you ask for them.

A committed .pth file and a keys/ directory sit in the root

The tree is worth a look before you install anything. Alongside the expected directories, `prismor/`, `adapters/`, `docs/`, `tests/`, `examples/`, `scripts/`, `bin/` and `packaging/`, there are `advisories/`, `grafana/`, `pipeline/`, `research/`, `templates/`, a `keys/` directory, and a file named `immunity-agent.pth` at the top level. A .pth file is Python source that the interpreter executes during site initialisation, and a directory called keys at the root of a security project is the first thing a reviewer should ask about in either case. The governance paperwork is thorough by comparison, with AGENTS.md, CLAUDE.md, CODE_OF_CONDUCT.md, GOVERNANCE.md, SECURITY.md, USE_CASES.md, a TODO file, a benchmark file and per-agent configuration directories for three tools. One packaging oddity is worth noting: the JavaScript manifest in the same tree carries version 1.13.0 while the release stream is at 1.57.0.

Editorial conclusion

Prismor fits a team running autonomous coding agents with credentials on the machine, where the exposure it names, an agent reading an environment file during a debugging task and sending it outbound, is a real problem rather than a theoretical one. It fits badly as a single drop-in, because the four attachment points are four separate integrations and an agent is only covered by the ones its framework supports. Three things to check before relying on it. Start in observe or shadow mode rather than enforcing, since the same rules are what you will later use to block. Establish which agents your setup actually hits, because coverage is asserted per agent in a separate integrations matrix and per framework in a separate coverage file, and the repository also commits a top-level .pth file and a keys/ directory, which in a security tool is the first thing to ask about. And note that the packaging is deliberately thin, with two runtime dependencies, so what you are trusting is mostly Prismor's own code rather than a dependency tree. Apache-2.0 licensed, the release stream is at 1.57.0, last pushed on 1 October 2026.

Frequently asked questions

Official sources

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