Infrastructure teams settled this argument years ago. Access rules stopped being a document and became a file: declarative, diffable, reviewed in a pull request, enforced automatically. Nobody wants to go back.
AI agents are where the same argument is being had again, usually badly. The rules governing what an agent may do tend to live in a prompt, a wiki page, or a shell script somebody wrote in an afternoon - none of which are enforceable and none of which survive review.
What makes a policy actually a policy
Prose in a system prompt is a suggestion to a model that may or may not follow it. A real policy has properties you can rely on:
- Declarative - it states what is allowed, not the procedure for checking. Rules match on the action: the tool, the command, the path, the class of data involved.
- Deterministic - the same action produces the same decision every time, with no model in the loop deciding whether to comply.
- Reviewable - it is a file. It diffs, it goes through a pull request, and tightening a rule leaves a commit with a name attached.
- Enforced at the boundary - evaluated at the moment the action is attempted, not audited weeks later.
- Accountable - every decision, allowed or blocked, produces a record.
Prismor policy, concretely
Prismor policies are declarative rules evaluated at the tool-call boundary. Each rule matches an action and resolves to allow, warn, or block, and rules are grouped into categories - destructive commands, secret exposure, network exfiltration, and so on - so you can tune a whole class of behavior at once instead of chasing individual patterns.
Beyond raw pattern matching, tools can be tagged by what they actually do, and rules can be written against those tags. A rule that says "anything that reads private data may not then talk to the internet" holds across every tool with those properties, including tools that did not exist when the rule was written. That is the difference between a deny list and a policy.
Warn exists because the honest first answer is often "we do not know yet". Start with warn, watch what your agents actually do, then promote the rules you are confident in to block.
Observe before you enforce
A policy written from imagination blocks the wrong things. Prismor runs in observe mode first, recording every tool call and the decision that would have been made without stopping any of it. You then write policy against what your agents genuinely do, and switch to enforce when the diff between the two is boring.
Enforcement mode is set per device, so you can move one machine or one team at a time instead of flipping a switch on the whole fleet and finding out what breaks.
One policy, every agent
The value compounds when the policy is not per tool. The same rules apply to coding agents, to agents you have built yourself through the SDKs, and to every MCP server your agents connect to, because they are all evaluated at the same boundary.
That means the answer to "what are our agents allowed to do" is a single file you can show someone, rather than an inventory of shell scripts and settings files spread across laptops.
A crowded field, one boundary
Agent governance is a noisy market, and most of the noise sits upstream of the moment an agent actually does something. Prismor works at the tool call, where the action lands and where a decision still changes the outcome.
Frequently asked questions
What is policy as code for AI agents?
Writing the rules that govern agent behavior as declarative, version-controlled configuration that is evaluated automatically when an agent tries to act, rather than as prose in a prompt or a document nobody enforces.
Why not just tell the agent what it may not do in the prompt?
A prompt is advisory. The model may ignore it, be talked out of it by injected content, or simply lose it in a long context. Policy is evaluated outside the model, so the decision does not depend on the model cooperating.
How is this different from OPA or similar policy engines?
The idea is the same; the boundary is different. Traditional policy engines answer requests between services. Agent policy is evaluated at the tool call, where the relevant facts are the command being run, the file being touched, and the data being exposed.
Can I start without blocking anything?
Yes, and you should. Observe mode records every action and the decision that would have applied, so you can write policy from real behavior before anything is enforced.
Want a control plane over your AI agents?
Prismor checks every tool call your agents make against your policy, blocks what breaks it, and keeps the audit trail. Run the open-source runtime yourself, or let us set it up across your org.
Or email [email protected]