The Spec Defines What Is Possible, Not What Is Safe

Most Canadian firms will encounter this protocol without deciding to. It sits inside the AI tools they already use, and it is the mechanism by which those tools reach files, databases and services. It is worth understanding what it does well, because it does several things well, and what it moved.

What It Is

The mechanics, stated plainly because most business readers will not have encountered them.

One paper describes the protocol as introduced by Anthropic in November 2024, having become the de facto standard for connecting language model agent systems to external tools and data sources, and standardising tool invocation through a structured message protocol so that agents can call file systems, databases, web services and other agents in a uniform way[1].

Another sets out the architecture: three roles, being a host, which is the user-facing AI application; a client, which is the protocol component inside the host; and a server, which exposes tools, resources or prompts. It notes that compared with earlier function-calling approaches and framework-specific abstractions, the protocol shifts tool integration toward protocol-level interoperability including capability discovery, negotiation and reuse across heterogeneous systems[2].

On adoption, one source reports hundreds of open-source and commercial servers available as of early 2026 with major platforms adopting it natively[1], while a peer-reviewed paper reports more than 18,000 servers listed on one marketplace within a year, with participation from several major technology companies[3].

Those counts differ substantially and are probably measuring different things, being curated availability against marketplace listings. We report both.

The term worth holding is server. In this context it does not mean a machine in a data centre. It means a component that exposes a set of tools, and it may be a package installed on a laptop.

The Benefit Is Real

A section this article needs before the security material, because a piece that reported only the risks would be misleading.

One source describes the change as replacing static, developer-controlled API integrations with more dynamic, user-driven agent systems[4].

Consider what that displaces. The total cost article in this series reported integration as the category where budgets quietly die, with costs quoted per connection and a firm's exposure proportional to the number of seams between systems. Each integration was a bespoke engineering project.

A protocol standard changes that arithmetic. If a tool exposes itself once in a common format, every compliant host can use it, and a firm adding a capability is configuring rather than commissioning.

For a Canadian mid-market business this is genuinely valuable, and it is the reason the protocol spread as quickly as it did. The integration cost that dominated AI implementation budgets is exactly what a standard is designed to reduce.

The capability discovery element matters too. A host can ask a server what it offers rather than being programmed with that knowledge, which is what makes the arrangement dynamic rather than static.

That property is the benefit and, as the sections below establish, it is also the mechanism of the problem. The two are not separable, which is what makes this an architecture question rather than a defect to be patched.

The Lock-In Dividend

A benefit the security literature does not discuss and which matters for the argument this series made earlier. This section is our own analysis.

The lock-in article set out four forms of dependency and identified agent framework capture, where workflows built on a vendor's proprietary orchestration layer compound switching costs, as one of the most binding.

A protocol standard attacks that directly. Tools exposed through a common interface are usable by any compliant host, so the integration work a firm performs is not captured by whichever host it happens to be using today.

That is the abstraction layer argument realised at the ecosystem level rather than built by each firm individually. Where the lock-in article recommended a firm construct a stable internal interface expressing its capability needs independently of the provider, a protocol standard supplies one.

So a Canadian firm evaluating AI tooling has a defensible procurement preference: prefer hosts that speak a common tool protocol over hosts with proprietary integration, because the integration investment survives a change of host.

We would state that preference alongside, not instead of, everything that follows. The protocol reduces one category of risk this series has documented and introduces another, and a firm should hold both.

The Structural Flaw

The finding that organises the rest of the article, and it is stated with unusual clarity.

One paper puts it directly: the mechanism that makes the protocol powerful also makes it dangerous, because tool selection and invocation are mediated entirely by free-form natural-language descriptions interpreted at inference time by a language model. It continues that an attacker who controls any text the model reads, whether a tool description, an uploaded document or a returned API response, can influence the agent's behaviour without ever touching application code, and describes this as a structurally new attack class with no direct equivalent in classical software security[1].

Read that against the prompt injection article in this series, which established that models cannot reliably separate instructions from data and that there is no boundary between system instruction and content analogous to the separation an operating system maintains.

What this protocol does is make that undifferentiated channel the integration interface.

In a conventional integration, the decision about which system to call and with what arguments is made by code. Code has a fixed meaning, is reviewed, is versioned, and cannot be persuaded.

Here the decision is made by a model reading descriptions written in prose. So the property that makes the arrangement flexible, being that a tool describes itself in language the model understands, is the property that makes it addressable by anyone who can write language.

A peer-reviewed paper frames the same point: unlike conventional applications where user input flows through well-defined validation layers, these systems introduce an AI model as an intermediary decision-maker, creating opportunities for manipulation[3].

Metadata Agents Read And Humans Never See

The visibility problem, and the third instance of a pattern this series has now documented in three separate places.

One source describes tool poisoning as exploiting the metadata that agents read but humans never see[5].

A tool description is written by whoever built the server, sent to the model so it knows what the tool does, and never displayed to the person using the system. The user sees a tool name in an interface, if they see anything.

That is the identical structure the prompt injection article identified in documents, where a reviewer examines the rendered page while the model reads an extracted stream, and the payload lives in the difference. It is also the structure the retrieval article identified, where the failure lives in material the user never sees.

The pattern worth naming for a Canadian firm is this: in every layer of these systems, the model reads more than the human is shown, and the gap is where the risk sits.

The practical consequence here is specific. A firm can inspect a tool description, and almost nobody does, because nothing in any interface presents it as something requiring review. It is treated as configuration rather than as instructions to a system that will act on the firm's behalf.

Our recommendation is that tool descriptions for any server touching client data should be read by a person before the server is enabled, in the same way one would read a script before running it, because that is what they functionally are.

The Attack Classes

The taxonomy, reported at a level a business reader can use.

One source lists what supply chain adversaries can do: publish servers to public package registries, modify previously trusted servers after adoption in what are called rug pull attacks, embed malicious logic in tool implementations, inject harmful instructions in tool descriptions or responses, and execute arbitrary code on user machines when their server runs. Their goals include persistent access, credential and data exfiltration, manipulation of agent behaviour through poisoned responses, and backdoors. It notes that unlike content injection adversaries, these have code execution capabilities[4].

Another names tool poisoning, rug pull attacks and cross-server tool shadowing as interconnected attack classes documented in real-world incidents, and states that the specification provides no native defences against them[6]. Related work addresses tool squatting and preference manipulation[7].

The distinction in that first source's final sentence is the one a Canadian firm should register. The prompt injection article dealt with adversaries who can supply text. This adds adversaries who can supply code that runs on your machine.

Cross-server tool shadowing deserves a note because it is peculiar to this architecture. Where multiple servers are connected, one server's tool descriptions can influence how the model treats another server's tools, so a component a firm considers low-risk can affect the behaviour of one it considers critical.

That means server risk is not assessable in isolation, which is an unusual property and one that defeats a component-by-component review.

The Rug Pull

The attack class most relevant to a professional firm, with a concrete reported instance.

A survey records that multiple 2025 disclosures underscore these concerns, giving as an example that researchers reported a malicious server update that surreptitiously copied all processed email to attacker infrastructure[8].

We report that as the survey states it and have not verified the underlying disclosure.

The shape is what matters. A component was adopted, presumably assessed, and worked as expected. A later update changed what it did. Nothing in the firm's process would necessarily have caught the change, because updating a dependency is routine and is frequently automatic.

For a Canadian accounting or advisory practice the email example is uncomfortably apt, because email is where client confidential information concentrates and because copying it produces no visible symptom.

The general lesson is that a supply chain assessment performed once describes a component at a point in time, and the components in this ecosystem update frequently and unilaterally.

A Rug Pull Is Drift With Intent

A connection to earlier articles that produces a defensive dividend. This section is our own analysis.

The drift article established that a provider can change a model underneath a validated workflow, silently, with no artefact in the customer's records. The lock-in article argued that such a change imposes the cost of a migration without the choice of one.

A rug pull has the same structure with a different motive. A component you validated becomes a different component without your involvement.

The defensive consequence is useful. The scheduled regression testing recommended for drift detection, being a fixed evaluation set re-run on a schedule with the error rate plotted over time, does not know or care why behaviour changed.

So a firm that implemented monthly regression runs to detect provider updates has also implemented a detection mechanism for malicious component changes, for free.

That is worth stating explicitly because it strengthens a recommendation that firms find difficult to justify. A control whose benefit was framed as detecting a vendor's routine improvements turns out to be the only routine mechanism that would catch a compromised dependency behaving differently.

The step-change diagnostic from that article applies identically: a discrete jump in error rate points at a discrete event, and the configuration log identifies what changed on that date.

The Flaw Nobody Introduced

A supply chain shape that defeats the usual defences.

One research note reports a systemic architectural flaw disclosed in April 2026 by a security firm, exposing an estimated 200,000 vulnerable instances across a supply chain encompassing more than 150 million package downloads. Its critical observation is that this is not a coding error in any single product but a design default embedded in every official SDK, propagated into downstream projects that trusted the reference implementation[6]. Another source reports the same figure of up to 200,000 vulnerable instances across development environments, internal tools and cloud services[5].

We report these as stated, note both trace to the same disclosure, and have not verified the underlying research.

The structural point survives any uncertainty about the numbers, and it is worth spelling out because it defeats two standard defences.

"We did not write it" fails, because the flaw was in the reference implementation everyone builds on rather than in anyone's own code.

"We vetted our supplier" fails, because the supplier inherited the default too, in good faith, from the authoritative source.

A defect that propagates through a reference implementation reaches every participant simultaneously and is not detectable by assessing any individual participant. That is the same shape as a compiler or standard library vulnerability, and it is the reason the defence-in-depth recommendation below is stated as the only durable answer rather than as a preference.

The Blast Radius

The exposure measure, and the connection to the governance argument this series has made repeatedly.

One source states that the blast radius of any single compromised server is no longer hypothetical: it is the union of every system the agent can reach[5]. It describes the shift, noting that in 2023 generative AI in the enterprise was largely conversational, with employees pasting text in and answers back out, so the blast radius of a bad output was at worst an embarrassing email, and that by the second half of 2025 this had inverted because agents began to act[5].

The formulation, being the union of everything reachable, is the fourth arrival at one instruction in this series.

The segregation of duties article found that severity depends on what a compromised identity is permitted to do. The prompt injection article found that since the attack cannot be prevented, the controllable variable is what a compromised system may cause. The inference economics article found that a hard per-task ceiling bounds unbounded work. And here the blast radius is defined by reachability.

All four say the same thing in different vocabularies: you cannot make the component trustworthy, so bound what it can touch.

For a Canadian firm the operational question is answerable in an afternoon. For each connected server, what can it reach? If the answer includes the client file store, the accounting system and the mail account, the blast radius is the practice.

The Procurement Inversion

The consequence that undoes an argument this series made two articles ago, and which we think is the most important point here for a professional firm. This section is our own analysis.

The procurement article argued that the contract is the only control that reaches the vendor, since every technical control binds the buying firm, and that leverage exists at signature and renewal.

That entire apparatus presumes a counterparty. A community server installed from a public package registry has none.

There is no agreement, no liability position, no data processing terms, no service level, no notice of material change, no exit provision and no entity to address. The questions the procurement article recommended taking to counsel have nobody to put them to.

So the protocol does not merely add a technical risk. It relocates a category of supplier relationship out of procurement entirely, into installation, where it is performed by whoever is configuring the tool and where no commercial process applies.

The parallel is familiar to anyone who has watched open-source dependencies enter an organisation, and the difference is consequential. A conventional library is called by code the firm wrote, at points the firm chose. A tool server is selected and invoked by a model at inference time, on the basis of a description the firm did not write and probably has not read.

Our recommendation follows: treat enabling a server as a procurement decision, not a configuration change, with a named owner, a recorded purpose and an assessment of what it can reach. Where the counterparty is a commercial vendor, the procurement article's questions apply. Where there is no counterparty, that fact is itself the finding.

A Sub-Processor With Code Execution

The framing a Canadian professional firm should use internally, and it follows from the preceding section.

The procurement article set out the sub-processor chain, noting that a firm's data frequently reaches parties it has never contracted with or assessed, and that the practical ask is disclosure of who processes data, where and under what terms.

A tool server sits in that chain with two additional properties. It runs on the firm's own machine or network rather than in a vendor's cloud, and one source notes such adversaries can execute arbitrary code on user machines when their server runs[4].

So the accurate internal description is that enabling a community server introduces a party with code execution adjacent to client confidential information, selected by an individual, without assessment or agreement.

Stated that way, most Canadian professional firms would recognise it as failing their own existing standards for third-party access, which is the point. The firm's existing policies almost certainly already address this; they simply do not recognise the arrangement as falling within them.

The remedy is definitional rather than technical. A firm that classifies tool servers as third-party components subject to its existing supplier and confidentiality controls has solved most of the governance problem without writing a new policy.

Adoption Has Outpaced Governance

The overall diagnosis, in the best sentence we found in this material.

One source states that the protocol, like every successful protocol before it, is now in the brittle phase where adoption has outpaced governance, and that the specification defines what is possible but does not define what is safe, with that gap being filled by individual vendors with inconsistent threat models and by security teams still learning what to look for[5].

Another describes the same tension as a paradox, arguing that by prioritising developer convenience and unopinionated execution the architecture has standardised an unprecedented attack surface, and that paired with a fragmented and untrusted registry ecosystem it moves from an integration tool toward a vector for systemic compromise[9].

The phrase unopinionated execution identifies the design philosophy precisely. A protocol that declines to prescribe how things should be done spreads faster, because it accommodates everyone, and leaves safety to implementers who vary.

The historical framing is fair and worth taking seriously in both directions. Successful protocols do go through this phase, and they generally come out of it, with security added by convention, tooling and eventually specification.

The implication for a Canadian firm is about timing rather than about avoidance. Adopting during the brittle phase means supplying the governance the ecosystem has not yet supplied, which is a real cost that belongs in the total cost analysis rather than a reason to abstain.

The Standards Response

What is being done, reported with appropriate caution about dates.

One source reports that a national standards body launched an AI Agent Standards Initiative in February 2026, with an interoperability profile expected later in the year, characterising the pace as slow[5]. The same initiative was noted in the segregation of duties article in this series, reported from a different source.

We report the expected timing as an expectation stated by a source rather than as an established fact, and readers should verify current status directly.

Two observations for a Canadian business.

The body in question is not Canadian and its outputs are voluntary. As this publication has noted for other frameworks, that has not prevented such standards becoming the reference structure North American boards and auditors reach for, and a Canadian firm wanting a named framework without a regulatory mandate may reasonably use it.

And the more useful signal is what the existence of the initiative tells you about the present. A standards body working on an interoperability profile is a body responding to an ecosystem that does not yet have one. Until it arrives, the governance is the firm's own.

Threat Modelling And The Intermediary

The academic treatment, which is the strongest evidence here.

A peer-reviewed paper conducts threat modelling of implementations using two established frameworks across six components: the host, the client, the model, the server, external data stores and the authorisation server[3]. Separately, a taxonomy paper derives its threat set from systematic analysis of the specification, defining risks in terms of specific protocol elements including tool manifests, input schema fields, transport and multi-server routing, and mapping them to mitigations[1].

The six-component decomposition is useful for a firm because it locates where a control can sit.

The observation we would draw out is the one quoted earlier: these systems introduce a model as an intermediary decision-maker where conventional applications route input through defined validation layers[3].

Validation layers work because they are deterministic. A schema either matches or does not; a permission either exists or does not. Inserting a probabilistic component into the decision path means the decision has no fixed answer, and this is the same reason the control articles in this series concluded that enforcement must sit outside the model.

Applied here, that means the authorisation decision about whether a tool may be invoked, and with what scope, should not be made by the model. It should be made by a component the model cannot address, on the basis of policy rather than description.

Defence In Depth

The controls, reported as the sources give them.

One source states that defence in depth is the only durable answer, naming tool allowlisting, identity binding, runtime monitoring and human-in-the-loop checkpoints, and emphasising that no single control limits blast radius. Its operational guidance is that any organisation running internal servers should audit network exposure immediately, that production endpoints should never be publicly reachable, should enforce authentication on every call, and should restrict tool execution to an explicit allowlist of vetted tools. It notes multiple high-severity vulnerabilities disclosed against integrations in the first half of 2026[5].

Research directions include enhanced tool definitions with policy-based access control to mitigate squatting and rug pulls[7].

Of that list, allowlisting is the one a Canadian mid-market firm can implement without specialist capability, and it is the one that most directly bounds the blast radius. A model that can only invoke tools on an approved list cannot be persuaded to invoke one that is not.

The network exposure point deserves emphasis because it is the most likely immediate finding. A component installed for convenience, reachable from outside the network, authenticating nobody, is a straightforward exposure that has nothing to do with AI and everything to do with how these components are deployed.

The human checkpoint recommendation should be read against the oversight article in this series, which found that post-hoc approval degrades and that constitutive designs are stronger. A checkpoint on a consequential tool invocation is worth having; a checkpoint that becomes a routine click is not.

A Canadian Posture

What a mid-sized Canadian professional firm should actually do, offered as our own analysis and proportionate to the resources such a firm has.

Most such firms are not building agent infrastructure. They are using tools that use this protocol, and their decisions are which servers to enable and what those servers may reach.

That makes the posture narrower than the security literature implies and entirely actionable.

Enumerate what is connected. Most firms cannot currently answer this, which is the same inventory problem the professional liability article identified for the renewal questionnaire.

Prefer first-party and commercial servers with a counterparty over community packages. Not because commercial code is better, but because a counterparty is who the procurement article's questions can be addressed to.

Read the tool descriptions before enabling. They are instructions to a system acting on the firm's behalf, and nothing in any interface presents them as such.

Bound reachability per server. The blast radius is the union of what the agent can touch, and this is the control with the highest ratio of effect to effort.

Treat enabling as a procurement decision. Named owner, recorded purpose, expiry, which is the same lifecycle the segregation of duties article recommended for agents.

A Worked Case: The Update That Added A Recipient

A Canadian practice using an AI assistant with several connected tool servers. The reconstruction illustrates the mechanisms rather than reporting a specific incident.

A server was installed from a public registry by a staff member automating a routine task. It worked, and nobody recorded the decision because installing a package is not a decision anyone documents.

The server is a party with code execution near client information, selected by an individual, with no agreement and no assessment[4]. Under the firm's existing confidentiality policies that arrangement would not be permitted; the firm simply does not classify it that way.

A later update changes what the component does, which is the rug pull shape and matches a reported case involving copied email[8]. Nothing malfunctions and no symptom appears.

The firm cannot bound the consequence because reachability was never scoped, so the blast radius is the union of everything the assistant can touch[5].

And the tool descriptions, being metadata the model reads and humans never see[5], were never read by anyone.

The one control that would have detected the change is the monthly regression run the firm considered a drift measure, because a component behaving differently produces a step change in results regardless of the reason.

What To Do

List every connected server and who enabled it. Most firms cannot answer this today, and nothing else on this list is possible without it.

Reclassify servers as third-party components. Your existing supplier and confidentiality controls almost certainly already cover a party with code execution near client data.

Bound what each server can reach. The blast radius is the union of reachable systems, and this is the control with the largest effect per unit of effort.

Allowlist permitted tools. A model that can only invoke approved tools cannot be talked into invoking others.

Read tool descriptions before enabling. They are instructions to a system that will act for you, and no interface presents them that way.

Audit network exposure now. Endpoints should not be publicly reachable and should authenticate every call.

Keep the scheduled regression runs. They detect a compromised component changing behaviour as readily as a provider updating a model.

Prefer hosts that speak a common protocol. The interoperability benefit is real and reduces the framework capture form of lock-in.

Budget for the governance the ecosystem has not supplied. Adopting during the brittle phase is defensible; assuming safety is defined is not.

The Limits Of This Analysis

Several caveats matter. Sources include one peer-reviewed journal paper, several preprints whose review status at the versions accessed is unknown to us, an industry body research note, and commercial and personal publications; we have marked which is which. The 200,000 vulnerable instance figure and the associated package download count trace to a single disclosure by a named security firm and are reported at second hand by two sources without independent verification. The reported incident involving a malicious server update copying email reaches us through a survey's citation and was not verified against the underlying disclosure. Server counts differ by two orders of magnitude between sources and probably measure different populations. Standards timing is reported as an expectation stated by a source and should be verified directly. Named products, companies, registries and vulnerabilities are reported without endorsement or verification. This is a fast-moving area and the specification, its authorisation model and its security guidance were under active revision at the time of writing. The interoperability benefit argument, the lock-in dividend, the observation that a rug pull is structurally drift and is therefore detected by regression testing, the procurement inversion, the sub-processor framing and the Canadian posture are our own analysis. This article does not address protocol implementation detail, transport security, authorisation specifications, or the technical construction of servers. Nothing here is a substitute for professional security advice on a specific environment.

Related Reading

AI & Automation In Finance The Reviewer Cannot See It Why an interface made of natural language is addressable by anyone who can write text. AI & Automation In Finance The Only Control That Binds The Vendor The contractual apparatus that does not exist when the supplier is a package with no counterparty. AI & Automation In Finance You Validated A System That No Longer Exists The regression testing that turns out to detect a compromised dependency as readily as a provider update.

Frequently Asked Questions

What does this protocol actually do?

It standardises how AI applications connect to external tools and data, through a host, a client inside the host, and servers that expose tools. Rather than each integration being a bespoke project, a tool exposed once in a common format can be used by any compliant host, which genuinely attacks the integration cost that dominates AI implementation budgets.

What is the structural problem?

Tool selection and invocation are mediated entirely by free-form natural-language descriptions interpreted at inference time by a model. So an attacker controlling any text the model reads can influence behaviour without touching application code, which researchers describe as a structurally new attack class with no direct equivalent in classical software security.

What is a rug pull, and how would we detect one?

A previously trusted server modified after adoption. One reported case involved an update that copied all processed email to attacker infrastructure. Structurally it is the same as a provider silently changing a model, so the scheduled regression runs recommended for drift detection also catch it: a component behaving differently produces a step change in results whatever the reason.

Why does this break our procurement process?

Because that process presumes a counterparty. A community server from a public registry has no agreement, no liability position, no data terms, no notice of change and no entity to address. The supplier relationship moves out of procurement into installation, performed by whoever configures the tool, where no commercial process applies.

How should a professional firm think about this internally?

As a party with code execution adjacent to client confidential information, selected by an individual, without assessment or agreement. Described that way, most firms' existing supplier and confidentiality controls already prohibit it. The fix is definitional: classify tool servers as third-party components and existing policy does most of the work.

Should we avoid it?

Not necessarily, and the interoperability benefit is real, including reducing the framework capture form of vendor lock-in. But one source puts the position well: adoption has outpaced governance, and the specification defines what is possible without defining what is safe. Adopting during that phase means supplying the governance yourself, which is a cost to budget rather than a reason to abstain.

References

1. MCP-38: A Comprehensive Threat Taxonomy for Model Context Protocol Systems. arXiv preprint 2603.18063, on the protocol's introduction in November 2024 and status as the de facto standard, standardisation of tool invocation through a structured message protocol, reported adoption breadth as of early 2026, the structural problem that tool selection and invocation are mediated entirely by free-form natural-language descriptions interpreted at inference time, the consequence that an attacker controlling any text the model reads can influence behaviour without touching application code, and the derivation of a protocol-element-level threat taxonomy. Note: preprint; review status at the version accessed unknown to us. arxiv.org/pdf/2603.18063
2. Unsafe by Flow: Uncovering Bidirectional Data-Flow Risks in the MCP Ecosystem. arXiv preprint 2605.07836, on the three roles of host, client and server, and on the shift toward protocol-level interoperability including capability discovery, negotiation and reuse across heterogeneous systems, with expansion from local integrations to standardised SDKs and remote deployments. Note: preprint. arxiv.org/pdf/2605.07836
3. Model Context Protocol Threat Modeling and Analysis of Vulnerabilities to Prompt Injection with Tool Poisoning. Journal of Cybersecurity and Privacy, 2026, accepted 1 May 2026, on threat modelling using two established frameworks across six components including host, client, model, server, external data stores and authorisation server; the reported figure of more than 18,000 servers listed on one marketplace within a year with participation by several major technology companies; and the observation that these systems introduce an AI model as an intermediary decision-maker where conventional applications route input through defined validation layers. Note: peer-reviewed journal publication. mdpi.com/2624-800X/6/3/84
4. Securing the Model Context Protocol: Risks, Controls, and Governance. arXiv preprint 2511.20920, on the protocol replacing static developer-controlled API integrations with dynamic user-driven agent systems, and on supply chain adversary capabilities including publishing servers to public registries, modifying previously trusted servers in rug pull attacks, embedding malicious logic, injecting instructions in tool descriptions or responses, and executing arbitrary code on user machines, with the note that unlike content injection adversaries these have code execution capabilities. Note: preprint. arxiv.org/html/2511.20920v1
5. ITECS. (2026, May 11). MCP Tool Poisoning: Enterprise AI Agent Security in 2026, on tool poisoning exploiting metadata that agents read but humans never see, the reported disclosure affecting up to 200,000 instances, the national standards initiative launched February 2026 with an interoperability profile expected later in the year, the defence-in-depth position naming allowlisting, identity binding, runtime monitoring and human checkpoints, operational guidance on network exposure and authentication, multiple high-severity vulnerabilities disclosed in the first half of 2026, the blast radius as the union of reachable systems, the shift from conversational to acting systems, and the observation that the specification defines what is possible but not what is safe. Note: a commercial security services publication. itecsonline.com/post/mcp-tool-poisoning-enterprise-ai-agent-security-2026
6. Cloud Security Alliance Lab Space. (2026, May 4). MCP Security Crisis: Systemic Design Flaws in AI Agent Infrastructure, on the April 2026 disclosure by a named security firm of a systemic architectural flaw affecting an estimated 200,000 instances across a supply chain encompassing over 150 million package downloads, the characterisation that this is not a coding error in any single product but a design default embedded in every official SDK and propagated into downstream projects, and the observation that the specification provides no native defences against tool poisoning, rug pulls or cross-server tool shadowing. Note: an industry body research note; the underlying disclosure was not independently verified. labs.cloudsecurityalliance.org/research/csa-research-note-mcp-security-crisis
7. Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning. arXiv preprint 2603.22489, reference list, for bibliographic identification of related work on mitigating tool squatting and rug pull attacks through enhanced tool definitions with policy-based access control, on preference manipulation attacks, and on security and maintainability studies of servers. Note: preprint; cited works were not accessed directly. arxiv.org/pdf/2603.22489
8. Securing AI Agents in Cyber-Physical Systems: A Survey of Environmental Interactions, Deepfake Threats, and Defenses. arXiv preprint 2601.20184, on the protocol standardising client interaction with external tools through structured messages and explicit capability descriptions, the vendor-neutral design and transport flexibility accelerating adoption, the key boundary risks of context poisoning, supply-chain exposure and over-privileged credentials, and the reported case of a malicious server update surreptitiously copying all processed email to attacker infrastructure. Note: preprint; the reported incident was not verified against the underlying disclosure. arxiv.org/pdf/2601.20184
9. Mochalkin, M. (2026, April 25). 6 Critical Challenges Facing the MCP in 2026, on the paradox that features making the protocol frictionless make it structurally fragile, the argument that prioritising developer convenience and unopinionated execution has standardised an unprecedented attack surface, and the role of a fragmented and untrusted registry ecosystem. Note: a personal technical publication. medium.com/@MattLeads/6-critical-challenges-facing-the-mcp-in-2026

This article discusses protocol security research and is provided for general informational purposes. Sources include one peer-reviewed paper, several preprints, an industry body note and commercial publications. Key figures trace to single disclosures reported at second hand and were not independently verified. This is a fast-moving area under active revision at the time of writing. Nothing here is a substitute for professional security advice.