The credential nobody revoked is still live

1. Opening Claim

MCP is dead. That is the position being circulated. The specifics behind that claim, who declared it, on what date, with what scope, are not confirmed. Treat the statement as a posture, not a forensic finding. The operator question is not whether the protocol’s reputation collapsed. The operator question is what continues to run in production under its name, and what trust was extended to it that has not been withdrawn.

Protocols do not die when they are declared dead. They die when every integration that depends on them is removed, every credential issued against them is revoked, and every downstream system stops accepting their inputs. None of those conditions are confirmed here. What is confirmed is a claim. A claim does not change runtime behaviour. A claim does not close a session. A claim does not invalidate a token. If your environment integrated MCP and nothing else has changed, your exposure is identical to what it was before the claim was made.

This is the part that matters for anyone with operational responsibility. The death of a protocol is a procurement statement. The presence of a protocol in your stack is a control statement. Those two statements are governed by different teams, different timelines, and different incentives. The gap between them is where unmaintained code keeps shipping data, and where attackers prefer to live. Until the integrations are pulled and the trust relationships are dissolved, MCP being dead is a marketing condition, not a security condition.

2. The Original Assumption

The assumption attached to MCP, as it was adopted, was that a defined protocol surface for model context exchange would constrain the trust relationship between a client, a model, and an external resource. The assumption being challenged by the claim ‘MCP is dead’ is not stated in the input. Whether that challenge concerns design flaws, deprecation, ecosystem collapse, or replacement by a successor protocol, is not confirmed. Operators should not select one of those explanations because it sounds plausible.

What can be stated is the structural assumption any protocol of this shape inherits. The client trusts the protocol implementation to mediate access. The model trusts the protocol implementation to deliver scoped context. The external resource trusts the protocol implementation to authenticate the requester. Three trust relationships, one mediating layer. If the mediating layer is no longer maintained, no longer reviewed, or no longer authoritative, all three relationships continue to operate against a control that no party is accountable for. That is the assumption that gets carried forward silently when a protocol is declared dead but not removed.

The second assumption was that a protocol with defined boundaries would produce defined logging, defined identity propagation, and defined error semantics. Whether MCP implementations actually produced those outputs in any given environment is not confirmed and must be verified per deployment. The assumption itself is the problem. Teams adopt a protocol and inherit the assumption that its specification is enforced by its implementations. Specifications are not controls. Implementations are controls. The two are only equivalent when someone validates them, and that validation is rarely repeated after initial integration.

3. What Changed

What changed, based on the input, is the status claim. MCP is now described as dead. The mechanism, the authority behind the declaration, and the effective date are not confirmed. The scope of what ‘dead’ covers, specification, reference implementation, ecosystem support, vendor commitment, is not confirmed. Operators should not assume the term means the same thing across sources. Until the scope is defined, the change is a label change.

What has not changed, in the absence of further facts, is every system that integrated MCP before the claim. Those systems continue to expose the same endpoints, accept the same tokens, and execute the same handlers. If maintenance has stopped, the rate of unpatched defects in those systems will increase over time. That increase is a logically necessary implication of any unmaintained code path that remains reachable. The speed of that increase is not confirmed and depends on conditions specific to each deployment.

The operational change worth tracking is the shift in attention. When a protocol is publicly declared dead, defensive attention moves to its successor. Offensive attention does the opposite. Unmaintained, still-deployed, still-trusted code is a higher-yield target than maintained code with active review. Whether attackers have shifted focus to MCP deployments specifically is not confirmed. The pattern, that abandoned-but-deployed protocols accumulate exploitation pressure, is consistent with how unmaintained code paths are treated by anyone whose objective is access. Treat the claim ‘MCP is dead’ as a signal that the asymmetry between attacker interest and defender interest has moved in the wrong direction for any system still running it.

4. Mechanism of Failure or Drift

The mechanism here is the divergence between declarative status and runtime status. A claim about a protocol’s death changes how it is referenced in roadmaps, procurement decks, and architecture diagrams. It does not change what executes when a client opens a session. Runtime behaviour is governed by the code that is loaded, the credentials that remain valid, and the network paths that remain reachable. None of those three states are altered by an announcement. The announcement and the deployment are governed by different systems, and only the deployment is enforceable.

Drift begins at the point where the declaration is accepted as a control. Teams that read ‘MCP is dead’ and treat that as equivalent to ‘MCP is removed from our environment’ are operating against a model that does not match the deployment. The drift is silent because nothing in the environment generates an alert when a deprecated protocol continues to serve traffic. Deprecation is a documentation event. Removal is an operational event. The two are confused regularly, and the confusion is the failure mode. Whether any specific MCP deployment generates alerts on protocol usage is not confirmed and must be verified per environment.

The second drift vector is identity propagation. If MCP integrations issued tokens, registered service accounts, or established trust between components, those artefacts persist until they are explicitly revoked. Revocation is not implied by deprecation. Whether any specific MCP deployment uses tokens, service accounts, or persistent trust relationships is not confirmed and must be verified per deployment. The structural point holds regardless. Identity artefacts outlive the protocol that created them. The protocol can be declared dead while the trust relationships it established remain enforceable until someone revokes them by hand.

The third vector is the maintenance contract. A protocol that is publicly described as dead is unlikely to receive coordinated vulnerability disclosure, security patches on a defined cadence, or active triage of reported defects. Whether that is the actual maintenance state of MCP after the claim is not confirmed. What is confirmed by the claim is that the public expectation of maintenance has been withdrawn. Any defect found in a deployment after that withdrawal sits in a system with no defined remediation path. The mechanism of failure is the gap between a still-reachable attack surface and an absent maintainer. That gap does not close on its own.

5. Expansion into Parallel Pattern

The same mechanism appears in every protocol that has been declared end-of-life while remaining deployed. The pattern is not specific to MCP. It is specific to the structural condition of reachable code with no accountable maintainer. The condition produces the same outcome regardless of what the protocol does, because the cause is not the protocol’s design. The cause is the absence of a party with authority to fix it. Once that party is removed, the runtime properties of the protocol are frozen at the state they were in when maintenance stopped, and every subsequently discovered defect remains open by default.

Consider any context-exchange protocol that has been declared superseded but left in place. If the deprecation is announced and the integrations remain, the deployment continues to accept inputs, dispatch handlers, and return outputs. The protocol does not know it has been deprecated. The handlers do not know they are unmaintained. The clients do not know the specification is no longer authoritative. The runtime behaviour is identical to a maintained protocol, with one difference. The window between defect discovery and defect closure is no longer bounded. That single change converts the protocol from a managed surface into an open surface. The conversion is invisible to the systems on either side of it.

The pattern compounds when the protocol mediates trust between three or more parties. Mediating protocols carry the assumption that the mediator is authoritative. When the mediator is no longer maintained, the parties on either side continue to defer to it. Neither party has the visibility or authority to renegotiate the trust relationship without coordinated action. The relationship persists by inertia. Inertia is not a control. It is the absence of a control. Any environment that retains a deprecated mediating protocol is enforcing trust through inertia, and inertia fails the first time it is tested by someone with intent and time.

6. Hard Closing Truth

MCP being dead is a procurement statement until it becomes a removal statement. The two are not equivalent and should not be treated as equivalent in any environment with operational stakes. The work that converts the first into the second is unglamorous. Inventory the integrations. Identify the tokens. Revoke the credentials. Remove the handlers. Close the network paths. None of that happens because a protocol was declared dead in public. It happens because someone with authority inside the environment decided that the declaration required a response, and assigned the response to a team with a deadline and a verification step.

What must now be true in any environment that integrated MCP, if the claim is accepted: the integrations are enumerated, the trust artefacts are listed, the maintenance status of each component is documented, and a removal date is set against each instance. If those four conditions are not met, the environment is operating against a protocol that the rest of the industry has stopped defending. That is the exposure. It is not a theoretical exposure. It is the direct, logically necessary consequence of leaving reachable code in production after its maintainer has been withdrawn. Whether the maintainer has actually been withdrawn from MCP is not confirmed, and that confirmation is itself a required input to the response.

The operator position is fixed. Controls that are not enforced are not controls. A deprecation notice is not enforcement. A blog post is not enforcement. A vendor statement is not enforcement. Enforcement is the removal of the code, the revocation of the credentials, and the closure of the trust relationships. Until those three actions are completed and verified, MCP is alive in your environment regardless of what is being said about it elsewhere. The death of a protocol is decided in the deployment, not in the announcement. Treat the claim as a trigger to act, not as evidence that the action has already occurred.