Notifications
Clear all
Topic starter
11/07/2026 8:27 pm
TL;DR: AI agents moving into production are converging on OAuth because static API keys, passwords, and session cookies do not provide the consent, scoping, revocation, and auditability required for delegated access, according to Stytch. The governance issue is less about choosing an auth protocol than about preserving accountability when machine identities act on behalf of users.
NHIMG editorial — based on content published by Stytch: AI agent authentication methods and OAuth for delegated access
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams authenticate AI agents that act on behalf of users?
A: Use OAuth with explicit user consent, narrow scopes, and revocable tokens.
Q: Why do static API keys create more risk for AI agents than for ordinary services?
A: Static keys are poor for agents because they behave like long-lived shared secrets with no built-in consent, scope, or revocation semantics.
Q: How do organisations decide between OAuth Authorization Code flow and Client Credentials?
A: Use Authorization Code when the agent acts for a user and must inherit that user’s permissions.
Practitioner guidance
- Separate delegated access from service-account access Classify every AI agent workflow before implementation.
- Eliminate shared secrets from agent onboarding Replace API keys, passwords, and session cookies with revocable token-based patterns for any production or sensitive-data workflow.
- Map scopes to real task boundaries Define the smallest useful permissions for each agent and review them against the actual actions the agent can trigger.
What's in the full article
Stytch's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for implementing Authorization Code with PKCE and Client Credentials in agent workflows.
- Detailed treatment of advanced OAuth extensions such as on-behalf-of token exchange and dynamic client registration.
- Implementation considerations for MCP-connected systems that need secure client discovery and authentication.
- Examples of how connected-app revocation and token lifecycle management are handled in production auth designs.
👉 Read Stytch's guide to AI agent authentication methods and OAuth →
AI agent authentication methods: what OAuth changes for IAM teams?
Explore further
11/07/2026 8:57 pm
OAuth is becoming the default because static secrets do not provide a governable delegation model for agents. The article is right to treat API keys and passwords as poor fits for production agent access, but the deeper issue is that they erase the separation between consent, scope, and attribution. Once an agent acts on behalf of a user, access must be revocable without collapsing the entire identity. Practitioners should treat OAuth as the baseline control plane for delegated NHI access, not as an implementation detail.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when an AI agent performs an unauthorized action?
A: Accountability depends on the identity model used. If the agent acted with delegated user access, logs should attribute the action to the user and the client that obtained the token. If the agent used a service account, accountability sits with the owning system and its lifecycle controls, including revocation, scope review, and audit logging.
👉 Read our full editorial: OAuth is becoming the default for AI agent access governance
