AI agent integration is forcing IAM teams to rethink OAuth trust

At a glance

What this is: This analysis argues that AI agents will push services toward OAuth, token exchange, and dynamic client registration as the practical basis for delegated access.

Why it matters: For IAM and NHI teams, the challenge is to let agents act on behalf of users without turning short-lived delegation into persistent, overbroad access.

👉 Read Curity's analysis of AI agent integration, OAuth, and token exchange

Context

AI agent integration is not just an application design issue, it is an identity and authorization problem. Once an agent can call APIs, update records, or trigger transactions on behalf of a user, the service must decide how to authenticate the agent, how to limit scope, and when to require step-up approval. That makes agentic AI a direct NHI governance concern, because the agent is effectively a non-human actor operating with delegated access.

Curity's example is consistent with where the market is heading: agents will not always use polished first-party integrations, and they may arrive through APIs, token exchange, or even user interfaces. That means service providers need controls that work even when the integration path is imperfect. The organizations that treat agent access as a normal app-client problem will miss the identity risk introduced by autonomous execution.

Key questions

Q: How should security teams govern AI agents that act on behalf of users?

A: Treat AI agents as delegated non-human identities with task-scoped permissions, limited lifetimes, and explicit revocation paths. The core control is not whether the agent can authenticate, but whether its access is bound to a specific user intent and a specific action set. High-risk actions should require fresh approval, and every agent identity should be inventoried and owned.

Q: What is the difference between OAuth and token exchange for AI agent access?

A: OAuth establishes the initial delegated authorization from the user to the agent. Token exchange then lets that agent obtain another token for a different service or audience without repeating the entire consent flow. OAuth creates the first trust boundary, while token exchange extends that trust across services. Both need strict scope, audience, and expiration limits.

Q: When does AI agent convenience become an access control risk?

A: Convenience becomes a risk when faster integration weakens consent, MFA, scope limits, or auditability. If an agent can act with a broadly scoped token, register itself automatically, or bypass normal user verification for sensitive actions, the organization has traded usability for hidden privilege expansion. The right threshold is whether the agent can be constrained as tightly as any other NHI.

Q: Should organisations allow AI agents to register clients dynamically?

A: Only if registration is gated by policy, ownership, and lifecycle controls. Dynamic client registration can reduce manual work, but it also creates new identities automatically, which means the organization must know who approved them, what they can do, and when they should be removed. Without that control, registration becomes an identity sprawl problem.

Technical breakdown

Why OAuth becomes the default control plane for AI agents

OAuth is designed for delegated access, which is why it fits AI agents better than shared credentials or direct user logins. The agent can receive a time-limited access token with a constrained scope, while the user keeps their primary authentication method. That matters because the security model shifts from identity reuse to bounded delegation. In practice, the service must define which actions an agent may perform, which endpoints require fresh consent, and how token lifetime maps to task duration. Without that discipline, an agent becomes a convenient path to over-privileged access.

Practical implication: Treat OAuth scope design as an NHI control, not just an app integration detail.

How token exchange changes multi-service agent workflows

Token exchange lets an agent trade one valid credential for another credential that is accepted by a different service. Architecturally, that can reduce repeated user prompts when an agent needs to touch several systems to complete one task. The risk is trust propagation: each hop extends the original delegation chain, so the weakest service in the sequence can widen the effective blast radius. The control question is whether every exchanged token preserves the same user intent, scope, and expiry constraints. If it does not, the chain becomes a privilege amplification path rather than a user experience improvement.

Practical implication: Map every token hop and require that each exchange preserve scope, audience, and expiration.

Why dynamic client registration raises both scale and governance pressure

Dynamic client registration allows a service or gateway to onboard an agent automatically instead of through manual provisioning. That helps with scale, but it also changes who gets to exist as an authenticated client in the first place. In NHI terms, registration becomes identity creation, so the control plane must decide which trusted entity may register the agent, what metadata is required, and how the client is later revoked. If registration is automated without governance, the environment can accumulate unreviewed agent clients faster than teams can track them.

Practical implication: Require policy checks and ownership data before any agent client is registered.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 agent access should be governed as delegated NHI, not as a smarter browser session. The article's core insight is that agents need to act, not just recommend. That means the identity model must account for execution authority, not only authentication. Teams that keep treating agents as a UI convenience will underdesign scope, expiry, and reauthorization controls. The practical conclusion is to manage agent access with the same rigor used for other high-trust NHIs.

OAuth is the right baseline, but only if teams design it for task-scoped privilege. A token that is technically delegated can still be operationally excessive if the scope is broad or the lifetime is too long. The article correctly points to time-bound access and user consent, but practitioners should go further and tie authorization to task context, sensitive-action step-up, and explicit revocation. The practical conclusion is to make delegated access ephemeral by design.

Dynamic client registration creates an identity lifecycle problem, not just an onboarding shortcut. Automation helps agents connect at scale, but automated creation without lifecycle control produces hidden clients that survive beyond their intended purpose. That is classic NHI sprawl in a new form. Teams should expect agent identities to multiply quickly and should build approval, inventory, and cleanup into the registration process. The practical conclusion is to govern agent identity from creation to retirement.

AI gateways may centralize enforcement, but they do not remove the need for per-service authorization logic. A gateway can normalize access, logging, and policy enforcement at the edge, yet downstream services still need to decide what an agent may do once it arrives. The governance trap is assuming the gateway replaces service-level authorization. It does not. The practical conclusion is to pair gateway controls with API-specific policy checks and audit trails.

Agentic AI will expose the weakest parts of existing identity programs first. Where MFA, passkeys, or user-centric workflows cannot be applied cleanly, teams may be tempted to bypass them for agent convenience. That is how security regressions happen. The right response is not to weaken controls for usability, but to redesign delegated access patterns so that automation inherits the security posture rather than escaping it. The practical conclusion is to treat agent integration as a control redesign exercise.

From our research:

• 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%), 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.
• That visibility gap makes OWASP NHI Top 10 a useful forward reference for teams formalizing agent governance.

What this signals

Agentic access is becoming a lifecycle problem, not a point-in-time authorization problem. If agents can register, exchange tokens, and act through APIs or user interfaces, then the real control failure is inventory and revocation, not just login. Teams should assume agent identities will accumulate faster than traditional app clients and build ownership, expiry, and cleanup into the operating model. This is the kind of sprawl that turns delegated access into standing risk.

With 92% of organisations agreeing that governing AI agents is critical, yet only 44% having implemented policies, the issue is no longer awareness but execution. The practical programme gap is the same one seen in other NHI domains: discovery outruns governance. Teams should align agent controls with the NIST AI Risk Management Framework and define who can create, approve, and retire agent identities.

Ephemeral credential trust debt: every shortcut that lets an agent authenticate faster can also make later review harder. If your team cannot explain which user authorized which action, through which token, and under what scope, the environment is already drifting beyond auditable trust. That is the point to introduce tighter policy, not looser UX.

For practitioners

• Define agent-specific OAuth scopes Break agent privileges into task-scoped permissions, then separate read, write, and transaction actions so a single token cannot unlock unnecessary operations.
• Require step-up approval for sensitive actions Force reauthorization for actions such as payments, data modification, or account changes so the agent cannot execute high-risk tasks on a standing token.
• Track every token exchange hop Record the originating user, the exchanged token audience, and the receiving service so you can audit how delegated access moved across systems.
• Control dynamic client registration with policy Allow agent onboarding only through approved trust anchors, require owner metadata, and revoke unused client registrations on a fixed review cycle.
• Plan for non-API agent access paths Monitor user-interface based interactions as well as API calls so agents that do not use formal APIs still appear in access logs and governance workflows.

Key takeaways

• AI agents expand the NHI problem because they need delegated access that is constrained by time, scope, and action type.
• The biggest operational risk is not that agents exist, but that they can multiply trust through token exchange, dynamic registration, and weak visibility.
• Teams should treat agent governance as an identity lifecycle discipline, with ownership, revocation, and step-up controls built in from the start.

Key terms

• AI Agent: An AI agent is an autonomous software entity that can take actions, call tools, and make execution decisions on behalf of a user or system. In identity terms, it behaves like a non-human identity with delegated authority, which means its permissions, scope, and lifecycle must be governed explicitly.
• Token Exchange: Token exchange is a delegation pattern where one valid credential is swapped for another that is accepted by a different service or audience. It helps agents move across systems without repeating user consent, but it also extends trust, so each hop must preserve scope, expiry, and purpose.
• Dynamic Client Registration: Dynamic client registration is a protocol pattern that allows a software client to register itself with an authorization system automatically. For AI agents, it can reduce manual setup, but it also creates new identities at speed, which makes ownership, policy checks, and revocation essential.
• Step-up Authorization: Step-up authorization is a control that requires additional verification before a sensitive action is allowed. In agentic environments, it prevents a broadly delegated token from being used for high-risk tasks such as payments, data changes, or access expansion without fresh consent.

Deepen your knowledge

AI agent identity governance and delegated access controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agentic workflows, the course maps the identity lifecycle choices that matter most.

This post draws on content published by Curity: AI agents and security considerations for API integration. Read the original.