Authorization · architecture
Runtime Authorization for AI Agents
Authentication proves who is calling. Authorization proves what class of thing they may do. Neither answers the question an autonomous agent actually raises: may this specific action, with these values, happen right now.
The short answer
Runtime authorization is the evaluation of a fully specified action — identity, operation, parameter values, target and context — at the moment it is proposed, rather than a permission granted in advance. It is required for autonomous agents because the agent chooses its action at runtime from content that did not exist at grant time, so no static role can encode whether a particular call is acceptable. It sits alongside authentication and role-based authorization, not instead of them. Three questions, three layers, and a four-stage path from roles to per-action decisions.
Three questions, three layers
Access control for people answers two questions, and for decades that was enough because the third was answered by the person.
| Layer | Question | Decided when | Sufficient for |
|---|---|---|---|
| Authentication | Who is calling? | At session start | Establishing identity. Necessary, never sufficient. |
| Authorization (roles, scopes) | What class of operations may they perform? | At grant time, in advance | Systems where the operation set is known before the request exists. |
| Runtime authorization | May this exact action, with these values, against this target, proceed now? | At the moment of proposal | Autonomous systems, where the action is chosen from content that arrived at runtime. |
For a human user, the third question was answered by the human. A person with refund permission decides whether this refund is appropriate, using judgement, accountability and the knowledge that their name is attached. An agent has the permission and none of the rest, which is exactly the gap runtime authorization fills.
Why roles cannot stretch
The instinct is to model the agent as a user, give it a role and move on. It fails for three specific reasons, each of which shows up quickly.
Roles name operations, not magnitudes. A role permitting transfer permits every amount the tool accepts. The role cannot express that 500 is routine and 500,000 needs a director, because the role was granted before any amount existed.
Roles are static; agent context is not. The same operation is fine in staging and serious in production, fine for a customer in good standing and not for one in dispute, fine at the twelfth attempt and suspicious at the four hundredth. Roles have no place to put any of that.
Roles accumulate. Every capability an agent has ever needed stays attached, because removing one risks breaking something nobody has time to test. Human role sprawl takes years; agent role sprawl takes weeks, because agents get new tools continuously and nobody attends their leavers process.
None of this means abandoning roles. Roles are the right coarse filter and they are how you keep the runtime decision cheap — a role check refuses the obvious cases before any policy evaluation happens. They are just not the last word.
What a runtime decision needs
A runtime authorization decision sees things a grant-time decision cannot, and that is the entire value. Six inputs beyond identity and role.
Parameter values
The magnitude, the recipient, the row count, the date range. Where most of the real risk lives, and structurally invisible to role checks.
Target and jurisdiction
Which system, which region. The same operation against an EU instance and a US instance can be a different legal act.
Environment
Production or staging, with the same rule set and different thresholds. One rule set, parameterised — not two rule sets that drift.
Data classification present
Whether this payload contains PII or payment data. Frequently the deciding factor, and knowable only at call time.
Credential mode
Whether the call arrives on per-user OAuth or a pooled key. A legitimate reason to refuse an otherwise permitted action.
Recent behaviour
What this identity has done in the last minute. The eleventh identical write is a different act from the first, and no stateless check can tell them apart.
The last input is the one most implementations omit and the one that catches the most incidents — the policy engine covers how to hold it without making decisions non-deterministic.
Delegated authority, and its four bounds
When an agent acts for a person, it holds delegated authority. Human delegation is bounded by convention, professional judgement and the awkwardness of exceeding a mandate; none of those apply to software, so the bounds have to be explicit.
Four bounds, and all four need stating — an unbounded dimension is where the surprise arrives.
Scope
Which operations, against which systems. Narrower than the delegating human’s own authority, always. An agent acting for a finance director should not inherit a finance director’s full reach because it was convenient.
Magnitude
How much, how many, how far. The bound roles cannot express and the one that turns a permitted tool into an acceptable call.
Duration
Delegation with no expiry is permanent, and permanent delegation to software nobody reviews is how estates accumulate authority. Expire it; renewal is a cheap conversation and revocation after an incident is not.
Revocability
One action, revoking the delegation immediately, reachable by the delegating human and by whoever is on call. If revocation requires a deploy, it is not revocation.
Four stages from roles to per-action decisions
Nobody arrives at per-action authorization in one step, and attempting it produces a policy layer too complex to reason about. Four stages, each independently useful.
Role-based, per agent
Every agent has its own identity and a role naming the tools it may call. Coarse, and already better than a shared service account. Most estates are here or one step behind.
Add parameter bounds to the mutating tools
Not all of them — the mutating ones. Ceilings, allow-lists, row caps. This single stage closes the largest gap between permission and consequence for the least effort.
Order the work by mutating tools with no schema ceiling. That list is usually shorter than expected and it is where the exposure is.
Add context: environment, target, data classification
The same rule set, evaluated with more inputs. Thresholds tighten in production. Payloads containing PII route differently or get transformed.
Add behaviour and step-up
Recent-behaviour input for loops and anomalies, and step-up authentication for the narrow band where blocking is too blunt and approval too slow. This is where per-action authorization is genuinely complete.
Stage two is where most of the value is. If a programme stalls anywhere, stall at three rather than at one.
Built on this thinking
Stage two onwards, as a running product
BarzelVault evaluates the fully specified action — identity, tool, every parameter, target, environment, data classification, recent behaviour — and returns one of four deterministic outcomes including require-step-up, with the decision recorded in a hash-chained trail. Barzel Central Gateway supplies identity and the coarse role filter in front of it.
Four mistakes worth naming
Treating the agent as a user
Users bring judgement and accountability to the permission. An agent brings neither, so the permission has to be narrower and the decision has to happen later.
Delegation with no expiry
Permanent authority granted to software nobody reviews. Expire everything; renewal costs a conversation.
Discarding roles entirely
Roles are the cheap coarse filter that keeps runtime evaluation affordable. Keep them; stop treating them as the whole answer.
Non-deterministic runtime decisions
If the same action can be decided differently a minute later, the decision is indefensible and untestable. Same inputs, same outcome, always.
Frequently asked questions
What is runtime authorization for AI agents?
Evaluation of a fully specified proposed action — identity, operation, parameter values, target and context — at the moment it is proposed, rather than reliance on a permission granted in advance. It is required because an agent chooses its action at runtime from content that did not exist at grant time.
What is the difference between authentication, authorization and action authorization?
Authentication establishes who is calling. Authorization establishes what class of operations they may perform, decided in advance. Action authorization establishes whether this exact action, with these values, against this target, may proceed now — decided at the moment of proposal.
Why is role-based access control not enough for AI agents?
Three reasons. Roles name operations but not magnitudes, so a role permitting transfer permits every amount. Roles are static while agent context is not — the same operation differs by environment, account status and attempt number. And agent roles accumulate in weeks rather than years, because agents gain tools continuously and nobody attends their leavers process.
Should AI agents be modelled as users?
No. A user brings judgement and accountability to a permission; a person with refund permission decides whether this refund is appropriate. An agent has the permission and none of the judgement, so its permission has to be narrower and the decision has to happen later, at call time.
What inputs does a runtime authorization decision need?
Beyond identity and role: parameter values, target system and jurisdiction, environment, data classification present in the payload, credential mode, and recent behaviour by that identity. The last is the most commonly omitted and catches the most incidents — the eleventh identical write is a different act from the first.
What is delegated authority for an AI agent?
Authority a human grants an agent to act on their behalf, bounded in four dimensions: scope, which operations against which systems and always narrower than the human’s own; magnitude, how much and how many; duration, because delegation with no expiry is permanent; and revocability, in one action reachable by whoever is on call.
How do you move from roles to per-action authorization?
Four stages. Per-agent identity with a role naming its tools. Then parameter bounds on the mutating tools only, which closes the largest gap for the least effort. Then context — environment, target, data classification. Then recent behaviour and step-up authentication. Stage two carries most of the value.
Does runtime authorization replace roles and scopes?
No. Roles are the cheap coarse filter that refuses obvious cases before any policy evaluation runs, which is what keeps runtime decisions affordable. Keep them and stop treating them as the last word.
Sources and further reading
The layered model draws on zero-trust architecture and OAuth’s delegation mechanics, cited below. The three-question framing, the four-stage path and the four bounds on delegated authority are our own.
- 01 · NISTNIST SP 800-207 — Zero Trust Architecture ↗The policy decision point / policy enforcement point split this architecture borrows directly.
- 02 · IETFOAuth 2.1 — draft specification ↗Consolidated current best practice for authorization, including PKCE by default.
- 03 · IETFRFC 8693 — OAuth 2.0 Token Exchange ↗The mechanism for preserving caller authority across a gateway hop.
- 04 · IETFRFC 9068 — JWT Profile for OAuth 2.0 Access Tokens ↗Claim structure a gateway can validate without calling back to the issuer.
- 05 · NISTNIST SP 800-63 — Digital Identity Guidelines ↗Assurance levels behind step-up authentication and re-authentication decisions.
- 06 · CNCFOpen Policy Agent — documentation ↗Reference implementation of decoupled policy decisions and policy as code.
- 07 · OWASP GenAI Security ProjectOWASP GenAI LLM Top 10 (2026) ↗Consensus risk list; excessive agency and prompt injection are the entries governance exists to bound.
- 08 · OWASPOWASP API Security Top 10 ↗Broken object-level and function-level authorization, which reappear unchanged at the tool layer.
Last reviewed 24 August 2026. External links open in a new tab; we do not control their content.
Try the mechanics on a live server
To watch a real tools/list response before you point a client at anything that governs production — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
BarzelVault is the pre-execution decision point, sold as a running product
Nine tools, 12 static resources, 3 resource templates and 9 prompts. Four deterministic policy outcomes — allow, deny, dry-run, require approval — with approval workflow, hash-chained audit and guardrail data protection. Streamable HTTP, JSON-RPC 2.0.
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.