The access outlived the protocol

The claim that MCP is dead is a statement about a protocol layer, not a confirmed industry-wide event. What is observable is that a control surface many organisations began to rely on for connecting models to internal systems is now in question. For boards, the relevant fact is not the status of the protocol itself, but the exposure created by the access patterns it enabled while in use. The outcome indicates that integrations were established between large language models and internal data, tools, and execution environments under assumptions that may no longer hold.

This matters because the risk does not end when a protocol is declared obsolete. Connections made under MCP-based integrations granted models the ability to read, retrieve, and in some configurations act on internal systems. The scope of those connections within any specific organisation is not confirmed at this level. What can be said is that wherever such integrations were deployed, the access granted to the model became part of the organisation’s effective attack surface. That access does not retire on its own.

The board-level concern is therefore not whether MCP continues as a standard. It is whether the organisation can answer, with evidence, which systems were exposed to model-driven access, under what identity, and with what constraint. The duration and extent of those integrations across the environment remain unconfirmed until inventoried directly. Until that is established, the organisation cannot characterise its current exposure with confidence.

The original assumption embedded in MCP-based adoption was that a standardised protocol would reduce the risk of ad-hoc model integrations by providing a consistent connection layer. Under that assumption, governance could attach to the protocol, and oversight could be centralised at the integration point. Many organisations treated the existence of a standard as a sufficient basis for expanding model access to internal systems. The outcome indicates that this assumption shifted operational risk onto a layer whose long-term stability was not guaranteed.

A second assumption was that the identity and execution boundaries enforced by the protocol would remain consistent with the organisation’s broader access control model. In practice, model-driven access often operated under service identities, delegated tokens, or shared credentials whose scope was defined at integration time. No evidence of continuous enforcement at the level of individual model actions can be assumed without direct verification. The control posture was, in many cases, established at connection rather than at runtime.

The third assumption was reversibility. Boards were often advised that integrations could be withdrawn if the standard changed or if risk increased. That assumption holds only where inventory, ownership, and dependency mapping are current. Where integrations were established by distributed teams without central registration, reversibility cannot be determined from available information. The organisation’s ability to withdraw access cleanly is a function of what it can see, not what it intended to build.

What changed is that the assumed continuity of MCP as a stable control surface can no longer be relied upon. The outcome indicates that the layer through which model access was governed is now itself a source of uncertainty. Access granted under the protocol does not automatically lapse, and the controls that depended on the protocol’s continued operation must now be re-examined against the systems they were meant to protect. The exposure is defined by what the integrations were permitted to reach, not by the status of the protocol.

The second change is the loss of a single point at which governance, audit, and oversight could be attached. Where organisations consolidated their model-access controls on this layer, that consolidation is now a concentration of unverified assumptions. No evidence of equivalent enforcement at the underlying system level can be presumed. Each connected system must be evaluated on the basis of its own access controls, independent of the protocol that introduced the model to it.

The third change is the shift in vendor and ecosystem direction. Where the protocol’s trajectory is no longer assured, the organisations and tools that built on it are making independent decisions about replacement, divergence, or withdrawal. The implications for industry standards cannot be determined from available information at this stage. What can be stated is that the period of assumed convergence has ended, and the control environment around model access is now fragmented until a new basis for standardisation is established and verified in practice.

The mechanism by which exposure persists is straightforward. Access granted to a model through an integration is held by the underlying system, not by the protocol that introduced it. When the protocol layer becomes uncertain, the credentials, tokens, and trust relationships established through it do not retract. The outcome indicates that the operational surface created during the period of MCP adoption continues to exist within the systems it touched. Whether those connections remain active, dormant, or partially decommissioned cannot be determined from available information without direct inventory.

Drift occurs at the point where governance was attached to a layer that is no longer guaranteed to function as the control point. Where audit, logging, and policy enforcement were positioned at the protocol boundary, the loss of confidence in that boundary does not automatically transfer those controls to the systems beneath it. No evidence of equivalent runtime enforcement at the connected-system level can be presumed. The organisation must verify, system by system, what access remains, under what identity, and with what constraint. Until that verification is complete, the control posture is described by intent rather than by operation.

A further mechanism of drift is the divergence of teams and vendors who built on the protocol. Where integrations were established by distributed product, data, and engineering groups, the response to the protocol’s changed status will not be uniform. Some integrations will be retired, some replaced, some left in place under the assumption that they remain functional. The duration over which this divergence resolves remains unconfirmed. During that period, the organisation’s effective exposure is the sum of all integrations that have not been positively confirmed as withdrawn, not the subset that leadership believes to be active.

The pattern visible here is not unique to MCP. It recurs wherever a standard, protocol, or platform layer is treated as a sufficient basis for extending access to internal systems. The same dynamic has been observed in earlier shifts around federated identity providers, third-party API gateways, and shared service buses. The outcome indicates that when governance is consolidated on a layer that the organisation does not control, the stability of that layer becomes a precondition for the stability of the control environment. When the layer changes, the controls change with it, whether or not the organisation has reflected that change in its risk register.

The parallel extends to the broader category of model-access integrations beyond MCP itself. Where models are connected to internal data and tools through any protocol, vendor SDK, or bespoke connector, the same questions apply. The identity under which the model operates, the scope of systems it can reach, the constraints enforced at runtime, and the organisation’s ability to withdraw that access are properties of the integration, not of the standard that enabled it. No evidence that these properties are uniformly governed across the model-access estate can be assumed without direct examination.

The industry-level implication is that reliance on emerging standards as a substitute for enforced access boundaries is now visibly fragile. The period in which MCP was treated as a converging point for model integration has ended, and the organisations that depended on that convergence are now exposed to the fragmentation that follows. What replaces it, and on what terms, cannot be determined from available information. What can be stated is that any successor will inherit the same board-level question: whether access granted through it is constrained at runtime, attributable to an identity, and reversible on demand.

The closing position for the board is that the status of MCP is not the exposure. The exposure is the access that was granted while it was in use, and the degree to which that access can now be enumerated, verified, and constrained. Access defines exposure. The protocol that established the access does not define the exposure, and its retirement does not retire the access.

Controls must function at runtime to exist. Where governance was attached to the protocol layer rather than to the systems it connected, the organisation cannot claim those controls without direct evidence that they continue to operate at the point of access. The duration and extent of any gap between assumed control and operational control remain unconfirmed until measured. No evidence of continuity should be presumed in its absence.

What must be true going forward is that the organisation can produce, on demand, an inventory of every system to which a model has been granted access, the identity under which that access operates, the constraint enforced at runtime, and the mechanism by which the access can be withdrawn. Until that condition is met, the organisation’s exposure to model-driven access cannot be characterised with confidence, and any statement about the consequences of MCP’s changed status - at the level of this organisation or the industry - remains a statement about a protocol, not a statement about risk.