How is this different from OAuth scopes or RBAC?

Scopes and roles authorize access: which tools and data an agent may reach. Action authorization evaluates content: whether this specific message or transaction complies with commercial policy. An agent with perfect scopes can still compose an email the business must not send.

What does authorization do to latency?

Deterministic checks run in milliseconds. The semantic stage adds one model call, typically one to two seconds. For email, quotes, and tickets that is invisible. For tighter loops, run the deterministic stage inline and reserve the semantic pass for consequential actions.

Can the agent just retry until something passes?

Yes, and that is the designed behavior. A blocked agent gets the violation list, adjusts, and proposes a compliant action. The point is not to punish the agent; it is that nothing non-compliant can reach the customer, however many attempts that takes.

Who writes the policy?

The business, not the model team. Discount caps, spend authority, and forbidden commitments are commercial decisions. The healthiest pattern treats the policy like a pricing page: owned by the business, versioned, and reviewed whenever the business changes.

AI agent authorization: gating actions before they ship

Published 2026-07-27 · EvalLayer

AI agent authorization is the runtime check that decides whether an action an AI agent is about to take (a quote, a discount, a commitment, a public claim) is allowed to execute. The action and a policy go in; one of four decisions comes out: allow, rewrite, require_approval, or block, with the specific violations attached. It is the difference between hoping the agent stays inside its authority and knowing that nothing outside its authority can ship.

Two meanings of authorization

In classical security, authorization is the second half of authN/authZ: authentication proves who you are, authorization decides what you may access. OAuth scopes, RBAC roles, ACLs. Applied to agents, that meaning covers which tools an agent may call and which data it may read, and a growing set of identity vendors handles it well.

Agent authorization in the runtime sense is a different question. Not "may this agent use the email tool" but "may this agent send this email, containing this discount, to this customer, under this policy, right now." Access authorization is evaluated against an identity. Action authorization is evaluated against content. An agent can hold every scope it needs and still compose a message the business must not send, which is why the second meaning exists and why passing the first check says nothing about the second. This article is about the second meaning.

The runtime meaning is being standardized as we write. The Cloud Security Alliance's AARM specification frames action security at runtime across context, policy, intent, and behavior, and the March 2026 study Before the Tool Call measured what happens in the absence of a standard layer: 27.2% of engineering teams surveyed had given up on framework-provided authorization and hardcoded their own checks at the tool-call boundary.

The four-decision ladder

Every authorization request resolves to one of four decisions, ordered by escalating friction.

allow

No violations. The action ships untouched, with a record that it was checked. In a healthy deployment this is the overwhelming majority of traffic, and it costs milliseconds, which is what makes checking every consequential action affordable in the first place.

rewrite

Soft violations: a missing required disclaimer, an off-policy phrasing of an approved claim, a drift toward a blocked area that has a compliant equivalent. The layer returns an approved_rewrite, a minimally edited version that fixes what it flags. Critically, the rewrite is re-checked before it is offered; a fix that introduces a new violation never reaches the caller. The platform can auto-substitute the rewrite or surface it to the agent as a correction.

require_approval

Authority violations: the action exceeds what the agent may do alone, but a human could legitimately approve it. A 22% discount against a 15% cap. A 7,500 dollar commitment against a 5,000 dollar authority. The action parks, a human sees the violation list and the context, and their yes or no becomes part of the record. This is human-in-the-loop with routing: humans review the small fraction that needs judgment instead of sampling the mass that does not. More on the pattern in human-in-the-loop AI agents.

block

Hard violations: forbidden commitment types, blocked topics, claims that are false on their face. Nothing ships and nobody in the flow can waive it. The agent gets the violation list and can try a different approach; the customer never sees the attempt.

Anatomy of a policy

The policy is the contract between a business and its agent, and it is deliberately small. A real one looks like this:

{
  "max_discount_pct": 15,
  "commitment_authority_usd": 5000,
  "forbidden_commitments": [
    "delivery date guarantees",
    "refund promises",
    "indemnification"
  ],
  "approved_claims": [
    "SOC 2 Type II certified",
    "24/7 support response"
  ],
  "required_disclaimers": [
    "Quotes are valid for 30 days"
  ],
  "blocked_topics": [
    "competitor pricing",
    "legal advice"
  ]
}

Six fields cover most commercial exposure: how much discount the agent can give, how many dollars it can commit, what it must never promise, what it may claim, what it must always say, and what it must not discuss. If a rule matters, it should be one of these fields rather than a paragraph of prose in a system prompt, because fields are checkable and prose is arguable.

The wire format matches the mental model. The request is a single call, POST /authorize, carrying the action content and the policy; the response carries the decision, a violations array with severities, and the approved_rewrite when one applies. If your policy cannot be serialized into a request like this, what you have is guidance, not policy.

The two-stage checking architecture

Checking splits into two stages because the two failure classes are different in kind.

Stage one is deterministic. Discount percentages are parsed and compared against max_discount_pct. Dollar amounts are extracted and compared against commitment_authority_usd. Required disclaimers are matched for literal presence. This stage is code: exact, instant, effectively free, and immune to persuasion. A large share of real violations are caught here without any model involvement.

Stage two is one AI pass for semantics. Whether a sentence constitutes a delivery guarantee, whether a claim is a paraphrase of an approved claim or a new invention, whether a paragraph has wandered into a blocked topic: these are judgment calls, and a single model call with the policy in context makes them. The pass is independent of the agent being checked. It sees the action and the policy, not the customer conversation, so the social engineering that bent the agent has no channel to the checker.

Violations from both stages merge, each carrying a severity, and severity drives the ladder: hard violations block, authority violations require approval, soft violations trigger the re-checked rewrite. One deterministic sweep plus one model pass is also what keeps the economics workable: from $0.01 per check, cheap enough to run on every consequential action rather than a sample.

The audit record

Every decision is stored: a hash of the content that was checked, the policy that applied, the violations found with their severities, the decision returned, and the human approval if one happened. This is not logging for debugging. It is evidence. When a customer claims the agent promised something, the record shows what was checked and what shipped. When an enterprise security review asks what stops the agent from overcommitting, the answer is a decision trail, not a description of a system prompt. EvalLayer has processed 300+ evaluations in production and anchors verdict history on-chain, which makes the trail independently verifiable rather than a database the vendor could quietly edit. The full case for records is in the audit trail article.

require_approval vs block: drawing the line

The design question teams actually wrestle with is which violations park for a human and which die immediately. A working rule:

Use require_approval when a human could legitimately say yes. A discount above cap for a strategic renewal, a commitment above authority for an account worth the exception. The policy is a default, not a ceiling on the business itself, and approval is how the exception gets made with accountability attached.
Use block when nobody in the flow has the right to say yes. Regulated claims, commitment types the company has decided it never makes, blocked topics like legal advice. Routing these to a support lead for approval just moves the liability to whoever clicks fastest.

Get the line wrong in one direction and approvals become a queue that teaches everyone to rubber-stamp. Get it wrong in the other and the agent is blocked from deals the business wanted. The severity mapping is the real policy decision, and it deserves a named owner.

Seeing it run

The fastest way to understand the ladder is to watch it. The live demo checks a quote email with three planted violations against a sample policy and returns the decision, the violations, and the rewrite in a few seconds. For where authorization sits in the wider stack, start with what is AI agent assurance and the complete guardrails guide.