AI Agent Authorization:
Five Controls Before a Tool Runs

AI agent authorization is the practice of verifying agent identity, delegated authority and each proposed action as separate facts. An agent should not impersonate its user, and it should not infer permission to use any tool or dataset merely because the goal sounds legitimate. The final decision belongs at the technical boundary immediately before a tool produces an effect.

This is now a production architecture question for small and mid-sized engineering teams. A text-only assistant has a different blast radius from an agent that sends email, updates tickets, executes code or places orders. As more systems are connected, a login at the start of a session becomes weaker evidence for an action taken several steps later.

Why agent identity has become a production concern

On 27 August 2026, NIST highlighted four recurring weaknesses: shared credentials, static or long-lived tokens, broadly scoped access and over-reliance on manual approval. NIST argues that agents should be treated as first-class entities with unique identifiers, credentials and entitlements that remain bound to the person or system operating them.

This is guidance, not a completed agent identity standard. The underlying NCCoE concept paper published on 5 February 2026 is still a draft. The direction is nevertheless useful: established identity and access management principles remain relevant, but they must accommodate machine speed, delegation chains and probabilistic planning.

The key distinction is straightforward. Authentication establishes which agent and principal are making a request. Authorization decides whether that exact action on that exact resource is permitted under current conditions. A valid token therefore proves neither that a model-generated parameter is correct nor that the action is necessary or safe.

Five controls for secure AI agent authorization

Control	Technical outcome	Negative test
1 · Identity	User, agent, run and service are distinguishable	A different agent cannot reuse the same grant
2 · Delegation	Authority names purpose, action, resource, audience and expiry	A read task cannot escalate into write or delete
3 · Policy gate	Tool, arguments and context are checked before every effect	An allowed function with another tenant's object ID is denied
4 · Approval	Risky actions expose clear, immutable decision data	Changing an argument invalidates the previous approval
5 · Evidence	Decision, execution, result and revocation can be correlated	Aborted and repeated runs remain visible

This model is ATMAN analysis based on the sources listed below. It translates standards into testable boundaries. It does not imply that one product implements every control or that passing one test can guarantee model behaviour.

1. Use a distinct identity instead of impersonating the user

A production agent needs at least a stable agent identifier, a short-lived run or session identifier, and a reference to the delegating user or system task. A downstream service must be able to distinguish a person acting directly, an agent acting for a person, and a system-triggered task without a current user.

Shared API keys erase that distinction. If ten agents use the same secret, an audit can identify only the credential, not the actual actor. Do not place long-lived credentials in prompts, Markdown files or logs. Use a secret or token service that evaluates identity and environment, then issues a constrained credential at runtime.

2. Express authority as a task, not a broad role

“Use the CRM” or “access email” is too vague for an agent. Delegated authority should name the action, target resource, audience, data class, validity window and permitted volume. A support workflow might allow reading ticket 4711 and preparing a reply, while denying send, delete and contact export.

The IETF's OAuth 2.0 Rich Authorization Requests (RFC 9396, May 2023) supplies structured authorization_details for this purpose. Actions, locations, data types and identifiers can express finer-grained authority than a broad scope. Teams must verify whether their identity stack supports the standard; the architectural pattern can also be represented in a policy document or capability token.

Credentials should be short-lived, audience-restricted and revocable. NIST IR 8587, published on 22 December 2025, targets agencies and cloud providers and remains an Initial Public Draft. Its guidance on key isolation, token validation, lifecycle controls and continuous monitoring is still a useful technical baseline.

3. Make the execution decision outside the model

The decisive security boundary sits between planning and effect. A model may propose a tool and its arguments; a deterministic component must evaluate them against a schema and policy. Prompt content and agent memory must not be able to alter this component.

1. Normalize. Resolve aliases, object paths, units and defaults into one unambiguous representation.
2. Validate. Reject unknown fields, wrong types, prohibited values and ambiguous targets.
3. Authorize. Evaluate the user, agent, action, resource, purpose, time, environment and current risk together.
4. Budget. Limit calls, records, cost, concurrency and retries for the run.
5. Execute. Pass only the approved, immutable action to a minimally privileged adapter.
6. Verify. Capture the actual outcome and side effect; an HTTP 200 response does not prove business success.

A current vendor-specific implementation appears in the AWS Security Blog post published on 27 August 2026. It places checks before the model, immediately before the tool call and after the tool response, mixing deterministic schema, regular-expression and allowlist checks with model-based guardrails. The portable lesson is where the boundaries sit, not which cloud service implements them.

4. Match approval friction to potential harm

Approval before every read makes an agent ineffective; one blanket approval for a whole session makes consent meaningless. Classify actions by impact. Narrow, read-only and reversible operations can run automatically under explicit policy. External communication, personal-data export, payments, deletion, production changes and privilege escalation should require explicit approval or remain blocked.

The approval must show what will happen: target, recipient, data volume, amount, environment and material arguments. Bind the decision to a hash or immutable action ID so any later parameter change requires new consent. Never collect passwords or secrets through the agent dialogue. The Model Context Protocol elicitation specification dated 18 June 2025 explicitly prohibits servers from requesting sensitive information through elicitation.

5. Bind tokens and preserve decision evidence

A stolen bearer token can generally be presented by whoever possesses it. DPoP in RFC 9449 (September 2023) can bind an OAuth token to a cryptographic key and help detect replay. The standard also defines its boundary: DPoP by itself is neither client authentication nor access control. It protects the presentation path, not the business legitimacy of an action.

An audit trail should connect user and agent identity, run ID, tool, normalized action, target resource, policy version, decision, approval ID, result, time and correlation ID. Avoid logging secrets and unnecessary personal data. Separate access control, tamper-resistant storage and an explicit retention period make the evidence more dependable.

Agent and data-flow design fits within a clearly bounded AI and data engagement. The identity model, policy boundary, secrets, logging and abuse tests belong in the accompanying cybersecurity design. For output-channel notices, marking and human review, see the separate guide to implementing AI Act transparency obligations.

Production checklist: six tests before rollout

1. Switch identities. Repeat the same task with another user and agent; data and authority must not carry over.
2. Tamper with arguments. Change the object ID, recipient, amount, environment and tool while retaining an otherwise valid token.
3. Attenuate delegation. Confirm that a child task can never receive more authority than its parent.
4. Expire approval. Change an argument after consent or let the decision window lapse; execution must stop.
5. Replay the token. Present it from another process or key, then verify detection, containment and revocation.
6. Trace end to end. Reconstruct the path from user intent through policy decision and tool call to the real outcome.

A rollout is credible only when allowed actions work and prohibited variations fail visibly. Start with one reversible workflow. Add tools, authority and automation only after negative tests and revocation are observable in production.

Frequently asked questions about AI agent authorization

Why is a separate account not enough for an AI agent?

A separate account makes the agent identifiable, but it does not constrain every action. The system also needs delegated, short-lived authority and a deterministic check of the tool, resource, parameters and context immediately before execution.

Should a human approve every agent tool call?

No. Narrow, read-only and reversible actions can run automatically under explicit policy. Manual approval is most useful for irreversible, external, financial, privileged or unusual actions.

Does DPoP completely prevent misuse of agent tokens?

No. DPoP binds an OAuth token to a cryptographic key and makes third-party replay harder. The standard explicitly says that DPoP alone is neither authentication nor access control.

What belongs in an AI agent audit trail?

At minimum: user and agent identity, run ID, tool and action, target resource, normalized parameters, policy version, decision, approval, result, timestamp and correlation ID. Secrets and unnecessary personal data should not be written to plaintext logs.

Sources and methodology

• National Institute of Standards and Technology: Back to the Future – Why Agentic AI Needs a Strong Identity Foundation, published 27 August 2026, accessed 8 September 2026
• NCCoE/NIST: Accelerating the Adoption of Software and AI Agent Identity and Authorization, concept paper published 5 February 2026, draft status, accessed 8 September 2026
• National Institute of Standards and Technology: NIST IR 8587 – Protecting Tokens and Assertions from Forgery, Theft, and Misuse, Initial Public Draft published 22 December 2025, accessed 8 September 2026
• Internet Engineering Task Force: RFC 9396 – OAuth 2.0 Rich Authorization Requests, Proposed Standard published May 2023, accessed 8 September 2026
• Internet Engineering Task Force: RFC 9449 – OAuth 2.0 Demonstrating Proof of Possession, Proposed Standard published September 2023, accessed 8 September 2026
• Model Context Protocol: Elicitation, specification version dated 18 June 2025, accessed 8 September 2026
• AWS Security Blog: Extend Amazon Bedrock Guardrails to Tool Interactions Using the Strands Agents SDK, published 27 August 2026, accessed 8 September 2026

NIST supplies the current problem framing, the two IETF RFCs provide concrete OAuth mechanisms, and AWS offers a vendor-specific implementation example. The five-control model, risk tiers and test order are ATMAN analysis. This article is technical guidance, not legal advice, certification advice or a product-specific security guarantee.