Agent authorization decides whether one specific proposed action may run. It answers a question about an action: may this operation, on this resource, with these arguments, happen right now. That is a different question from whether the agent may open a connection, and a different question again from who the agent is. An agent can be correctly authenticated, correctly connected, and still be proposing something nobody agreed to.
What does agent authorization actually decide?
Three questions sit behind every action an agent takes, and they are usually answered by three different systems.
- Who is this? Authentication. A credential or a certificate proves the caller is the identity it claims.
- May it connect to that? Access control. The identity is entitled to reach the resource, at some level of privilege.
- May this action run? Authorization of the action itself. This one depends on the operation, the target, the arguments, the state of the world and the rules in force, and it has to be answered per request.
Most infrastructure answers the first two and treats the third as implied. For a deterministic client that is defensible: the client only ever issues the calls its code contains. An agent driven by a language model has no such bounded request set. It composes the call at runtime from text it read, so the set of actions it might propose is open, and a decision that was implied by the code no longer exists anywhere.
How is this different from authentication and access control?
Authorization is a decision. A credential is a means. The two are confused because holding the means usually settles the decision: a bearer token is defined so that "any party in possession of a bearer token (a 'bearer') can use it" (RFC 6750, section 1.2). Once an agent holds one, the decision has already been made, in advance, for every call the token covers.
Zero trust architecture separates the two explicitly. A policy decision point evaluates the request; a policy enforcement point sits on the path and lets nothing through that the decision point has not approved (NIST SP 800-207, section 3). The same split appears in attribute based access control, where the decision is computed at request time from attributes of the subject, the object and the environment rather than from a list written earlier (NIST SP 800-162).
Saltzer and Schroeder named the property this depends on in 1975: complete mediation, meaning every access to every object is checked for authority, with no cached "yes" that later requests reuse (Saltzer and Schroeder, section I.A). An agent with a long-lived key in its environment is a cached yes.
Why does an agent need this when a service account did not?
Because the agent is the component whose behaviour is decided by input you do not control. MITRE ATLAS catalogues tool invocation by an AI agent as an adversary technique in its own right: the attacker does not need new access, only to steer the agent into calling a tool it already has (AML.T0053). OWASP files the same problem under excessive agency and names the cause as excessive functionality, permissions or autonomy granted to the model (LLM06:2025).
Neither is a bug in the model. Both are consequences of where authority sits. If the authority to act lives with the agent, then the agent's judgement is the control, and the agent's judgement is what an attacker writes on.
How does it work in practice?
A working agent authorization layer has five parts.
- A proposal. The agent states the action it wants: the operation, the target, the arguments. It states it as a request, not as a command.
- A decision point outside the agent. The rules live somewhere the agent cannot edit, and they are evaluated by something the agent does not run.
- Recomputed inputs. The values the decision turns on, such as how sensitive the target is or whether the operation can be undone, are looked up on the deciding side. A decision that reads its own risk rating out of the request is being graded by the caller.
- Enforcement at the point of effect. The check sits where the credential is used, not in the caller. A check the caller performs is advice.
- Refusal as the default. An action no rule covers is refused rather than graded downward. Deny by default is the standard posture for access enforcement (NIST SP 800-53 Rev. 5, AC-3 and AC-6).
Where does agent authorization fail?
- The check runs in the agent. A compromised or misled agent skips it. The enforcement point has to be downstream of the thing being constrained.
- The decision trusts the request. If the caller supplies the risk class, the resource owner or the "already approved" flag, the caller decides.
- Policy has a gap and the gap is permissive. Unknown resources and unknown operations are the ones an attacker reaches for first.
- The credential is still in the agent. Then authorization is optional: the agent can call the API directly and the decision layer never sees it. This is the failure that makes the other four moot, and it is covered in AI agent credentials.
- The decision is not recorded. An authorization nobody can reconstruct is indistinguishable from no authorization, after the fact. See the AI agent audit trail.
- Time of check, time of use. The world changes between the decision and the action. Long holds need a recheck at execution, not only at grading.
Authorization also does not make the agent right. It bounds what a wrong agent can cause. That bound is the subject of containing a successful injection.
How does ZIFFER decide whether an action may run?
ZIFFER grades every proposed action against a policy bundle you signed, and answers one of three ways: granted, held for a quorum of two named humans, or refused. The decision values are recomputed from that signed policy rather than read from the proposal, an unknown resource is treated as the highest tier, an action with no risk function is refused, and the answer is carried in a signed receipt your own executor verifies before it acts with your credential. The objects and their exact definitions are in the concepts page, including what a grant is not: it is not an execution, and nothing in the decision layer performs the action. Dual authorization for the held case is covered in dual authorization for AI agents.