R-01 · allow-list
What this agent may call at all
A named set of tools. Anything absent from it is not permitted, by omission rather than by an explicit refusal.
allowcrm.contact.read
Policy is data, not a prompt.
Allow-lists, deny rules and thresholds, bound to one agent and versioned. A deterministic engine reads them and records which rule decided. The point is not that it is clever - the point is that it is reproducible.
formallow-lists, deny rules, thresholds
bound toone agent
versionedimmutable policy_version
evaluated bya deterministic engine, server-side
model involvednone
A security control you can reason about.
The same question gets the same answer
The same request against the same policy version produces the same decision, every time. A control that can be talked into a different answer is not a control, and one you cannot reproduce afterwards is not evidence.
Policy is separate from enforcement
The decision engine reads policy; nothing in a request can soften what it says. There is no risk parameter in the evaluate request - the engine computes risk_score itself.
No binding is not permission
An agent with no applicable policy binding does not fall through to allow. The absence of a rule is not a rule that permits.
It is not a language you extend
Policies are data evaluated by the shipped engine, not a sandbox that runs code you supply. That is a smaller surface on purpose.
Three kinds of rule.
Everything a policy can say is one of these three, which is what keeps the evaluation order small enough to hold in your head.
R-02 · deny rule
A refusal that outranks the list
Evaluated before the allow-list, so a tool can be generally permitted and still refused for a specific shape of call.
blockbulk_export where record_count > 1000
R-03 · threshold
A boundary on a computed value
Risk score, amount, record count. Crossing it sends the call to a human instead of resolving it either way.
holdrefund_amount > 5000
01 trust gate lifecycle, containment stops here if contained
02 resolve policy bound to this agent, at its current version
03 deny rules a match ends the evaluation
04 allow-list absent from it is not permitted
05 risk + threshold over the threshold holds the call
06 decide allow · block · approval_required
Two fields matter more than they look.
policy_idStable identifier of the policy that decided.
policy_versionImmutable. This is the one to log.
matched_policyA display name. It can be edited afterwards.
matched_ruleThe specific rule that produced the answer.
decision_sourcetrust_gate · policy_deny_rule · policy_allow_list · risk_threshold
Log both, and the argument is over
Six months later somebody asks why an agent was allowed to do something. With policy_id and policy_version on the record you can point at the exact policy content that was enforced. With only the display name you can point at whatever it has since been renamed to.
decision_source is what separates “policy refused this” from “the agent was contained and policy was never reached”. During an incident that distinction is the whole answer.
What the policy engine is not.
It is not a model. No LLM participates in the authorization decision, and no prompt can change one.
It is not a policy language runtime you extend. Policies are data evaluated by the shipped engine.
It does not take risk from the caller. There is no risk field in the request. The engine computes the score.
It does not fall through to allow. No applicable binding is a refusal, not a default permission.
Private access
Bring the action you are worried about.
We will write the policy for it in front of you and show you what the decision records.