Agent-to-agent OAuth and MCP change AI agent identity governance

At a glance

What this is: This guide explains how MCP and OAuth combine to let AI agents connect securely to apps through scoped, revocable authorization rather than shared credentials.

Why it matters: It matters because identity teams now have to govern AI agents as first-class non-human actors, with consent, scope, revocation, and monitoring controls that go beyond human login design.

By the numbers:

• 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.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Stytch's guide to agent-to-agent OAuth and MCP identity flows

Context

Agent-to-agent OAuth is the authorization pattern that lets an AI agent act on a user’s behalf without handling the user’s password or a long-lived API key. In practice, MCP provides the connection layer and OAuth provides the delegated access model, which makes AI agent identity governance a problem of scoped permissioning, token lifecycle, and revocation.

For IAM teams, the important shift is that AI agents are no longer just another integration endpoint. They are active identities with their own tokens, consent flows, and policy boundaries, so the governance model has to extend from human SSO into non-human identity management, token monitoring, and access review.

Key questions

Q: How should security teams govern AI agents that use OAuth to access APIs?

A: Treat each agent as a distinct non-human identity with its own owner, scopes, consent record, and revocation process. Use short-lived tokens, validate every request, and review access by application and business purpose, not by the assumption that the agent behaves like a normal app integration.

Q: Why do AI agents complicate existing IAM and access review processes?

A: Because agents can obtain and use privileges continuously, while many IAM controls assume access is stable long enough to be reviewed by a human. That assumption breaks when the access path is token-based, dynamic, and tied to runtime decisions rather than a fixed user session.

Q: What do organisations get wrong about OAuth for AI agent connectivity?

A: They often treat OAuth as a login feature instead of a delegated authorisation model with lifecycle obligations. The common mistake is trusting the initial consent step and then failing to monitor token scope, token rotation, revocation, and connected-app ownership over time.

Q: Who is accountable when an AI agent misuses delegated access?

A: Accountability usually sits with the organisation that approved the connection, the team that owns the connected application, and the operator responsible for the agent’s lifecycle. In practice, if no one owns the scopes and revocation path, accountability is effectively absent even if the token was technically valid.

Technical breakdown

How MCP discovery and OAuth handoff work for AI agents

MCP uses discovery metadata so an agent can find the authorization server, token endpoint, and registration endpoint without hard-coded configuration. That discovery step is what makes agent connectivity scalable, because the agent can bootstrap trust dynamically before requesting access. OAuth then supplies the actual authorization grant, usually through authorization code flow with PKCE for public clients. The important architecture point is that MCP moves the transport and tool-calling problem, while OAuth carries the security state. The agent is not trusted because it can reach an API. It is trusted only after the token is issued, scoped, and validated against the expected issuer, audience, and expiry.

Practical implication: treat MCP as the connection layer and OAuth as the control layer, and validate both before allowing an agent to call production APIs.

Why scoped tokens are safer than API keys for agent connectivity

API keys are static secrets, so they tend to persist far beyond the task that justified them. OAuth access tokens are different because they are scoped, time-limited, and revocable, which fits the temporary and task-bounded nature of agent work. In an agent-to-agent model, that matters because the agent should inherit only the access needed for the approved action, not the full privileges of the user or integration owner. This is where least privilege becomes enforceable at runtime. The same design also supports user consent and administrative policy, which means access can be limited by scope rather than by trust in the agent itself.

Practical implication: replace shared API keys with scoped OAuth grants anywhere an agent can reach customer or internal APIs.

What token lifecycle controls matter most for agent governance

Token lifecycle is the real governance boundary in agent-to-agent access. Issuance, validation, refresh, and revocation all need to be explicit because agents can act continuously and repeatedly once connected. Short-lived access tokens reduce blast radius, refresh token rotation limits replay risk, and revocation must be operationally available when an agent is compromised or its purpose changes. Validation also cannot be optional, because every request should prove the token is still valid and still scoped for the action being attempted. Without that, an agent can drift from intended use into unauthorized access even when the original consent looked correct.

Practical implication: build every agent integration around short-lived tokens, refresh rotation, and immediate revocation paths.

NHI Mgmt Group analysis

OAuth for AI agents is now an NHI governance problem, not just an application integration pattern. The guide is correct to frame tokens, consent, and revocation as the core trust boundary. Once an agent receives its own scoped credential, it is operating as a non-human identity with distinct lifecycle requirements. The implication is that identity programmes need one governance model for human users, service accounts, and agent-driven access paths.

Scoped tokens are the only practical alternative to credential sharing for agent connectivity. The article’s strongest security point is that agents should never receive passwords or raw API keys when delegated access is the objective. That shifts the control focus to token scope, expiry, and revocation rather than static secret handling. Practitioners should treat every agent integration as an access boundary that can expand or shrink at runtime.

Agent connectivity exposes a runtime policy gap that many IAM programmes still ignore. Discovery and dynamic client registration make it easy for an agent to appear, but they do not by themselves establish business approval, ownership, or auditability. That leaves a named governance gap we call self-service agent trust debt: the longer dynamic connections remain unmanaged, the more the environment accumulates opaque, revocable-but-unreviewed access paths. Practitioners need policy, visibility, and lifecycle ownership before scale turns convenience into sprawl.

MCP standardization reduces tool fragmentation, but it also raises the bar for control consistency. The benefit is that agents no longer need a different auth pattern for every service. The downside is that one weak policy or weak token-validation implementation can now repeat across many agent connections. Identity teams should standardize the control model before they standardize the integrations.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• That visibility gap is why lifecycle and rotation guidance in the Ultimate Guide to NHIs , 2025 Outlook and Predictions matters for agent-connected access as well.

What this signals

With 52% of companies able to track and audit the data their AI agents access, the governance baseline is already uneven, and that gap will widen as agent deployments scale. The control question is no longer whether agents can connect through MCP, but whether the organisation can explain, review, and revoke every connected path before it becomes operational debt.

Self-service agent trust debt: dynamic registration and delegated tokens can create a growing inventory of connected clients that nobody actively owns. Identity teams should expect connected-app sprawl to mirror the old service-account problem unless ownership, scope review, and revocation are tied into the same programme. For framework alignment, the runtime verification model in NIST AI Risk Management Framework is the more relevant lens than static authentication alone.

For practitioners

• Inventory every AI agent as a governed identity Record each agent, the apps it can reach, the scopes it has, the owner responsible, and the revocation path. If an agent cannot be mapped to a human or system owner, it is already outside governance.
• Replace static secrets with scoped OAuth grants Eliminate API keys where an agent can use authorization code flow with PKCE, short-lived access tokens, and refresh token controls. Scope grants to the minimum API operations needed for the task, not the broader account.
• Enforce token validation on every agent call Validate issuer, audience, expiry, and scopes on each request, not just at initial login. If the token cannot be checked continuously, the agent can outlive the security decision that created it.
• Build a revocation and offboarding path for agents Make it possible to disable an agent token instantly when ownership changes, behaviour drifts, or a connected app is no longer approved. Offboarding should remove connected access, not just disable a user-facing login.

Key takeaways

• AI agent connectivity through MCP and OAuth turns delegated access into an identity governance issue, not just an authentication pattern.
• Scoped, revocable tokens materially reduce risk versus shared secrets, but only if validation, refresh, and revocation are enforced end to end.
• Without explicit ownership and lifecycle control, agent connections become self-service trust debt that IAM teams will eventually have to unwind.

Key terms

• Agent-to-Agent OAuth: An authorization pattern where an AI agent uses OAuth tokens to act on behalf of a user or application without receiving the underlying password or raw secret. In practice, it creates a delegated access path that can be scoped, monitored, and revoked like any other non-human identity.
• Dynamic Client Registration: A mechanism that lets a client register itself with an authorization server at runtime instead of being manually preconfigured. For AI agents, this supports scale, but it also creates governance pressure because new identities can appear quickly unless policy, ownership, and logging are enforced.
• Token Lifecycle: The full sequence of token issuance, validation, refresh, and revocation that determines whether delegated access remains legitimate. For AI agents, the lifecycle is the real control surface because long-running or autonomous behaviour can outlast the security decision that granted the token.
• MCP Discovery: The process by which an AI agent finds an MCP server’s authorization and tool-endpoint metadata before making a connection. It reduces integration friction, but it also means the environment must treat discoverability as part of the trust chain, not just a convenience feature.

What's in the full article

Stytch's full guide covers the operational detail this post intentionally leaves for the source:

• Node.js implementation examples for agent-to-agent OAuth flows with MCP.
• Discovery, dynamic client registration, and token exchange details for connected apps.
• Token validation, refresh, revocation, and policy enforcement guidance for production deployments.
• Practical options for aligning agent access with admin policies and consent screens.

👉 Stytch's full guide covers the Node.js flow, token lifecycle, and policy controls in implementation detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.