What breaks when MCP revocation is not centralised?

Why Centralised Revocation Matters for MCP

When revocation is centralised, one decision point can cut off access consistently across the MCP estate. That matters because MCP access often depends on shared tokens, gateways, servers and upstream identity providers. When those controls fragment, revocation becomes a coordination problem instead of a control action, which slows containment and weakens assurance.

A central model also preserves the meaning of revocation. If one server still accepts a token after another has rejected it, the organisation no longer has a reliable answer to the question, “is this access live or not?” For practitioners, that inconsistency is often the first sign that the architecture has drifted from policy to convenience.

What Fails When Revocation Is Split Across Servers

Distributed revocation breaks the operational chain between compromise detection and access shutdown. A token may be revoked in one place while remaining valid in another, especially when mcp server cache state, trust different upstream providers, or implement local exception handling. That leaves a residual access window that attackers can exploit and that defenders may not see quickly.

It also creates lifecycle drift. When a user leaves or a credential is rotated, teams have to chase the change through multiple administrative paths, and each path can fail independently. The result is not just slower deprovisioning, but a higher chance that an orphaned token, stale session or shadow integration survives long enough to matter.

Centralised revocation is easier to reason about because the enforcement logic is singular even if the infrastructure is distributed. The mcp security model documented in Model Context Protocol: Authorization specification is useful here because it anchors the discussion in audience-bound tokens and avoids token passthrough patterns that make revocation harder to enforce consistently.

Why Verification and Audit Evidence Get Worse

Revocation is not complete until you can prove it. With decentralised controls, evidence becomes fragmented across consoles, logs and identity systems, so audit teams have to reconstruct a story rather than inspect a single authoritative state. That makes it harder to show when access was removed, where it was still valid, and whether the removal was actually enforced everywhere.

Fragmented evidence also reduces operational confidence. If response teams cannot verify that a revoked token is rejected at every relevant entry point, they have to assume the worst and treat the access path as potentially still alive. In practice, that means more manual checks, broader containment and more uncertainty during incident response.

For a control model that depends on a single cut-off point, centralisation is the difference between immediate enforcement and best-effort cleanup. NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant because access control, identification and authentication, and auditability all depend on being able to revoke access decisively and verify the result.

Where the Architecture Usually Goes Wrong

The most common failure is letting each server or provider make its own revocation decision without a shared source of truth. That usually happens when teams optimise for local autonomy, add gateways without central policy enforcement, or allow direct-to-server trust relationships to accumulate over time. The architecture then looks distributed, but the accountability model is still central, which creates gaps.

A second failure is assuming that authentication and revocation are the same thing. They are not. A token can be validly issued and still need to be invalidated immediately after compromise, role change or offboarding. If the revocation path is not central, the organisation is effectively relying on every downstream system to interpret lifecycle changes correctly and promptly.

That is why identity and access guidance for machine and service credentials often stresses a single control plane for lifecycle actions. NHI Authentication Guide and AI Agent Identity Security: The 2026 Deployment Guide both reinforce the same operational point from different angles: if credentials or agent identities can still act after a change event, the lifecycle control is incomplete.

Practitioner Guidance

What to prioritise: Treat revocation as a single enforced control, not a set of local admin actions. The first design question is which component is authoritative for disabling access, and every other component should consume that decision rather than recreate it.

What to verify: Test the full path from revocation request to rejected request at the MCP server, gateway and upstream identity layer. If any component still accepts the token after revocation, you do not yet have centralised revocation in practice.

Common mistake: Teams often prove that offboarding updates one system and assume the rest will follow. In mcp environment, that assumption is risky because delayed propagation, cache behaviour and multiple trust domains can keep access alive longer than policy allows.

Practitioner takeaway: The real control objective is not just removing access, but making removal immediate, globally enforceable and auditable across every place the MCP token can still be accepted.

Related resources from NHI Mgmt Group

• How can organizations manage the risk of credential leaks in MCP frameworks?
• What challenges do unmanaged API keys pose within MCP?
• What breaks when MCP revocation does not reach the underlying OAuth token?
• What breaks when delegation revocation is not tied to client deletion?