Notifications
Clear all
Topic starter
06/06/2026 11:33 am
TL;DR: AI agents are becoming first-class API consumers, and WorkOS argues they need explicit OAuth-based authorization, tight scopes, audience checks, step-up approval for sensitive actions, and full request validation because agentic chaining and prompt injection expand the blast radius of weak controls. The real issue is that old API security assumptions still treat every caller as a human-triggered action.
NHIMG editorial — based on content published by WorkOS: API security best practices for the age of AI agents
By the numbers:
- 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%).
Questions worth separating out
Q: How should security teams authorize AI agents that call APIs on behalf of users?
A: Use delegated authorization, not shared human sessions.
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.
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.
Practitioner guidance
- Make OAuth 2.1 the default for agent access Use a central authorization server, short-lived tokens, and explicit consent for every agent workflow.
- 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.
- 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.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- OAuth 2.1 implementation guidance for agentic API flows, including PKCE and redirect handling
- Practical examples of scope design for read, write, and destructive agent actions
- How to structure claims such as sub, client_type, and act for delegated requests
- Request validation and replay protection considerations for machine-speed API callers
👉 Read WorkOS's API security best practices for AI agent identities →
AI agent identities and API authorization: what changes now?
Explore further
06/06/2026 12:25 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: API security best practices for AI agent identities
