Runtime authorization for AI agents.

Runtime authorization checks whether a particular agent may perform a particular operation on a particular target under a current, traceable grant and policy. It belongs immediately before the last boundary that can stop a consequential effect. Authenticating an agent at login or approving its task at creation does not settle every later tool call. The agent may plan new steps, parameters may change, and upstream authority may disappear.

The design needs trusted actor and task attribution, a verifiable authority origin and delegation chain, a policy evaluation using current context, and an enforcement point that the agent cannot bypass. The decision is bound to the evaluated request. The executor retains its own domain checks, and evidence must say what it did, not just what the authorization system allowed.

An agent can make many calls during one task. Some read data; others change external state. The system should evaluate a consequential request with its principal, authority chain, operation, target, purpose, policy and current context. A one-time “agent approved” flag does not capture those differences.

The enforcement point needs to sit before the tool or API executes. If another unchecked route reaches the same operation, the authorization architecture is incomplete.

• Agent and task identity
• Protected operation and target
• Valid delegated authority
• Current policy and trust
• Enforcement before execution

ALLOW permits the evaluated action; DENY blocks it; ESCALATE seeks approval; DEGRADE retains a specified lower-risk capability. These outcomes are not interchangeable. A degraded read mode should not quietly keep write access.

The decision should include a reason an operator can review. A valid credential may coexist with an expired grant or a newly risky environment.

Record the decision separately from the execution response and observed outcome. Retries should not convert a denied request into an allowed one or duplicate an already executed action. A trustworthy runtime design makes failure and revocation behavior explicit.

Approving a task may authorize an agent to investigate and prepare work, while releasing a payment or modifying a production service requires an action-specific grant. A runtime check resolves that distinction at the last meaningful moment before execution. It should evaluate the actual target and operation, not merely the wording of an earlier task request.

The action may also be affected by a new signal or a revoked parent grant. This is why a valid token at the tool boundary is evidence of identity or access, not proof that the operation remains within autonomous authority.

A task approval may cover investigation while the eventual tool call changes production state. The check should see the actual operation, target, principal, task, valid grant chain, policy and current context before the executor commits the effect. A check made only when a job is queued cannot account for a cancelled maintenance window or a revoked grant when the worker runs later.

Map every route to the effect. If an agent can call a raw API after a checked tool wrapper denies it, the wrapper is not an enforcement point. Likewise, a human approval of a vague plan should not be reused for a different target chosen later.

ALLOW applies to the evaluated request, not to all future calls. DENY must stop execution. ESCALATE should preserve the exact pending operation for review. DEGRADE must name the lower-risk capabilities still permitted. When policy or required context is unavailable, the system needs an explicit risk-based fallback rather than silently allowing a high-impact write.

A decision record proves what the authority layer decided. It does not prove that the executor succeeded. Link the decision to an execution receipt and, where possible, an observed state change. A timeout may leave the outcome unknown; reconcile before retrying a consequential action.

A runtime request should carry or resolve the authenticated principal, represented user or organization, task, originating grant, parent chain, purpose, tool, operation, stable target, normalized parameters, time, policy version, trust state and approval state. Each fact needs a trusted source. A model-generated sentence that says the user approved a transfer is not approval evidence.

The PDP-style decision can return ALLOW, DENY, ESCALATE or DEGRADE with a reason, validity interval and digest of the evaluated request. DEGRADE must name a smaller permitted set, such as diagnostic reads without mutation. It cannot mean “continue and watch more closely.” The PEP-style gate compares the final executor payload with the digest and refuses a changed request.

Short lifetimes reduce exposure but do not solve time-of-check/time-of-use. A request can be allowed, delayed in a queue, and executed after its maintenance window closes or its parent grant is revoked. Reevaluate high-impact work at the last meaningful boundary before commit. Cache only when the key binds all decision-relevant facts and the permitted staleness is explicit.

Approval follows the same rule. Bind it to the approver, agent, task, operation, target and normalized values, then expire and consume it according to the action contract. A changed beneficiary requires a new approval. A replayed approval must not authorize a second payment. Revocation state, approval state and risk state are separate inputs and should produce distinguishable denial reasons.

Authorization and idempotency solve different problems. Authorization determines whether the exact action is permitted. An idempotency key helps an executor recognize a retry of the same intended mutation. After a timeout, the caller should reconcile the provider reference or authoritative state before attempting another consequential operation; the timeout alone cannot establish success or failure.

Keep the authorization decision, execution receipt and observed outcome as three linked records. Decision = ALLOW, executor = TIMEOUT and observed state = UNKNOWN is an honest result. Later observation can move the outcome to CONFIRMED or NOT_OBSERVED without rewriting what the policy service decided at the earlier time.

Inventory every consequential tool and direct API path. Choose an enforcement point that sees the final operation and parameters. Define the grant origin and delegation format, current policy inputs, approval binding, revocation freshness, cache rule and failure mode. Decide which lower-risk actions may continue under DEGRADE. Preserve task and authority context through MCP servers, queues and child-agent handoffs.

Test an allowed request, out-of-scope target, changed parameter, expired grant, revoked parent, replayed approval, stale cached decision, direct bypass, missing policy dependency and ambiguous executor timeout. Verify the protected system state after each test. A clean policy log is insufficient if an alternate credential can still cause the effect.

A Policy Enforcement Point (PEP) intercepts or gates the protected operation. A Policy Decision Point (PDP) evaluates the request and returns a decision. An agent tool wrapper can act as a PEP only if no alternate path can reach the same effect unchecked. In another environment the gate may sit at an API, queue worker or privileged executor. A decision service may be separate or colocated. These established terms describe an architectural role, a public explanation of enforcement and decision roles rather than a disclosure of private implementation.

Capture the principal, user or organization represented, task, tool, operation, target, normalized parameters, purpose, authority chain, policy version, risk signals, approval state and time. The gate should verify which system supplied each fact. An agent’s own text saying that the user approved the action is untrusted. A missing required field on a high-impact write is a denial or escalation condition, not a reason to infer a permissive default.

OAuth scopes limit what a token can reach. RBAC provides stable role permissions. ABAC can consider principal, resource and environment attributes. Capability systems can carry tightly scoped rights. All are useful mechanisms. The agent-specific question is whether the current task and delegation authorize this exact consequence. A workload scope that can call a payment API does not prove authority to release a specific invoice for a specific counterparty and amount.

Tool allowlisting is similarly valuable but coarse. An MCP server may expose a tool for account management; discovering that tool does not authorize a call that changes a beneficiary. The gate must evaluate operation and parameters. The MCP transport authorization specification governs access to an MCP server, while application-level authority still needs to decide whether a particular protected tool effect is permitted.

Consider an agent that schedules a production restart during a maintenance window. The job waits in a queue. Before execution, the window closes and an operator revokes the parent grant. A decision made when the job was enqueued is stale. The worker should resolve the current chain and policy at the last meaningful point before restart. This is the time-of-check/time-of-use problem in an autonomous workflow.

For a high-impact call, bind approval to the actor, tool, operation, target and normalized parameters. Keep its validity short and reject reuse for a different request. A replayed approval must not make two payments or two destructive changes. Idempotency or a deduplication key addresses repeat execution; authorization addresses whether the operation is permitted. Both are required in a sound design.

ALLOW means the exact evaluated operation may be attempted. DENY blocks it. ESCALATE asks for review of the exact pending action. DEGRADE authorizes a specified lower-risk subset, such as diagnostics without writes. For high-consequence actions, missing policy, unverifiable origin, unreachable grant state or invalid approval should normally fail closed. A read-only mode may continue when its own grant and policy are still valid.

Suppose the decision is ALLOW, the executor times out and later observation is UNKNOWN. That is not a successful remediation. Store decision, execution receipt and observed outcome as separate records with timestamps and correlation. Reconcile the actual state before a retry. This distinction helps operators understand whether a failure was in authorization, execution or observation.