An AI agent's credential is issued once, but the authority of the person behind it changes every week: a new role, a lower limit, a leave of absence, a last day. Agent authorization has to be computed on each request from the person's current entitlements, the scope that person delegated and the agent's own registration. A change in the directory then applies on the agent's next call, without reissuing its credential.
This guide covers stale agent credentials, per-request authority, actions beyond authority and what to require of any system.
Regulatory references verified as of October 31, 2026.
The credential is a snapshot of one day
An agent receives its credential at setup: an API key, an OAuth token a person granted, or a service account. It records what was true on the day it was issued.
The person behind the agent keeps moving. A treasury analyst moves to a new desk. A manager's signing limit drops after an audit. An employee starts twelve weeks of leave. A contractor's engagement ends on a Friday. The directory records each change the same day.
The agent's credential stays as it was. If the systems the agent calls check the credential and nothing else, the agent keeps acting on authority its principal gave up last week.
OWASP names the risk. Its entry on excessive agency lists "excessive permissions" among the root causes, with the example of an extension that "has permissions on downstream systems that are not needed for the intended operation of the application." Its mitigation is to "track user authorization and security scope" so that actions taken on behalf of a user run in that user's context.
Enterprise security already has the answer
Enterprises do not need a new security model for agents. Entitlement models, role definitions, signing limits and policy are built, and joiner, mover and leaver processes run every day. That work is done. The joiner, mover, leaver post maps each HR event to an identity event.
Agents need two properties added on top of that work.
The agent's identity is its own. An agent carries a cryptographic credential that is independent of any person's credential. Revoking it leaves the person's access intact. The record names the agent, so what the agent did is separate from what the person did. The agent authority scope entry explains why a borrowed key fails on all three counts.
The agent's authority is inherited from the person. The agent never exceeds the person who delegated to it, and the person's authority comes from the directory the enterprise already runs. Each agent receives a bounded share of one person's entitlements, as they stand today.
The Trust Fabric sets out the four layers underneath: verified identity, access governance, runtime governance, and audit and evidence. Access governance answers what a person may do, and the enterprise identity provider stays the authority on that question. Runtime governance reads the answer at the moment the agent acts.
Effective authority is computed per request
The pattern is a join across three inputs, evaluated at the time of each request:
- The person's entitlements as of now. Read from the enterprise directory on the request, or from a cache that directory change events clear.
- The delegation grant. What the person delegated to this agent: permitted tools and operations, permitted models, transaction limits, account allowlists, data classifications and an expiry.
- The agent's registration. The scope registered for the agent itself, which no delegation can exceed.
The agent's effective authority is whatever all three permit at once. If any input denies the action, the agent may not take it. When one agent delegates to another, the same rule runs over every link of the chain, so authority narrows down the chain and never widens.
A role change, a revoked entitlement, a termination or an expired grant takes effect on the agent's next request.
Zero trust architecture set the same expectation for people and devices years ago. NIST SP 800-207 states that "Access to individual enterprise resources is granted on a per-session basis" and that "All resource authentication and authorization are dynamic and strictly enforced before access is allowed." An agent can issue many calls in one session, so for an agent the request is the unit to check.
Every input also carries a version: the directory snapshot, the grant and its revision, the registry entry. A control point that records those versions with each decision lets anyone recompute, months later, exactly what authority was in force when the agent acted.
What a directory change does under each model
| Event in the directory | Authority fixed when the credential is issued | Authority computed per request |
|---|---|---|
| Person moves to a new role | Agent keeps the old role's reach until someone reissues its credential | The next call is evaluated against the new role |
| Signing limit is lowered | Agent can still submit payments up to the old limit | A payment above the new limit pauses and goes back to the person |
| Person starts a leave of absence | Agent keeps acting on the absent person's authority | The next call reflects the leave status in the directory |
| Person leaves the company | Agent runs until someone finds and revokes its keys | The next call fails the join, with no credential change |
| Examiner asks what was allowed on a past date | Reconstructed from separate logs, if at all | Recomputed from the input versions in the record |
An action beyond authority goes back to the person
When an agent asks for something beyond its effective authority, a refusal breaks the workflow and teaches people to route around the control. Letting it through defeats the control. The third course is to pause the action and return it to the person on whose authority the agent is acting.
- The control point withholds the action before it executes.
- It reduces the action to a canonical form: the tool, the operation, the arguments, the target, the amount, the agent and the session. It computes a digest of that form.
- It opens an approval ticket bound to the digest. The ticket starts pending and carries an expiry.
- The request goes to the person whose authority the agent is using. That person decides.
- Identity verification scales to the risk. A routine action needs a light check on a registered device. A payment above the delegated limit needs a live biometric check at a defined assurance level, such as NIST IAL2 identity proofing with AAL2 authentication.
- On approval, the exact action approved is released, once. A resubmission with a different amount, payee or account produces a different digest and matches nothing. The ticket is marked redeemed and cannot be used again.
- On denial or expiry, the agent receives a structured response that states the reason, and the action does not run.
OWASP lists the same control among its mitigations: "Utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken." Per-request authority makes the approval precise: a ticket raised because the analyst's limit dropped yesterday carries today's limit in the record. The human in the loop entry separates gating an action from reviewing it afterward.
One control point, two paths, one record
Agents call models, and they call tools. A payment or a database write arrives as a tool call, over the Model Context Protocol (MCP), agent-to-agent (A2A) protocols or plain HTTP APIs. The reasoning behind it arrives as model calls. When separate products govern the two paths, their logs share no identifiers, and nobody can easily show who authorized an action and what the agent saw first.
Protocol-level authorization answers a narrower question. The MCP specification states that it "provides authorization capabilities at the transport level," and that MCP servers "MUST validate that access tokens were issued specifically for them as the intended audience." That confirms a token is valid for this server. Whether the person behind the agent may take this action today needs the directory.
The pattern places one enforcement point in front of both paths, inside the customer's environment. The MCP security and A2A entries cover the protocols. Two tool-path controls belong beside authorization:
- Pin tool definitions. On first use, store a fingerprint of each tool's name, description and input schema. Compare on every later use, so a server that changes a tool after approval is caught. The tool poisoning entry explains the attack.
- Track taint. Mark data that comes back from lower-trust tools, follow it through the agent's work, and deny a sensitive tool call whose arguments carry it.
Evidence the customer keeps and checks
A record the vendor alone keeps asks a regulator to trust the vendor. Each decision is appended to a chain in which every record carries a sequence number, the hash of the record before it and a keyed hash of its own contents. At short intervals, a time-stamping authority signs a token over the records appended since the last interval; under RFC 3161, "The TSA's role is to time-stamp a datum to establish evidence indicating that a datum existed before a particular time." The records and tokens go to write-once storage in an account the customer controls. An independent verifier recomputes the chain without access to the system that wrote it.
Each record names the person, the agent, the delegation chain, the effective authority with its input versions, the policy, the ticket's lifecycle, the verification level and the decision. The tamper-evident audit log entry covers the mechanics.
What to require of any agent authorization system
Put these questions to any vendor:
- When are the person's entitlements read? At credential issue, at session start, or on each request?
- Does the agent have its own identity? Does revoking the agent disable the person?
- Can authority widen through delegation?
- What happens to an action beyond authority? Refused, let through, or returned to the person whose authority the agent is using?
- Is the release bound to what was approved? Can a changed amount, or a second use, pass on one approval?
- Does identity verification scale to risk?
- Are model calls and tool calls in one record? Ask for the identifier that joins them.
- Can a past decision be recomputed from the input versions in the record?
- Can the customer verify the evidence without the vendor's system?
- Does a cached answer respect authority, or can it reach a requester who lacks the entitlement to see it?
How APERION governs agent authority
Owned intelligence, governed from the first call. APERION future-proofs the hybrid AI estate: every agent and every model an enterprise rents or owns, governed from one control point inside its own walls. The control point sits in the path between agents and every model and tool they call, rented or owned, and keeps each action inside the authority a person delegated.
The proof is one call. An agent tried to wire $50,000 nobody approved. The amount exceeded the authority delegated to the agent. The action paused and went back to the person whose authority the agent was using, who decided with proof they were there. The accountable human decides, and the record shows who decided, when and under which policy.
Smartflow enforces on the model path and the tool path, across MCP, A2A and HTTP, and writes both into one hash-chained, timestamped record that the customer verifies with the open source audit verifier. Tool definition pinning and taint tracking are described on the Smartflow 1.20 release page. The AIDA guide covers how an agent credential binds an agent to the person it acts for.
A verified person, the authority that person delegated, the agent that used it, the policy that applied, the decision and the record of all of it. That chain is the product.
Frequently asked questions
What is AI agent authorization?
AI agent authorization is the decision, made for each action an agent attempts, about whether the agent may take that action on behalf of a person. A sound decision draws on three inputs: the person's current entitlements in the enterprise directory, the scope the person delegated to the agent, and the scope registered for the agent itself. The action proceeds when all three permit it.
Why is a scoped OAuth token not enough for an AI agent?
A scoped token records what was granted when it was issued and stays valid until it expires or someone revokes it. The person's authority can change in the meantime through a new role, a lower limit, a leave or a departure, and the token does not see it. A token also confirms that a call is valid for a server, which is a narrower question than what the person may do today.
What is delegated authority for AI agents?
Delegated authority is the share of a person's authority that the person hands to an agent: which tools and operations, which models, what transaction limits, which accounts, which data classifications and for how long. It can never exceed the person's own authority. When one agent delegates to another, the second agent's authority is bounded by the first, so authority narrows along the chain.
What is just-in-time authorization for AI agents?
Just-in-time authorization computes an agent's authority at the moment of each request, from current inputs, instead of trusting a decision made when the credential was issued. A role change, a revoked entitlement or an expired grant applies to the agent's next call. No credential is reissued, because authority was never written into it.
What happens when an agent tries something outside its authority?
In the pattern described here, the action pauses before it executes and goes back to the person whose authority the agent is using. That person's identity is verified at a level matched to the risk, and the person decides. On approval, the exact action approved runs once. On denial or expiry, the agent receives a structured reason and the action does not run.
How can an auditor confirm what an agent was allowed to do?
The record for each decision stores the versions of the directory, the delegation grant and the agent registration that were in force, along with the policy, the decision and the person who decided. Chained hashes, timestamp tokens and write-once storage in the customer's account let an independent verifier confirm the record was not altered, without access to the system that wrote it.
Sources
- OWASP GenAI Security Project, LLM06:2025 Excessive Agency. Opened October 31, 2026.
- NIST, SP 800-207, Zero Trust Architecture, August 2020, Section 2.1, tenets 3 and 6. Opened October 31, 2026.
- Model Context Protocol, Authorization, specification version 2026-07-28. Opened October 31, 2026.
- NIST, SP 800-63A-4, Digital Identity Guidelines: Identity Proofing and Enrollment. Opened October 31, 2026.
- NIST, SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management. Opened October 31, 2026.
- IETF, RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP), August 2001. Opened October 31, 2026.
Related reading
Put this in the path of your own agents.
Policy enforced inline between your agents and every model and tool they reach, with a record bound to the human who owns it.
Request a Demo Read the docs