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.
Why local OAuth custody changes the trust model for remote MCP agents
remote mcp works cleanly only when the server remains the authority for who can act, and the client or agent merely presents a token it does not fully own. Once the agent stores that bearer token locally, the boundary shifts: the local runtime becomes a credential holder, and compromise of the agent process or its files can become direct replay against the MCP server.
That change matters because OAuth access tokens are designed to carry delegated authority, not to be treated as harmless configuration data. If the same token can be reused without proof of possession or audience binding, then the agent host inherits the blast radius of a stolen secret, not just the permissions of a bounded session.
In practice, this is why sender-constrained token patterns and audience-restricted access matter so much for remote tool access. RFC 6749: The OAuth 2.0 Authorization Framework defines the delegated access model, while Model Context Protocol: Authorization specification and related OAuth guidance show why the server should remain the control point for token validation and scoping.
What becomes vulnerable when the token lives on the agent host?
Local custody turns the token into an object that can be copied, cached, logged, exfiltrated, or reused outside the intended runtime path. A poisoned prompt, malicious extension, exposed config file, memory dump, or compromised container can all become viable theft paths, because the bearer token is enough to impersonate the agent to the MCP server.
The practical failure mode is not just “someone read a secret.” It is that the server can no longer distinguish legitimate agent use from replay by an attacker who has the token. That is why local storage is much closer to credential theft than to a pure authorization decision, especially when long-lived or refresh-capable credentials are involved.
Where bearer semantics are unavoidable, constraining replay becomes the design priority. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession and RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens both exist to reduce the value of a stolen token by binding it to a holder or client channel.
How should practitioners design remote MCP auth so local storage does not become the weak link?
The safest pattern is to keep tokens off the agent filesystem where possible and prefer short-lived, audience-bound credentials with clear rotation and revocation paths. When a token must exist locally, treat the host as part of the trust boundary, and assume prompt injection, process compromise, and file disclosure are realistic failure paths rather than edge cases.
RFC 9700: Best Current Practice for OAuth 2.0 Security reinforces the need to reduce token replay value, while RFC 8707: Resource Indicators for OAuth 2.0 helps narrow what a token can be used for. For MCP deployments, the authorization design should make the server enforce scope and audience, not rely on the agent to behave correctly.
Risk and Threat Considerations
Local token storage creates a high-value theft target because any compromise of the agent runtime can immediately become remote API access. The same design also increases the chance of silent abuse, since a stolen bearer token often looks indistinguishable from legitimate delegated use until the token is revoked or expires.
Failure mechanism: The agent host, config layer, or prompt-processing path leaks a bearer token that can be replayed directly against the MCP server, bypassing the intended runtime boundary.
Impact: Attackers can gain delegated access, exfiltrate data, invoke tools, or continue access until the token is rotated, expired, or invalidated.
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 API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers token lifecycle, rotation, and revocation for bearer credentials used by MCP agents. |
| Recommendation — Rotate, revoke, and expire MCP bearer credentials aggressively. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Local token storage can expose bearer material through files, logs, memory, or config paths. |
| NHI-07 — Long-Lived Secrets | Bearer tokens become more dangerous when local storage lets them survive too long. | |
| NHI-05 — Overprivileged NHI | A replayable MCP token is especially harmful when its scopes are broader than needed. | |
| Recommendation — Keep MCP tokens out of local files, logs, and crash artifacts. Use short-lived MCP credentials and rotate anything that must persist. Reduce MCP token scopes so replay yields only limited access. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Stolen local tokens can be replayed to impersonate the agent to the MCP server. |
| API5 — Broken Function Level Authorization | MCP tool calls must still be authorized even if a token is presented locally. | |
| API8 — Security Misconfiguration | Weak token handling, logging, or persistence can expose credentials on the agent host. | |
| Recommendation — Reject bearer-token designs that allow replay without holder binding. Enforce authorization on each MCP tool and action, not just token presence. Harden MCP client storage, logging, and runtime settings to avoid token exposure. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Local bearer-token storage is a classic credential exposure condition that attackers seek. |
| T1528 — Steal Application Access Token | An exposed MCP bearer token can be stolen and reused for remote access. | |
| T1056.001 — Keylogging | Prompted or interactive token entry on the host can be captured by malware or abuse tooling. | |
| Recommendation — Hunt for exposed MCP tokens in files, memory, and developer tooling artifacts. Detect and disrupt theft paths that copy MCP access tokens from agent hosts. Avoid workflows that require manual token entry on an exposed agent host. | ||
Practitioner Guidance
What to verify: Confirm whether the MCP client ever persists refresh tokens, access tokens, or equivalent bearer material to disk, logs, crash reports, or shell history. If it does, treat that storage path as part of your security boundary and review it like any other credential store.
Decision rule: If the token can authorize sensitive tool use or production data access, prefer a brokered flow, short token lifetime, and server-side audience enforcement over local long-term custody. If you cannot prove replay resistance, assume the token is enough for compromise.
Practitioner takeaway: For remote MCP, the core question is not whether the agent is trusted to use the token, but whether the environment can prevent that token from becoming a reusable secret outside the intended session.
Related resources from NHI Mgmt Group
- What breaks when AI agents rely on static OAuth scopes for MCP access?
- Who is accountable for securing a remote MCP server that issues and verifies OAuth tokens?
- What breaks when AI agents have to click through OAuth consent for every MCP tool?
- What breaks when MCP agents are given OAuth access without lifecycle governance?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org