Notifications
Clear all
Topic starter
22/06/2026 10:17 am
TL;DR: Most AI agent security failures come from repeated authorization mistakes, not zero-days: borrowed user sessions, static API keys, weak token scoping, and missing audit trails, according to WorkOS. The core lesson is that agent identity must be separate from human identity, or governance, revocation, and accountability all break down.
NHIMG editorial — based on content published by WorkOS: The 2026 AI agent auth checklist: 9 things to audit before you ship
Questions worth separating out
Q: How should security teams govern AI agents that act on behalf of users?
A: They should treat each agent as a separate principal, then apply delegated access only where the agent’s configured rights and the user’s current rights overlap.
Q: Why do borrowed sessions and shared service accounts create agent security risk?
A: Because they destroy identity boundaries.
Q: What do security teams get wrong about agent access tokens?
A: They often treat a token as proof that the agent should be trusted broadly.
Practitioner guidance
- Register each agent as a separate principal Assign a distinct client identity to every agent or agent class so you can revoke, scope, and audit access without affecting unrelated workloads.
- Enforce intersection-based authorisation at runtime Evaluate the agent’s configured permissions together with the user’s current permissions before every tool call.
- Separate login tokens from delegated access tokens Use OpenID Connect for user authentication and OAuth 2.1 for downstream authorisation, then keep the resulting access token short-lived, audience-bound, and scoped to one resource server.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step implementation patterns for per-agent OAuth client registration and delegated access flows
- Code-level examples for enforcing intersection-based authorisation on every tool call
- Detailed token claim design, including subject, actor, audience, and scope handling
- Operational checklist for audit logging, revocation handling, and fail-closed behaviour
👉 Read WorkOS's AI agent auth checklist for identity, delegation, and token controls →
AI agent authorization gaps: what teams need to audit before shipping?
Explore further
22/06/2026 11:07 am
Per-agent identity is now a governance baseline, not an implementation preference. Shared service accounts and borrowed user sessions collapse attribution, revocation, and scoping into one opaque control surface. That model was designed for a simpler world in which one principal, one role, and one audit trail were usually enough. The implication is that agentic systems force identity teams to govern the agent itself as the accountable principal.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when an AI agent takes an unintended action?
A: Accountability sits with the organisation that designed the delegation model, not with the agent itself. The system has to preserve enough context to show which user initiated the request, which agent executed it, what authorisation was in force, and whether the action should have been blocked or approved.
👉 Read our full editorial: AI agent auth checklist: why per-agent identity now matters
