What breaks when MCP revocation does not reach the underlying OAuth token?

Why This Matters for Security Teams

MCP revocation is only effective if it reaches the credential that the downstream service actually trusts. If an operator disables an MCP connector but leaves the underlying oauth token alive, the access path remains usable outside the protocol layer. That creates hidden standing privilege, weakens offboarding, and turns a clean control action into a false sense of containment.

This is the same pattern seen in credential-led incidents where the brokered layer is removed but the secret or token is not. NHIMG has documented how token-centric failures continue to drive real exposure in cases like the Salesloft OAuth token breach and the Klue OAuth Supply Chain Breach, where revocation and actual token invalidation are not the same event. In 2025, Astrix Security reported that 24,008 unique secrets were exposed in MCP configuration files, which underscores how often the control plane and the credential plane drift apart. As NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear, revocation must be enforced where access is actually authorized, not just where it is displayed. In practice, many security teams discover the token is still live only after an incident review or a customer complaint, rather than during intentional deprovisioning.

How It Works in Practice

MCP is a mediation layer, but OAuth is the credential mechanism that the target service ultimately validates. If revocation stops at MCP, the protocol wrapper may reject future tool calls while the bearer token, refresh token, or delegated grant still works elsewhere. That means the user, agent, or integration may still reach the target API directly, bypassing the intended control. The operational fix is to treat revocation as a multi-step process: remove the MCP route, revoke the OAuth grant at the issuer, invalidate refresh tokens, and confirm downstream token introspection or resource server rejection.

Security teams should design for the credential lifecycle, not just the integration lifecycle. Current guidance suggests the following sequence:

• Revoke at the identity provider or authorization server, not only in the MCP console.
• Shorten token TTLs so residual access expires quickly if revocation fails.
• Use workload or application identities with explicit audience and scope limits.
• Log the revocation event and verify the target service no longer accepts the token.
• Test offboarding by replaying the exact token path that was active before removal.

This matters especially for agentic systems, where autonomous tools may cache credentials, chain requests, or switch execution paths after a policy change. NHIMG’s Guide to the Secret Sprawl Challenge shows how credential sprawl persists across systems even after an admin believes access has been removed. For implementation detail, the OWASP Agentic AI Top 10 reinforces the need to govern tool access and secrets separately from the orchestration layer. These controls tend to break down when refresh tokens are long-lived and resource servers do not enforce introspection, because the old grant remains valid long after the MCP entry has been removed.

Common Variations and Edge Cases

Tighter revocation often increases operational overhead, requiring organisations to balance rapid offboarding against the risk of breaking legitimate workflows. That tradeoff is real in SSO-heavy environments, delegated admin setups, and multi-tenant SaaS platforms where one “user” may have several credential artifacts behind the scenes.

There is no universal standard for this yet, but best practice is evolving toward end-to-end token lifecycle control. Some systems use opaque tokens with server-side introspection, which makes revocation easier to enforce centrally. Others rely on self-contained JWTs, where the token may remain valid until expiry unless the resource server checks a revocation list or key rotation event. For autonomous agents, that distinction is critical because a revoked MCP connection may still leave a valid token in a cache, a secret store, or an agent memory layer. NHIMG’s CoPhish OAuth Token Theft via Copilot Studio is a useful reminder that agent workflows can expose credentials outside the assumed control boundary.

In environments with service-to-service delegation, the safer model is explicit token binding, short-lived grants, and immediate downstream verification. Without those controls, MCP offboarding may look complete while the actual privilege path remains active in the target system.

Related resources from NHI Mgmt Group

• When should organizations rotate OAuth tokens?
• What does the article say is missing from MCP deployments?
• What breaks when a third-party OAuth refresh token is stolen?
• What breaks when token refresh and revocation are treated as background plumbing?