Notifications
Clear all
Topic starter
10/06/2026 11:18 pm
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
12/06/2026 5:12 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Securing remote MCP OAuth flows for AI agent identities
