API security best practices for AI agent identities

At a glance

What this is: This is an analysis of how AI agents change API authorization, with the core finding that agents must be treated as non-human clients with narrow, explicit permissions.

Why it matters: It matters because IAM, PAM, and API governance teams now have to design for agentic delegation, not just human sessions or static service accounts, or they will misjudge scope, consent, and blast radius.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).

👉 Read WorkOS's API security best practices for AI agent identities

Context

AI agent identity is becoming an API security problem, not just an AI feature problem. The article argues that once agents call APIs directly, the authorization model must treat them as non-human clients with real permissions, real consequences, and no guaranteed human oversight at runtime.

That shift matters because traditional API security guidance assumes a human action sits behind each call. Agentic chaining, probabilistic decisions, and delegated execution break that assumption, so IAM teams need to think in terms of explicit consent, scoped delegation, and runtime validation for every request.

Key questions

Q: How should security teams authorize AI agents that call APIs on behalf of users?

A: Use delegated authorization, not shared human sessions. Give the agent a narrowly scoped token, validate the audience on every request, and bind the token to the acting user and client context. For sensitive operations, require a fresh user approval step so the agent cannot exceed the delegated intent.

Q: Why do AI agents create more API authorization risk than traditional service accounts?

A: AI agents make runtime decisions, chain actions, and can turn one allowed request into several unintended ones. That means blast radius grows after authorization, not just at provisioning time. Traditional service accounts are usually static; agents can change behaviour mid-session and amplify a small permission mistake into a larger incident.

Q: How do teams know whether an agentic authorization model is working?

A: Look for three signals: every service validates audience, high-risk actions trigger step-up approval, and audit logs show which agent acted for which user. If tokens are reused across services or sensitive operations happen without re-authorization, the model is not containing delegated risk.

Q: What is the difference between scopes and claims in AI agent authorization?

A: Scopes define what broad actions a token may perform, while claims describe the identity and context behind the request. Scopes should stay coarse enough to understand and control, but claims should not become a place to hide business rules. Use claims to inform policy, then enforce the rule in the API layer.

Technical breakdown

OAuth 2.1 as the authorization baseline for AI agents

OAuth 2.0 and OAuth 2.1 remain the correct foundation because they separate authentication from delegated authorization. For AI agents, that matters more than ever because the agent should never inherit a human session or reuse a broad token across tools. OAuth gives you short-lived tokens, consent capture, and a place to encode who is acting on whose behalf. In agentic systems, the protocol is only safe when the issuing authority, audience, and scopes are all enforced at runtime.

Practical implication: standardize agent access on OAuth 2.1 and reject any design that forwards human tokens into agent flows.

Scopes and claims for agent-specific authorization

Scopes define the broad action class a token may use, while claims describe context such as the acting user, client type, or delegation chain. That separation is important because agents need both coarse and fine control. Scopes alone are too blunt for sensitive workflows, and claims alone should never become business logic. The security model works only when the API uses claims to understand context and policy engines to decide whether the specific action is allowed right now.

Practical implication: keep scopes narrow, use claims for identity context, and enforce business rules outside the token.

Audience restriction and step-up checks at trust boundaries

Agentic systems often route through multiple components, including MCP clients, gateways, and downstream APIs. That makes token audience validation essential because a token issued for one service should not be reusable everywhere else. Step-up authorization adds a second layer for high-risk actions by forcing a stronger assurance level before sensitive changes proceed. Together, these controls keep delegated access from becoming unconstrained lateral movement across service boundaries.

Practical implication: validate aud on every hop and require step-up approval for destructive or high-impact operations.

Threat narrative

Attacker objective: The objective is to induce an agent to execute privileged API actions outside the user's intended scope, causing unauthorized data access, modification, or deletion.

1. Entry occurs when an AI agent receives a delegated token broad enough to start calling downstream APIs without human-by-human confirmation.
2. Escalation follows when autonomous chaining or prompt injection causes the agent to reuse that access for actions the user did not explicitly intend.
3. Impact lands when the agent performs destructive or sensitive API operations at machine speed, expanding blast radius before a human can intervene.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agents are first-class API consumers, so API authorization must move from user-centric trust to delegation-centric control. The article is right that an agent does not click a button and then stop. It reasons, chains, and acts across multiple calls, which means the old assumption that every API request maps cleanly back to a deliberate human gesture is no longer reliable. For IAM and API teams, that changes the design problem from session management to delegated decision control.

Agentic chaining creates a distinct identity blast radius. A token granted early in a workflow can be reused later in ways the user never explicitly approved, especially when the agent operates across multiple tools or internal services. That is not just over-permissioning in the classic NHI sense. It is a higher-order delegation problem where one broad authorization decision can cascade into many unintended API actions.

Context-aware claims are necessary, but they are not a substitute for policy enforcement. The article correctly separates identity context from business rules. Claims can tell an API that the caller is an AI agent acting for a specific user, but they cannot safely encode every constraint on timing, amount, sensitivity, or destination. Practitioners should treat claims as evidence, not as the policy itself.

Step-up approval remains the right control pattern for high-consequence actions, even when the caller is non-human. High-risk API operations still need a deliberate human yes, because delegated intent and delegated authority are not the same thing. The governance question is not whether agents are useful. It is which actions should never be allowed to cross the trust boundary without explicit re-authorization.

Audience-restricted delegation is the practical test of whether an agentic API design is secure. The article highlights the right pattern: every hop should validate the intended recipient, and recycled tokens should not flow unchecked between components. For identity teams, that is the difference between bounded delegation and token sprawl. If audience discipline is weak, the environment is already treating agent access like ambient trust.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, which leaves nearly half of organisations without a defensible compliance trail.
• For a broader control lens, see OWASP Agentic Applications Top 10 for the governance and attack patterns that make agent API access hard to constrain.

What this signals

Policy drift is now the main failure mode in agentic API programmes. Teams that can validate tokens but cannot express contextual approval rules will still lose control when agents begin chaining requests. The immediate programme signal is to review where human-triggered access assumptions still sit inside gateway logic, consent UX, and downstream authorization checks.

Identity blast radius is the concept practitioners should watch. Once an agent can reuse delegated authority across tools, the size of the authorization mistake matters more than the sophistication of the model. With 80% of organisations already reporting agents acting beyond intended scope, according to AI Agents: The New Attack Surface report, the governance gap is no longer hypothetical.

Use the Analysis of Claude Code Security and the OWASP Agentic AI Top 10 together to pressure-test how your APIs handle agentic delegation, prompt-influenced requests, and approval boundaries. If your controls only prove that a request came from a valid client, they do not yet prove that the request should be allowed in context.

For practitioners

• Make OAuth 2.1 the default for agent access Use a central authorization server, short-lived tokens, and explicit consent for every agent workflow. Do not pass human access tokens into MCP clients or downstream APIs. Treat any non-OAuth agent path as a migration item, not an acceptable exception.
• Separate coarse scopes from fine-grained policy decisions Define narrow scopes such as read-only or action-specific permissions, then enforce request-level conditions in a policy engine. Use claims to describe the acting user, client type, and delegation context, but keep operational limits such as amount, sensitivity, and destination outside the token.
• Validate token audience on every service hop Reject tokens whose aud claim does not match the receiving service, especially in agent-to-agent chains and gateway-to-API flows. Do not reuse external tokens inside internal services without re-issuing a token that is scoped for the next hop.
• Require step-up approval for destructive actions Force re-authorization before deletes, financial transfers, access revocation, or data export. Bind the higher assurance level to the new token and verify it before the API executes the request, so the agent cannot treat sensitive changes like routine reads.

Key takeaways

• AI agents turn API authorization into a delegated decision problem, not a simple authentication problem.
• Broad or reusable tokens create outsized blast radius when agents chain actions or operate without continuous human review.
• The controls that matter most are narrow scopes, audience validation, context-aware policy enforcement, and step-up approval for high-risk actions.

Key terms

• Agentic API Access: API access granted to an AI agent that can decide which requests to make and when to make them. The security challenge is not only who authenticated, but whether the delegated authority remains constrained while the agent chains actions across tools and services.
• Audience Restriction: A token control that limits where a credential can be used. In agentic systems, audience restriction prevents a token issued for one service from being replayed against another, which is essential when requests move through MCP clients, gateways, and downstream APIs.
• Step-up Authorization: A re-authorization pattern that requires stronger user assurance before a sensitive action is allowed. For AI agents, it preserves human control over destructive or high-impact operations even when the surrounding workflow is automated and the agent is otherwise acting on the user's behalf.
• Delegated Context: The identity and usage context carried with an agent request, such as which user the agent acts for and which client initiated the call. It helps an API understand the request, but it does not replace policy enforcement or validate whether the action should proceed.

Deepen your knowledge

AI agent API authorization and delegated access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing controls for agents that call tools and APIs, this is the right baseline to build from.

This post draws on content published by WorkOS: API security best practices for the age of AI agents. Read the original.