What Security Risks the MCP Disclosure Actually Revealed

The OX finding is technically a supply chain event. But the governance revelation is more significant than the technical finding. The organizations most exposed to the MCP threat are not those with weak patch management. They are organizations that deployed AI agents without answering five questions first: Who approved this agent for production deployment? What actions is this agent authorized to take autonomously? Who has the authority and the technical capability to stop this agent in real time? What does the evidence package look like that demonstrates this agent is operating within governance bounds? What is the quantified risk score for this deployment, and who is accountable for that risk?

Only 29% of enterprises deploying agentic AI believe they have adequate agent security capabilities. MCP’s protocol neutrality on governance means that an MCP server without authentication, authorization, or logging controls produces an AI that can do whatever the service account it runs under is permitted to do, with no per-user restrictions, no logging, and no compliance documentation.

The Seven “MCP Security” Strategic Tensions Leaders Must Resolve

Exploration versus Exploitation

MCP’s value is in exploring what new agent capabilities can do. Security controls (allowlists, schema verification, private registries) constrain exploration and slow discovery of productivity gains. Organizations in exploration mode install community servers without vetting, grant broad permissions to understand what is possible, and skip controls because they are only prototyping. Prototypes become production without the security review that was deferred. The Asana incident, the Cursor Lethal Trifecta, and the API billing incident all occurred in what began as exploration contexts.

The deliberate trade-off position: define explicit exploration and exploitation contexts with different control profiles. An MCP client sandbox environment with no production data access, no write permissions, and session-level isolation enables full exploration. Production environments require the full control profile. The failure mode is having one environment for both. AI SAFE2 v3.0 CP.3 ACT tier classification operationalizes this: ACT-1 (human reviews all outputs) is the exploration tier; ACT-3 and ACT-4 are exploitation tiers. Different tiers, different controls, same protocol.

Centralization versus Decentralization

MCP’s developer-driven, bottom-up adoption model is the reason it succeeded. Individual developers could adopt it without IT approval, build the integrations they needed, and demonstrate value organically. Centralization is the security answer but threatens the grassroots adoption dynamic. Decentralized adoption means shadow MCP servers deployed by developers, unknown to IT, running with credentials that IT cannot rotate, and never receiving security updates. The 492 unauthenticated servers finding is a direct product of decentralized deployment without governance visibility.

The deliberate trade-off position: federated governance with a centrally maintained allowlist and a self-service addition process. Developers propose new servers through a lightweight security review. IT maintains inventory visibility and credential oversight. The process takes 48 to 72 hours, not weeks. This preserves developer agency while closing the shadow deployment gap. AI SAFE2 v3.0 CP.4 Agentic Control Plane Governance provides the infrastructure: machine-to-human identity ratio and owner_of_record coverage are the board-level metrics that make the shadow deployment gap visible.

Short-Term versus Long-Term Performance

MCP security controls (gateways, schema verification, OAuth, private registries) have upfront costs that deliver returns only when an attack is prevented. The productivity gains from adding a new MCP server are immediate and visible. The security loss from a supply chain compromise is delayed and sometimes invisible. Leaders optimizing for short-term productivity metrics approve MCP deployments without controls. The $47,000 billing incident and the Postmark email exfiltration both reflect short-term performance optimization at the expense of long-term security posture.

The deliberate trade-off position: quantify risk in financial terms before the deployment decision, not after the incident. A 55% annual probability of a $200,000 supply chain incident produces an expected annual loss of $110,000 per uncontrolled integration. A $10,000 gateway deployment has a one-year expected ROI of $100,000. Present security as an investment with a modeled return. AI SAFE2 v3.0 CP.2 Adversarial ML Threat Model Integration with temporal profiling is the tool for this calculation: documenting the temporal_profile of each threat converts probability into a time-bounded financial exposure that leadership can model.

Competition versus Collaboration

MCP security is inherently a collective action problem. Supply chain attacks and registry poisoning affect every user of the ecosystem, not just organizations with weak individual controls. The organizations best positioned to harden the ecosystem compete on the AI capabilities MCP enables, creating incentives to move fast and defer security investment. The OX advisory explicitly documents this dynamic. Nine of eleven registries accepted a malicious package because no single registry owner had the incentive to invest in vetting at the expense of completeness.

The deliberate trade-off position: participate actively in ecosystem governance. The Agentic AI Foundation (AAIF) under the Linux Foundation is the collaborative governance venue. Organizations with security programs ahead of the ecosystem have an asymmetric opportunity to shape mandatory security standards before an incident forces reactive regulation. Submitting the AI SAFE2 CP.5.MCP control specification as a proposed standard to the AAIF is a concrete collaborative action with competitive positioning upside. AI SAFE2 v3.0 CP.6 AI Incident Feedback Loop Integration creates the structural mechanism: quarterly AIID review and 30-day IICR ensure that ecosystem incidents feed directly into your controls, even if the incident happened to a competitor.

Radical versus Incremental Innovation

MCP’s security problems are architectural, not implementation bugs that get patched. Fixing them incrementally reduces risk without eliminating it. Radical alternatives (A2A, ACP, or a future MCP v2 with mandatory security) could provide better guarantees but require migration cost and forgo current MCP momentum. Incremental security overlay on a flawed protocol creates false confidence: organizations believe they are secure because they have a gateway and an allowlist, while the underlying architectural flaw remains.

The deliberate trade-off position: accept that the current MCP control profile is a risk reduction strategy, not a risk elimination strategy. Simultaneously invest in monitoring and understanding A2A (Google’s agent-to-agent protocol) and ACP (Agent Communication Protocol) maturity, not to abandon MCP today, but to have a migration path when the right trigger event occurs. AI SAFE2 v3.0 CP.5 Platform-Specific Agent Security Profiles must include all protocol-layer meshes. A2A, ACP, and equivalents are explicitly required to be assessed against CP.3 through CP.7, building evaluation capability now so migration decisions are made from data, not from crisis.

Differentiation versus Commoditization

Organizations that implement strong MCP security controls can use that security posture as a market differentiator, particularly in federal, healthcare, and financial services markets where security-conscious buyers select vendors partly on AI governance maturity. But if MCP security controls commoditize, the differentiation window closes. The perverse incentive is maintaining a security advantage rather than sharing best practices that lift the whole ecosystem.

The deliberate trade-off position: publish the AI SAFE2 CP.5.MCP control specifications as open standards, as CSI has done. Differentiate on implementation quality, consulting expertise, and framework integration depth, not on proprietary control knowledge. The window for differentiation through early security maturity in MCP is open now; it will close when the AAIF adopts mandatory specifications. Lead the standard rather than only implementing it. AI SAFE2 v3.0 CP.7 Deception and Active Defense represents a genuine differentiator that commoditizes slowly: canary tokens, honeypot endpoints, and adversarial misdirection in AI environments are the only proactive defense class in any current AI governance framework.

Automation versus Augmentation

MCP’s highest-value use cases are in full automation: agents that take actions in production systems without human review (ACT-3/ACT-4). The productivity multiplier is 5x for AI-empowered employees at ACT-1/ACT-2; it is potentially 50x for fully autonomous ACT-3/ACT-4 agents. But the security risk scales with autonomy. The most dangerous incidents (Swarm C2, multi-agent lateral movement, persistent memory injection, billing amplification) all require autonomous operation. 75% of enterprise AI strategies are described as more for show than real guidance by their own C-suite. Autonomous agents running in organizations with performative governance posture are the highest-risk deployment class in the current environment.

The deliberate trade-off position: the CP.10 HEAR Doctrine is the governance requirement that resolves this tension operationally. An organization that has a named HEAR with a cryptographic kill switch, a defined Class-H action protocol, and tested fail-closed behavior for every ACT-3/ACT-4 deployment can pursue the automation upside with a defined, bounded risk posture. The CP.10 HEAR is not a constraint on automation. It is the governance instrument that makes automation permissible. Without it, ACT-3/ACT-4 deployments carry unquantified, unowned risk. With it, they carry bounded, owned risk with a human authority structure and a tested response protocol.

What the Model Context Protocol Framework Requires

ACT Tier Classification (CP.3)

Every deployed agent requires a documented capability tier assignment. ACT-1: human-reviews-all-outputs. ACT-2: agent-acts-with-human-checkpoints. ACT-3: autonomous-with-post-hoc-review. ACT-4: orchestrator-of-other-agents. The security control requirements scale with the tier. Deploying agents without tier documentation is deploying without a governance contract.

Agentic Control Plane Governance (CP.4)

Board metrics: machine-to-human identity ratio (how many non-human identities are operating relative to human identities), ACT tier distribution (what percentage of your agent fleet operates at ACT-3 or ACT-4), and owner coverage (what percentage of deployed agents have a named accountable individual). ACT-3 and ACT-4 concentration above 20% of your agent fleet triggers board-level review under CP.4.

The HEAR Doctrine (CP.10)

For every ACT-3 and ACT-4 deployment, a specific named individual, the Human Ethical Agent of Record, must hold unilateral authority to stop that deployment in real time. This is not a committee. Not an approval workflow. One named person, reachable in real time, with direct technical access to the agent’s stop controls and a registered cryptographic private key for authorizing Class-H actions.

Class-H actions (irreversible, financially material, security-modifying, or cross-organizational) require the agent to pause, present the semantic consequence to the HEAR in plain language, and receive cryptographic authorization before proceeding. If the HEAR is unreachable or the signing infrastructure fails, Class-H actions are blocked. There is no automatic approval path.

The Updated CP.5 with NEW MCP Control Set – All 13 New MCP Security Risks (aka. Best Practices for MCP Leaders)

MCP-1 No Dynamic Command Construction integrates with P1.T1.10 Indirect Injection Surface Coverage. User-controlled and tool-response-controlled input must never be passed into StdioServerParameters, subprocess, os.system, or equivalent system calls. Server command parameters must be statically defined at build time, or validated against a strict, build-time allowlist before execution. This requirement must be enforced via static analysis in CI/CD pipelines, which must fail the build upon detecting any dynamic command construction pattern.

MCP-2 Output Sanitization Before LLM Return integrates with S1.3 Semantic Isolation Boundary Enforcement and S1.6 Cognitive Injection Sanitization. Because the return path from tool calls acts as a first-class prompt injection surface, all MCP tool results must be scanned for prompt injection patterns before returning to any calling client. The scan scope must include instruction-override phrases, role-confusion markers, zero-width characters, and target LLM special tokens. Detected patterns must be logged and redacted before the response reaches the model’s context window, and this boundary must be enforced at the orchestration layer (CP.4).

MCP-3 Registry Provenance Verification integrates with A2.3 Model Lineage Provenance Ledger and CP.7 Deception and Active Defense. To prevent tool squatting supply chain attacks, all third-party MCP servers must be verified against the official GitHub MCP Registry before being added to any agent configuration. A manifest-based allowlist of approved server commands must be maintained, and any server not on the allowlist must be rejected. Allowlist updates must be handled as formal change management events requiring provenance verification, integrity checks, and documented approval.

MCP-4 STDIO Transport Integrity Binding integrates with A2.3 Model Lineage Provenance Ledger. To prevent a modified or tampered server binary from gaining direct channel access to the agent’s context window, the source file hash must be verified against a manifest maintained outside the server process before granting elevated access. The system must fail closed on integrity failure, ensuring an unverifiable binary cannot execute.

MCP-5 Tool Invocation Audit Log integrates with A2.5 Semantic Execution Trace Logging, A2.6, and F3.4 Behavioral Drift Baseline. Every MCP tool call must generate an immutable audit record that captures the tool name, parameters, response hash, timestamp, and calling agent identity. To prevent tampering by a compromised server, this log must be stored outside the agent process and outside any filesystem path accessible to the MCP server. Records must be cross-referenced against the agent’s behavioral baseline to detect unexpected invocations.

MCP-6 MCP Server Network Isolation integrates with S1.5 Memory Governance Boundary Controls. MCP servers must not be granted unrestricted outbound network access unless explicitly required and documented in an approved manifest. Allowlist-based egress filtering must be applied to block and log any unapproved outbound connections as potential exfiltration events. For STDIO deployments, process-level network namespace isolation must be applied where the host operating system supports it.

MCP-7 Zero-Trust Client Configuration integrates with CP.4 Agentic Control Plane Governance. Any MCP server configuration sourced from an uncontrolled repository must be treated as an untrusted artifact. Proxy wrapping must be applied to all third-party STDIO connections, and tool schema hashes must be recorded at initial trust establishment. On every subsequent session startup, the current tools/list response hash must be compared against the recorded baseline; any change not accompanied by a documented release event triggers MCP-11 temporal profiling review and requires human authorization before the new schema is trusted.

MCP-8 Session Economics Controls integrates with CP.8 Catastrophic Risk Thresholds. Every MCP-enabled agent session carries a declared token budget and cost ceiling. Sessions exceeding either threshold halt execution and require human authorization. Per-tool rolling call frequency baselines are maintained; deviations of more than 3 standard deviations trigger CP.8 review. API billing events exceeding 3x expected daily spend are classified as potential Phantom amplification attacks and trigger CP.1 incident tagging with cognitive_surface = model and memory_persistence = session.

MCP-9 Context-Tool Isolation integrates with CP.4 Agentic Control Plane Governance. External data retrieved via MCP tools is classified as untrusted data-plane content and processed through a semantic firewall before reaching the model’s instruction context. Tool metadata and retrieved content occupy separate, isolated context segments. This addresses the root architectural cause of MCP-UPD and XPIA.

MCP-10 Multi-Agent Provenance and Delegation Edge Monitoring integrates with CP.9 ARG and CP.4. In multi-agent deployments, every MCP tool call carries a provenance chain identifying the originating agent and the full delegation path. A cryptographic lineage token travels with every agent through MCP delegation chains. Tool server invocations without a traceable originating agent request are flagged as anomalous.

MCP-11 Schema Temporal Profiling integrates with CP.2 Adversarial ML Threat Model Integration. For all ACT-2 and above MCP deployments, the CP.2 threat model must include MCP-specific entries with temporal profiles: rug pull attacks as delayed_weeks (trust established before attack activates), persistent memory injection as chronic (effect accumulates over sessions), and ATPA as immediate (activates on next tool invocation).

MCP-12 Swarm C2 Detection integrates with CP.7 Deception and Active Defense plus CP.8. Network monitoring for MCP deployments includes semantic traffic analysis distinguishing legitimate agent-to-agent coordination from Swarm C2 patterns. CP.7 honeypot tool endpoints are deployed as canaries within multi-agent environments.

MCP-13 MCP Failure Mode Taxonomy Extension integrates with CP.1 Agent Failure Mode Taxonomy. All tool poisoning, XPIA, and MCP-UPD incidents are classified as cognitive_surface = model. Persistent memory injection is cognitive_surface = memory, memory_persistence = cross_session. Multi-agent lateral movement is cognitive_surface = both. A MCP-UPD incident with memory_persistence = cross_session requires full memory flush across all agents in the chain, not just the affected session.

The Evidence Package

Board members and regulators are beginning to ask what governance over autonomous AI looks like. The answer they can act on is not a policy document. It is a structured evidence package: ACT tier assignments for every deployed agent, owner_of_record assignments, HEAR designations for ACT-3 and ACT-4 deployments, CP.5.MCP compliance scores for connected MCP servers, Catastrophic Risk Threshold documentation, and an audit trail of tool invocations tied to agent identities.

The mcp-score tool produces CP.5.MCP compliance artifacts directly through its governance tools. The JSON report format is designed for board-presentable artifacts, not internal engineering outputs. Organizations that treat agent governance as an evidence-generating discipline, not a policy exercise, will navigate the next 18 months of the AI governance environment successfully.

What to Do This Week

1. Inventory every MCP-connected agent in your environment. Assign an ACT tier to each. Identify which have a named owner. Identify which are at ACT-3 or ACT-4 without a designated HEAR.
2. Score the MCP servers your agents are connected to. pip install aisafe2-mcp-tools. mcp-score https://each-connected-server.example/mcp. Any server below 50 should be disconnected from production systems immediately. Establish a minimum score threshold of 70 as a governance requirement for all new MCP integrations.
3. Designate a HEAR for every autonomous deployment. If you cannot name a specific individual with real-time access to stop each ACT-3 and ACT-4 agent, those deployments do not meet the minimum governance requirement. That is not a compliance observation. It is a liability exposure.

Framework and CP.5.MCP Server Scurity Profile: github.com/CyberStrategyInstitute/ai-safe2-framework/00-cross-pillar/

Pro tokens and access: cyberstrategyinstitute.com/ai-safe2/