Securing remote MCP OAuth flows for AI agent identities

At a glance

What this is: This is an analysis of how remote MCP OAuth flows expose delegated access tokens to AI agents and why that creates a replayable credential risk.

Why it matters: It matters because IAM teams now have to govern agent-held credentials, delegated access, and request-time enforcement as one identity problem across NHI, autonomous, and human workflows.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 69% of organisations now have more machine identities than human ones.

👉 Read Riptides' analysis of securing OAuth flows for remote MCP agent identities

Context

Remote MCP integrations create a plain identity problem before they create a protocol problem. The agent completes a standard OAuth2 flow, receives a delegated access token, and then has to store that credential somewhere in its runtime environment, which makes the token part of the workload's attack surface.

That storage model is the weak point. If the agent process is compromised, the attacker does not need to break OAuth, they inherit the delegated trust already sitting in memory or on disk. For NHI governance, this is a familiar failure pattern: the credential is valid, the holder is not trustworthy.

Riptides frames one answer by interposing a control plane between the agent and the real authorization server, so the agent stores only a system-issued JWT while the real token stays outside user space. The larger lesson is that agentic workflows now need request-time enforcement and credential binding, not just stronger login screens.

Key questions

Q: How should security teams handle delegated OAuth tokens for AI agents?

A: Security teams should keep the real access token out of the agent runtime entirely. The safer pattern is to let the agent complete the flow but store only a non-replayable proxy credential, while the real token is injected or exchanged at request time under workload and user binding. That reduces the chance that process compromise turns into credential replay.

Q: Why do remote MCP OAuth flows increase NHI risk?

A: Remote MCP flows increase NHI risk because they turn a delegated bearer token into something the workload must store and reuse. Once the token sits in agent memory, a compromised process can replay it against the target service. The risk is not simply exposure time, but the fact that possession equals authorisation until expiry.

Q: What breaks when an AI agent stores its own access token?

A: What breaks is the trust boundary. The agent becomes both the authorised actor and the credential vault, so any compromise of the process can expose the token and the permissions attached to it. That collapses the separation between use and custody, which is exactly what identity governance is supposed to preserve.

Q: Who should own governance for AI agent credential custody?

A: Ownership should sit with IAM, PAM, and platform security together, because the issue spans identity lifecycle, privileged credential handling, and workload execution. Teams should govern where the token lives, how it is bound to the process, and whether the runtime can replay it outside the intended request path.

Technical breakdown

How remote MCP OAuth discovery creates a token custody problem

Remote MCP servers use OAuth discovery metadata so a client can find the correct authorization server, register itself, and run the authorization code flow. In practice, that means the agent ends up with a bearer token after authentication. Bearer tokens are possession-based credentials: whoever has them can replay them until they expire. Once a token is placed in agent memory, environment variables, or config files, the security boundary shifts from the protocol to the runtime. The protocol can be standards-compliant and still leave a custody problem behind.

Practical implication: treat token custody as an identity control point, not a storage detail, and remove bearer secrets from agent-accessible runtime locations.

Why kernel-level credential injection changes the trust model

Kernel-level credential injection separates the credential the agent stores from the credential that actually reaches the MCP server. The agent presents a short-lived proxy token, while the kernel resolves that token to a real access token only at request time. That means the sensitive credential never enters user space, never sits in a file the agent can read back, and never becomes a reusable artefact for an attacker who compromises the process. The important architectural shift is that authorisation becomes bound to the calling workload and execution context rather than to whatever the agent can persist.

Practical implication: design for request-time credential substitution where the real token is bound to workload identity and never exposed to the process itself.

Why short TTLs do not solve delegated agent access

Short token lifetimes reduce exposure, but they do not remove it. A one-hour token is still replayable for one hour, and refresh token rotation only narrows the window. For remote MCP use cases, the issue is not just duration, it is replayability and provenance. If the agent is compromised, the attacker can use the token exactly as the legitimate process would. In other words, lifetime controls limit blast radius, but they do not stop an exposed bearer credential from being an exposed bearer credential.

Practical implication: pair short lifetimes with holder binding and runtime enforcement, because expiry alone does not neutralise delegated token theft.

Threat narrative

Attacker objective: The attacker wants to replay the agent's delegated access token to reach the remote MCP server and use the user's granted permissions without re-authentication.

1. Entry occurs when the agent stores a delegated OAuth access token in memory, configuration, or environment variables after a standard remote MCP login flow.
2. Credential access happens when prompt injection, framework compromise, or process compromise exposes that token to an attacker who can replay it as a bearer credential.
3. Impact follows when the attacker uses the stolen token to access the remote MCP server and act with the user's delegated trust until the token expires.

Breaches seen in the wild

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

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Bearer-token custody is the real control failure in remote MCP agent flows: the protocol can be standard-compliant and still unsafe when the agent becomes the place where delegated access is stored. The weakness is not OAuth itself, but the assumption that a process holding a token is an acceptable trust boundary. Practitioners should treat agent-held bearer tokens as a governance failure, not just a storage convenience.

Agentic access amplifies a classic NHI pattern rather than inventing a new one: a credential that can be copied, replayed, and reused is still a standing privilege problem even when the subject is an AI agent. The agent may be the actor, but the security consequence is the same as with any exposed NHI secret. The implication is that access governance must follow the token to the runtime, not stop at authentication.

Runtime-bound delegation is becoming the named control concept for MCP-era identity: the useful unit of control is not the token alone, but the link between workload identity, user identity, and request-time enforcement. That linkage narrows where trust can accumulate and makes credential theft materially harder to turn into access. Practitioners should reframe agent access reviews around custody, binding, and replayability rather than around login success.

Kernel mediation is a governance pattern, not just an implementation detail: by keeping the real token out of user space, the model removes the most fragile assumption in agentic OAuth flows, which is that the agent can safely possess what it can use. That assumption already failed for service accounts and API keys; remote MCP simply exposes the same flaw in a new runtime. The implication is that identity programmes need controls that distinguish possession from permission.

Access review cycles miss ephemeral credential exposure unless the exposed secret is never present in the first place: if a delegated token can be extracted and replayed within the agent's runtime, certification after the fact cannot undo the exposure. This is a lifecycle problem as much as a security one, because the credential outlives the context that created it. Practitioners should treat agent token custody as part of lifecycle governance, not an afterthought.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, 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 is why OWASP Agentic AI Top 10 and 52 NHI Breaches Analysis both point practitioners toward runtime containment rather than post-event review.

What this signals

Runtime-bound delegation: remote MCP workflows are pushing identity teams toward controls that bind workload, user, and request together at the moment of use. That changes the operating model from static token custody to runtime enforcement, which is where agentic risk now lives.

With 66% of identity experts already perceiving machine identities as posing higher security risks than human identities in The Critical Gaps in Machine Identity Management report, agent-held OAuth tokens are best understood as another machine identity custody problem, not a niche protocol issue.

Security teams should expect more products to hide credentials behind mediation layers and kernel or service-side injection, because the alternative is a growing class of bearer-token replay. The practical question is whether your governance model can prove where the real credential lives at any point in time.

For practitioners

• Remove bearer tokens from agent-accessible storage Move remote MCP credential handling to request-time injection or other server-side mediation so the agent never persists the real access token in memory, config files, or environment variables.
• Bind delegated access to workload and user identity Require a stable workload identity and a user context for every token lookup so the real credential is only released for the exact process and user combination that earned it.
• Treat refresh tokens as privileged NHI artefacts Store refresh tokens outside the agent runtime, rotate them under controlled policy, and assume they are equally sensitive because they extend replayable access beyond the initial token lifetime.
• Rework access reviews around custody, not login events Review where delegated credentials live, who can retrieve them, and whether the runtime can exchange a harmless proxy token for the real secret without exposing it to the workload.

Key takeaways

• Remote MCP OAuth flows can turn AI agents into holders of replayable delegated credentials, which is an identity governance problem as much as a security one.
• The evidence across agentic and machine identity research shows that exposed credentials and out-of-scope actions are already common enough to justify runtime controls now.
• Practitioners should prioritize credential custody, workload binding, and request-time enforcement over relying on token lifetime alone.

Key terms

• Bearer Token Custody: Bearer token custody is the question of where a token exists, who can read it, and whether it can be copied into a different context. In agentic systems, custody is as important as authorisation because a token that can be replayed becomes a reusable credential.
• Runtime-bound Delegation: Runtime-bound delegation is an identity pattern where permission is resolved at the moment a request is made, using workload identity and user context together. The goal is to keep the real credential out of the workload while still allowing the workload to act on behalf of an authenticated user.
• Credential Injection: Credential injection is the controlled replacement of one credential with another at execution time, usually before a request leaves the host or service boundary. It lets the workload operate with a harmless token or placeholder while the real secret remains protected by infrastructure.
• Replayable Credential: A replayable credential is any secret that can be stolen once and reused by an attacker without the original process or user being present. Bearer tokens, API keys, and many agent-stored access tokens fit this pattern unless they are bound to context or mediated at runtime.

Deepen your knowledge

Remote MCP OAuth custody and workload-bound credential handling are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI agents that must authenticate without holding the real secret, this is a relevant starting point.

This post draws on content published by Riptides: Securing Agentic OAuth Flows with Riptides. Read the original.