Configuring Prismor OSS has meant setting six independent policy axes. Enforcement fallback, egress allowlist, tool access, tag rules, sandbox ring, and step-up gates each live in a different place. Each carries its own default. A developer who wants nothing more than a posture that is safe for daily work has to assemble it by hand from settings.default_mode, settings.egress, settings.tool_tags, settings.sandbox, per-rule overlays, and an agents.yaml tool list.
That is six chances to get something wrong, and the failure is quiet. A policy that looks configured but leaves egress.default: allow reads like one that does not. So Prismor OSS now ships three named modes: dev-safe, trusted-workspace, and regulated-airgap. You pick one at install time, and each one states what it trades away.
The cost of a flexible policy engine
Flexibility is why a policy engine is worth running. It is also why teams stall before they finish configuring one. Every axis a security tool exposes is a decision handed to somebody who was trying to do a different job, and the person holding it is a developer three tickets deep on a Tuesday afternoon.
Power users want those axes and should keep them. The rest of us want a default that somebody already thought about. prismor setup covered one axis of the six, which rules block, and left the rest to be discovered. There was no way to ask for a whole posture, and no way to compare postures before adopting one.
The three modes
Each mode compiles down into the primitives the engine already reads, so this stays a configuration-layer feature and the enforcement path is untouched. Five self-protection rules stay on in every mode, which means a mode can never become cover for switching Prismor off.
- dev-safe. Assumes the repository may be hostile. Known destinations only, and read-only commands do not prompt. Built for open source contribution and PR review, where the agent is reading code nobody on your team has read yet.
- trusted-workspace. Assumes the repository is trusted, so the agent gets broad autonomy inside it. Hard stops stay on secret reads and package installs. Built for internal repositories and microservices.
- regulated-airgap. Assumes nothing is trusted. No network, no shell, and every write goes through approval. Built for regulated data and review-only workflows.
| Mode | Assumes | Coverage | Friction | Needs Docker |
|---|---|---|---|---|
| dev-safe | repo may be hostile | 31% (25/80) | 9% | Yes |
| trusted-workspace | repo is trusted | 34% (27/80) | 9% | No |
| regulated-airgap | nothing is trusted | 100% (80/80) | 90% | No |
That table is the summary. The full axis-by-axis defaults, egress allowlists included, are in the Prismor OSS docs alongside the rest of the CLI reference.
Why the friction numbers land where they do
Coverage and friction are both computed rather than asserted. Coverage comes from the live ruleset. Friction comes from running a corpus of ordinary developer commands through each compiled mode and counting what gets interrupted.
The two everyday modes both measure 9%. regulated-airgap measures 90%. That gap looks severe until you look at where agents spend their tool calls.
Shell and command execution is roughly three quarters of everything an agent does. The other four categories split the remaining quarter between them. That single fact sets the friction budget for any policy you can write.
A mode that touches the shell category is spending most of the budget it has. regulated-airgap denies Bash outright, so its 90% is close to arithmetic. The two everyday modes keep the shell and auto-approve read-only commands and non-mutating git, which is how they hold 25 blocking rules and still land at 9%. One caveat on that number. The friction index measures shell interruption and nothing else today, which is why the two everyday modes score the same. The axes where they differ, secret reads and sandbox confinement, are not in the corpus yet.
What each mode does not stop
Every mode ships with its residual risk. Prismor OSS prints it straight from prismor mode explain, the same command it runs at install time. This is the reason the feature exists rather than a disclaimer bolted onto it. A posture whose holes you cannot describe is a posture you cannot reason about.
- dev-safe does not stop exfiltration through the channels it allows, and that list is wide.
api.github.comis allowlisted by design, so a secret can still reach a public issue comment. It is a control on arbitrary destinations, and it says so. - trusted-workspace does not stop the code it lets the agent execute. A malicious build script in
setup.pyor an npmpreinstallhook runs with the agent’s full reach. No destination allowlist sees that happen. - regulated-airgap does not stop its own friction. The realistic failure is somebody running
prismor uninstall-hooksto get through an afternoon. Poisoned repository context needs no network either, so local logic manipulation survives the airgap.
One limit applies to all three. Keeping a secret out of the model’s context is a different job from keeping it out of a tool call, and it needs per-secret enrollment through prismor cloak add. No mode can do that for you.
What teams should do
A mode is a starting posture. Adopt one, then tighten it once you can see what your agents do.
- Pick a mode at install time. Match it to how much you trust the repository in front of you, which is a question people can answer without reading six config files.
- Start in observe.
prismor mode apply dev-safe --observecompiles the same posture with nothing blocking, so you get a week of evidence before anything interrupts a developer. - Read the residual risk before adopting.
prismor mode explainnames the gaps. If a listed gap is the one your threat model cares about, that mode is the wrong starting point. - Check the runtime for dev-safe. Its sandbox enforces, so it needs Docker. Without a runtime the apply refuses rather than degrading into a weaker posture nobody would notice.
- Re-check for drift.
prismor mode showreports the active mode and how far the file has moved from it.
Any control with six independent axes has a configuration surface, and a configuration surface is somewhere a policy can be wrong while looking right. Named postures that publish their own trade-offs turn that surface into something you can audit in one command, which is the whole bet behind shipping this as part of Prismor OSS. So here is the question worth putting to any agent control plane you are weighing up: can it tell you, right now, what it is letting through?
