Remote MCP OAuth tokens for AI agents: what changes now?

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.

NHIMG editorial — based on content published by Riptides: Securing Agentic OAuth Flows with Riptides

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.

Questions worth separating out

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.

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.

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

A: What breaks is the trust boundary.

Practitioner guidance

• 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.

What's in the full article

Riptides' full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step OAuth discovery and double-login sequence for remote MCP servers.
• Kernel-level credential injection flow showing how the real token is replaced before traffic leaves the machine.
• Example configuration for Service, CredentialSource, and CredentialBinding resources.
• Runtime token structure and claim mapping between workload identity and user identity.

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

Remote MCP OAuth tokens for AI agents: what changes now?

Explore further

View Full Forum →  |  NHI Foundation Course →