TL;DR: Remote MCP servers commonly force AI agents to store delegated OAuth access tokens in plaintext memory, configuration, or environment variables, creating a replayable credential target even when short TTLs are used, according to Riptides. The security problem is not token format but trust placement: agents should not hold the credential that actually grants access.
At a glance
What this is: This is an analysis of remote MCP OAuth flows and the finding that delegated access tokens end up stored inside agent runtime surfaces where they can be replayed if the process is compromised.
Why it matters: It matters because identity teams need to treat agent-to-tool OAuth as a non-human identity problem, where token custody and injection point matter more than token format or short TTLs.
Context
Remote MCP OAuth flows give third-party MCP servers a standard way to authenticate agents through OAuth 2.0, but the design assumes the client can safely hold the resulting token. In practice, agent frameworks often place that token in process memory, configuration, or environment variables, which turns delegated access into a replayable credential problem.
For IAM and NHI programmes, that is not just an implementation nuisance. It is a trust-boundary issue: the identity that is acting on behalf of the user is not the same thing as the credential that authorises the request, and letting the agent keep both collapses the security boundary.
The article is about remote MCP servers, not local workload identity inside a single managed platform. That makes the exposure more representative of the current agentic integration pattern across SaaS tools, productivity services, and data sources.
Key questions
Q: What breaks when remote MCP agents store OAuth tokens locally?
A: The security boundary breaks when the agent stores the same bearer token that can be replayed against the MCP server. A compromised process, poisoned prompt, or exposed config file can yield delegated access directly, so local token custody turns an identity flow into a credential theft problem rather than a pure authorization problem.
Q: Why do coarse OAuth grants and standing integration tokens create so much risk for AI agents?
A: Coarse OAuth grants create risk because they authorize every future call the integration can make, often for an entire API surface. If a token is stolen or misused, an agent or attacker can query, export, or mutate data at scale without reapproval. The danger is scope and duration, not just credential theft, so per call controls matter.
Q: How should teams reduce token replay risk in MCP servers that rely on OAuth access tokens?
A: Teams should move away from bearer-only assumptions and bind access tokens to proof of possession. In MCP, that means using DPoP so each request proves the caller still holds the private key associated with the token. This reduces the value of leaked logs, environment variables, and copied tokens because the token alone is no longer enough to call the server.
Q: What is the difference between a proxy JWT and a real MCP access token?
A: A proxy JWT is only meaningful inside the local control plane, while a real MCP access token is accepted by the remote resource server. Keeping those two credentials separate lets the system authenticate the workload without letting the agent hold a portable credential that can be replayed elsewhere.
Technical breakdown
How OAuth discovery turns into token custody for remote MCP
Remote MCP servers use OAuth 2.0 protected resource metadata to tell the client where to authenticate, then the client follows authorization server metadata, registration, and the authorization code flow. That sequence is standard, but the security consequence is not: once the flow completes, the client holds a bearer token that represents delegated user access. In agent frameworks, the token is commonly stored in memory or configuration because the agent is treated as the requester and the holder of record. That is where the identity risk begins, because bearer tokens do not prove which runtime instance currently possesses them.
Practical implication: treat OAuth token custody as part of the identity design, not an implementation detail.
Why plaintext token storage creates a replayable identity target
A plaintext OAuth token inside an agent process is functionally similar to any other exposed secret. If an attacker gains code execution, prompt injection leverage, or process-level access, they can extract the token and replay it directly against the MCP server until it expires. Short TTLs reduce exposure but do not remove it, because the token still grants usable delegated access during its lifetime. This is the same trust model failure seen across NHI environments: the credential exists in a place the attacker can reach if the workload is compromised.
Practical implication: assume any token available to the agent is recoverable under compromise unless custody is moved elsewhere.
Why kernel-level injection changes the trust boundary
The article’s key architectural move is to separate the token the agent stores from the token that actually authorises the request. The agent receives a proxy JWT that is valid only inside the local control plane, while the real access token stays in the kernel and is injected at request time. That means the agent can participate in OAuth without being the long-term holder of the credential that grants access. For identity governance, this is important because the authorising credential moves closer to the enforcement point, where the workload identity and user context can both be checked before use.
Practical implication: push credential possession down to the enforcement layer when an agent does not need direct access to the real token.
Threat narrative
Attacker objective: The attacker wants to steal and replay the agent’s delegated OAuth token to access remote MCP resources as the user.
- Entry occurs when a remote MCP integration completes the OAuth authorization code flow and places the delegated access token into the agent runtime.
- Credential access follows when the token is exposed through plaintext memory, configuration files, or environment variables accessible to the compromised process.
- Impact occurs when the attacker replays the stolen bearer token directly against the MCP server and inherits the user’s delegated access until expiry.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Remote MCP OAuth is an NHI custody problem, not an OAuth formatting problem. The central issue is not whether the flow follows the spec, but whether the agent is ever allowed to hold the credential that grants access. Once a bearer token lives inside the workload, the identity boundary has already shifted into a compromise-ready state. Practitioners should evaluate where custody sits, not just whether authentication is standards-compliant.
Plaintext token storage creates credential replay debt. Short-lived tokens reduce exposure windows, but they do not change the fact that the agent is holding a usable secret. That is the same persistence pattern NHI governance tries to eliminate in service accounts and API keys. The practical conclusion is that lifecycle controls have to be paired with custody controls, or the attack surface simply moves from static secrets to short-lived ones.
Delegated access for agents should be enforced at request time, not granted as portable possession. The article’s kernel-level injection model shows why the strongest control is not token rotation but token non-possession. When the real credential never leaves the enforcement boundary, compromise of the agent no longer yields the object an attacker actually wants. That is a more durable identity posture for remote MCP than any storage hardening alone.
Ephemeral credential trust debt: this pattern names the gap between short token lifetime and unsafe token custody. The credential may expire quickly, but the trust debt remains until the agent is prevented from possessing the real access token. That is the governance problem practitioners now need to design around.
Agentic OAuth needs an enforcement model that binds user, workload, and request path together. The important shift is that the acting identity is not enough by itself. The system must verify which workload is requesting the action, which user delegated it, and where the token will be injected before the request leaves the host. That makes request-time binding the real control plane concern.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
- Read next: MCP Security Guide
What this signals
Ephemeral credential trust debt: remote MCP integrations can shrink token lifetime without shrinking the core exposure problem. If the agent still possesses the real token, the organisation still has a replayable secret inside an NHI runtime, which means governance has to focus on custody and enforcement location, not just expiry.
Agents that connect to external MCP servers will increasingly force security teams to treat OAuth metadata, client registration, and token handling as one identity-control path. The useful question is no longer whether the flow is standard, but whether the workload ever becomes the durable holder of the authority it uses.
For programme owners, this is where secrets management, workload identity, and access governance converge. If the credential leaves the enforcement boundary, the identity model is already too permissive for agentic use cases.
For practitioners
- Map token custody points in every remote MCP integration Identify where agents store delegated OAuth tokens in memory, config, subprocess environments, or files, then classify each location as a replay surface rather than a harmless cache.
- Separate the acting identity from the usable credential Design flows so the agent can complete OAuth without receiving the real access token as a portable secret, and prefer brokered or injected credential handling where possible.
- Bind request-time authorization to workload and user context Require the enforcement layer to verify both the workload identity and the delegated user before replacing any proxy credential with the real one.
- Treat short TTLs as exposure reduction, not containment Use expiry and refresh rotation to limit blast radius, but do not rely on them to solve replay risk when the agent still holds a usable bearer token.
- Review third-party MCP servers as shared trust boundaries Assume the remote server, its OAuth metadata, and the client registration path can all influence the final trust model, especially when agents connect to multiple external tools.
Key takeaways
- Remote MCP OAuth flows can turn delegated access into a replayable credential problem when the agent stores the real token in its own runtime surfaces.
- Short TTLs reduce exposure time, but they do not change the fact that a bearer token inside the agent is still a usable secret.
- The strongest control is to separate token possession from token use so the agent can authenticate without ever holding the credential that grants access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Remote MCP OAuth flows rely on token handling that can expose agent-held credentials. |
| NHI-02 — Secret Leakage | The article centres on tokens stored in memory, config, and environment variables. | |
| NHI-07 — Long-Lived Secrets | Even short-lived bearer tokens remain risky if the agent can replay them before expiry. | |
| Recommendation — Separate agent participation in OAuth from possession of the real access token. Eliminate token exposure in agent runtime surfaces and move credential use to enforcement. Treat token lifetime as exposure reduction, not as a substitute for custody control. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent-held delegated tokens let compromised runtimes abuse user-granted authority. |
| Recommendation — Bind agent actions to workload and user context before allowing privilege use. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential storage, renewal, and replacement are central to the remote MCP token problem. |
| Recommendation — Manage OAuth tokens as authenticators and keep them out of agent-accessible storage. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The attacker objective is to extract and replay delegated tokens from the agent process. |
| Recommendation — Hunt for credential access paths that expose bearer tokens in agent runtimes. | ||
| NIST Zero Trust (SP 800-207) | 3e — Continuous Verification | Request-time replacement depends on continuous verification of workload and user context. |
| Recommendation — Apply continuous verification before injecting the real credential into outbound requests. | ||
Key terms
- MCP-Connected OAuth Flow: An MCP-connected OAuth flow is an authorization pattern used when AI agents, tools, or other dynamically discovered services need to authenticate and request access through OAuth. These flows benefit from machine-readable client metadata because participants may be created, updated, or validated programmatically instead of through static app registration.
- Token Custody: The control responsibility for where access tokens and refresh logic live, who can retrieve them, and how they are retired. In delegated integrations, token custody is often moved out of the app, but security ownership does not disappear. It shifts to the broker and the governance model around it.
- 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.
- Proxy Credential: A token that can be stored by the client but is only meaningful inside a local control boundary. In this article's context, a proxy credential lets the agent complete OAuth without ever holding the real access token that remote servers would accept.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org