Authorisation Policy
Deciding What an Agent May Do
Agentic Zero Trust says every action must be authorised independently of the model. Authorisation policy is the thing that actually renders that decision: a rule set evaluated outside the model, against a request the model produced but does not control. If the policy lives in the system prompt then it has the reliability of the model's instruction-following, which is precisely the property under attack.
Where the Decision Lives
The classic separation holds for agents, and separating these four roles is what makes policy auditable and unbypassable rather than a function buried in a tool wrapper.
Sits in the call path of every tool, so nothing executes without passing through it. It asks the decision point and obeys the answer, holding no policy logic of its own.
For agents: It must wrap the tool layer, not the agent loop. An agent that can call a tool directly has routed around enforcement entirely.
Takes a request plus context and returns permit or deny with a reason. Deterministic, side-effect free, and independently testable.
For agents: Must be reachable in single-digit milliseconds, because it runs on every tool call in a loop rather than once per user request.
Supplies the attributes a decision needs but the request does not carry: group membership, resource ownership, budget consumed, prior actions this session.
For agents: Session history is the attribute agents need most and conventional systems never provide, because no other client accumulates state the way a loop does.
The interface for writing, reviewing and versioning rules. Separated from the runtime so a change is a reviewable artefact rather than a live edit.
For agents: Nothing the agent can reach may write here. A policy the agent can edit is a suggestion.
Policy Models
Agents strain the older models because their action set is open-ended and their requests carry no fixed shape. What expresses cleanly for a web application often does not survive an agent inventing a new combination of tool and argument.
| Model | Expresses Well | Strain Under Agents | Fit |
|---|---|---|---|
| Static allowlist | Small fixed tool sets where the answer never depends on context | Says nothing about arguments, so one permitted tool covers every use of it | Starting point |
| RBAC | Coarse separation by job function, easily understood and audited | The agent has one role for a session spanning many contexts, so the role is always too broad | Insufficient alone |
| ABAC | Decisions over attributes of the actor, resource and environment together | Expressive enough to become unreadable, and unreadable policy is unreviewable policy | Good |
| ReBAC | Questions of the form "may this user reach this document through some relationship" | Graph traversal on the hot path of a loop needs care to stay fast | Good for data access |
| Capability tokens | Authority carried with the request, narrowed at each delegation hop | Revocation is hard once a token is issued, so lifetimes must be short | Strong for delegation |
What the Decision Has to See
A conventional authorisation check answers "may this principal do this to that resource". An agent needs three more inputs, and omitting them is what makes a technically correct policy useless in practice.
Both identities: the agent making the call and the user it acts for. Authorisation is the intersection of the two, never the union.
Missing it allows: The agent acting with the full authority of whoever started the session.
The operation and its target, resolved to concrete identifiers rather than the free-text the model produced.
Missing it allows: Policy matching on a tool name while the damaging detail sits in an unexamined argument.
What this agent has already done in this run. Each of a hundred small reads may be permitted while the hundred together are an exfiltration.
Missing it allows: Sequences that no individual check would ever refuse.
Where the instruction originated. A request traceable to a user message is different from one traceable to a fetched web page, even when it is byte-identical.
Missing it allows: Indirect prompt injection reaching exactly the same permissions the user has.
Spend, call count and time consumed so far. Agents fail by repeating a permitted action far more often than by performing a forbidden one.
Missing it allows: A correct action, executed ten thousand times.
Whether the action can be undone. A property of the operation rather than the requester, and the strongest signal for when to require a human.
Missing it allows: Irreversible actions treated with exactly the same care as a read.
Writing and Testing Policy
Policy is code that decides whether other code runs, so it deserves the same treatment as code: reviewed, versioned, tested, and rolled out gradually.
| Practice | What It Means | Skipping It Costs |
|---|---|---|
| Policy as code | Rules in a declarative language such as Cedar or Rego, in version control, reviewed like any change | Rules that live only in a running system and cannot be diffed or rolled back |
| Unit tests on policy | Fixtures asserting permit and deny for representative requests, run in CI | Discovering a rule was wrong from an incident rather than from a test |
| Default deny | Unknown actions and unknown tools are refused rather than passed through | Every newly added tool silently authorised until someone remembers to restrict it |
| Shadow evaluation | Run new policy alongside the old, log the disagreements, do not enforce yet | Learning the blast radius of a policy change from production traffic |
| Versioned decisions | Every decision records the policy version that produced it | Being unable to explain after the fact why something was allowed |
| Denial telemetry | Denials monitored as a signal, not discarded as noise | Missing both an agent probing its limits and a policy blocking legitimate work |
Failure Modes
Constraints written as instructions to the model rather than evaluated outside it. The policy then holds exactly as well as the model resists persuasion, which is the thing being attacked.
Fix: Move the rule to the enforcement point. Keep the prompt statement as a usability affordance so the agent knows why it was refused, never as the control.
A rule broadened during an incident, or written broadly to stop a stream of false denials, and never narrowed again. The commonest way a working policy becomes decorative.
Fix: Expiry dates on broad grants. Review anything matching a wildcard on a schedule, and alarm on rules that authorise unusually large shares of traffic.
The decision point times out or errors and the enforcement point permits the action so the product keeps working. Availability is preserved by removing the control entirely.
Fix: Fail closed with a clear error. If some path genuinely cannot, restrict that path to a minimal set of reversible actions.
Policy authorises the tool but never inspects what it is being called with, so a permitted read tool is pointed at a path it should never see.
Fix: Authorise the resolved action and its arguments, after parsing and canonicalising, not the tool name.
A tool or MCP server is added and no rule mentions it. Under default-allow it is fully authorised the moment it appears.
Fix: Default deny on unknown actions, and make adding a tool require a policy change in the same review.
A decision costing a hundred milliseconds is invisible on a web request and ruinous inside a loop making hundreds of calls, so someone eventually caches or skips it.
Fix: Keep evaluation local and in-process where possible. Cache decisions on immutable attributes only, never on session state.
Where This Sits
Policy decides whether an action is permitted. Sandboxing and Isolation bounds what a permitted action can reach, and the two are independent: a correct decision on an over-privileged sandbox still ends badly. Agentic Zero Trust supplies the identity and delegation model the decision reads from. Code Execution is the hardest case, because generated code is a single permitted action that can attempt anything. Steering is the softer sibling: policy refuses an action outright, steering redirects the agent before it asks. AIUC-1 covers evidencing all of it under certification.