What Every CIO Should Know Before Scaling AI Across the Enterprise

Enterprises are deploying AI faster than they are building the governance, identity, and security systems that deployment requires, and the resulting gaps are measurable, documented, and consistent across the industry. This is not a story about organizations moving recklessly. Adoption is accelerating and, in most cases, paying off operationally. Governance maturity has not moved at the same speed as adoption, and the distance between the two shows up in hard numbers.

The Agentics Enterprise MCP Guide 2026 draws a useful line here: "MCP adoption" and "MCP governance maturity" are separate metrics, and most organizations are tracking only the first one. That is why so many AI initiatives stall before they reach production. Only 11 to 14% of enterprise agentic AI pilots reach production, because the rest stall on identity, audit, and access-control gaps. A large majority of organizations report active AI use across business functions, but only a small fraction maintain a comprehensive AI governance framework, and that distance did not open up in a matter of weeks.

The gap widens further once agentic AI enters the picture. A large majority of organizations plan to adopt agentic AI within the next two years, but only a small fraction have a mature governance model built for AI agents specifically. Agents behave differently than the software governance frameworks were originally built around: they act, not just respond, and the controls designed for request-response systems don't map cleanly onto systems that take action on their own initiative.

The clearest evidence that this gap is structural rather than a temporary lag sits in how enterprises spend their money. Far more gets spent on AI capability than on AI security, and estimates put that imbalance at orders of magnitude. No organization budgets that unevenly by accident. The imbalance reflects where the incentives and the urgency have been pointed, which is almost entirely toward shipping capability. Closing it requires treating governance as the infrastructure that makes further scale possible rather than a brake applied after the fact. Nowhere does that gap concentrate more directly than in the protocol now connecting AI agents to the rest of the enterprise stack.

MCP: Enterprise AI's Connective Tissue and Concentrated Risk Surface

MCP has gone from an Anthropic open-source release to cross-vendor enterprise infrastructure faster than any comparable developer standard, and because of the architectural role it now plays, a governance failure inside MCP has consequences across the entire enterprise, not just the system where it originated. Understanding why requires looking at how fast, and how broadly, it was adopted.

The protocol was donated to the Linux Foundation's Agentic AI Foundation in December 2025, backed by OpenAI, Google, Microsoft, AWS, Cloudflare, and Bloomberg. That list of backers signals something important: MCP is no longer a single vendor's technology that others merely support.

Every major AI platform vendor ships MCP support today. OpenAI, Google DeepMind, Microsoft Copilot Studio, and AWS all added it shortly after launch, and the pattern repeats on the enterprise application side: CRM platforms including HubSpot, Salesforce Agentforce, and Microsoft Dynamics 365; marketing automation tools like Adobe Marketo Engage; and developer tools including Cursor, Windsurf, and Zed. MCP servers sit behind this breadth of integration as a single aggregation point, so you find credentials for multiple enterprise systems behind one interface.

The protocol also reverses a pattern security teams have spent two decades building defenses around. MCP often has servers query, and sometimes act, on behalf of connected clients rather than the other way around, as the NSA's cybersecurity information sheet notes. So that inversion opens attack paths that traditional security models were never built to trace. And the scale of exposure is only growing: IDC projections cited in Microsoft security research put the growth of active AI agents in enterprises at orders of magnitude by 2030, and every one of those agents is a potential MCP client. MCP blends instructions and data so an agent can act across systems without custom integration code for each one, and that is the same feature that makes its risk surface fundamentally different from anything a traditional API ever presented.

The specific MCP threat categories CIOs must understand

MCP introduces a threat surface that traditional API integration never had, and you can now find it formally documented across multiple threat taxonomies. The threats are no longer theoretical scenarios raised by researchers speculating about what might go wrong.

The root mechanism behind most of these threats is the same one that gives MCP its power: the protocol blends instructions, in the form of tool descriptions, with data. A change to a tool's metadata can redirect an agent's behavior just as effectively as a change to its system prompt, and that single fact is the cause behind several distinct attack categories.

Tool poisoning is the clearest example, and Microsoft Incident Response's June 2026 post documents how it plays out against a live system. A developer pushes an update to a third-party invoice enrichment MCP server connected to a Copilot Studio finance agent. The tool's name and user-facing summary never change. But hidden instructions embedded in the tool description direct the agent to retrieve unpaid invoice data and attach it to every enrichment call the agent makes afterward. The update goes live without triggering any re-approval workflow, because MCP reflects metadata changes dynamically rather than treating them as a new tool requiring new sign-off. This maps to OWASP ASI02 (Tool Misuse and Exploitation) and ASI04 (Agentic Supply Chain Vulnerabilities), categories formalized in the OWASP Top 10 for Agentic Applications released in December 2025 and updated to v2.01 in June 2026.

Supply chain compromise sits upstream of individual tools, because it embeds in the SDKs and registries agents depend on to function at all. OX Security research, titled "The Mother of All AI Supply Chains," disclosed a command execution vulnerability across Anthropic's official MCP SDKs for Python, TypeScript, Java, and Rust. The TypeScript flaw was patched in v1.26.0 under CVE-2026-25536, but the underlying STDIO transport issue remains unaddressed at the protocol level: it passes configuration parameters directly to the host operating system's shell without sanitizing them first, affecting a large number of vulnerable instances across a widely downloaded package ecosystem. The severity of that finding is reflected in an unprecedented designation: the Pentagon classified Anthropic a "supply chain risk" in early 2026, the first time an American AI company received that label.

Authentication gaps round out the picture at the infrastructure level. Trend Micro identified 492 MCP servers exposed to the internet with no authentication at all. Practical DevSecOps' statistics report found that only 8.5% of MCP servers use OAuth, and separate analysis from BlueRock Security found more than a third of a large sample of MCP servers were potentially vulnerable to server-side request forgery. Layered on top of weak authentication is confused deputy behavior: agents often execute with the MCP server's elevated credentials rather than the requesting user's actual entitlements, so a user without database admin access can ask an agent to run a query, and a server holding admin access will comply without checking whether the human behind the request was ever authorized to make it. Research backing this finding shows most agents are over-permissioned, and they hold far more access than their task requires. Lyzr's September 2026 guide names unmanaged tool lifecycles and rogue servers, alongside tool poisoning, as the dominant threats enterprises faced in 2026. These are not hypothetical failure modes: they have already produced confirmed breaches.

What confirmed incidents reveal about the real-world impact

The incident record has moved past proof-of-concept demonstrations into a growing body of confirmed breaches, and the trajectory points upward. Organizations untouched so far are exposed rather than exempt.

The clearest example involves an OAuth implementation flaw inside an MCP server integrated with the Drift customer service platform. In early 2026, security researchers disclosed that an attacker exploited this flaw to intercept and steal OAuth access tokens during Salesforce API calls. With a stolen token in hand, the attacker then got into the victim enterprise's complete Salesforce CRM customer data. The breach did not require defeating Salesforce's own security.

Regulators are responding to this category of risk, though not yet with finished rules. The Federal Reserve, the OCC, and the FDIC issued revised interagency model risk management guidance in April 2026, designated SR 26-2 and OCC Bulletin 2026-13, stating that generative and agentic AI are "novel and rapidly evolving" and currently outside the scope of existing guidance. The agencies signaled plans to issue a request for information, so financial institutions managing agentic AI sit inside an active compliance gap, and more specific guidance is known to be coming but is not yet defined. Waiting for that guidance to arrive before building controls means building them under regulatory pressure instead of ahead of it.

Accountability extends past regulators and into the boardroom. A majority of organizations that suffered AI breaches had no formal governance policy in place at the time. Only a small fraction of AI governance measures that do exist have an explicit owner assigned to them. Phantom ownership, not technical complexity, is the top implementation risk organizations are facing right now. That finding reframes the entire problem: the hardest part of closing these gaps is rarely the engineering work itself. It's deciding, in writing, whose job it is to do that engineering work and keep doing it as the environment changes. Organizations that have scaled AI without joining this incident list did that work first.

What the organizations that have scaled safely built first

The enterprises operating AI safely at scale are not the ones that moved the fastest into deployment. They are the ones that built governance infrastructure before broad deployment began, rather than retrofitting it after an incident forced the issue.

Uber offers the most complete public case study available. By early 2026, a large majority of Uber's developers were using agentic coding tools daily, AI was generating the majority of all code written inside the company's IDEs, and a single background coding agent called Minions was producing 1,800 code changes every week. Uber reached that scale by building three governance layers before scaling.

The first was an LLM gateway built with an integrated middleware stack, handling PII redaction, authentication and authorization, and audit logging for every interaction passing through it. That gateway gave Uber a single checkpoint where sensitive data could be caught before it left the system, and where every request carried a verifiable record of who made it and why. The second was an MCP gateway and registry, and it governed every agent-to-tool connection across Uber's extensive portfolio of internal services. Individual teams could have stood up MCP servers on their own, with no central visibility into what those servers could access, but Uber routed every connection through infrastructure the security team could see and control instead, so shadow servers never had a chance to form. Runlayer, as one MCP gateway and AI control plane, is built around that same principle of central visibility over every agent-to-tool connection. The third was an agent identity system, extending Uber's existing Zero Trust infrastructure to multi-agent workflows with cryptographically attested lineage attached to every tool call. So every action an agent took carried a verifiable chain back to its origin, and that closed the confused-deputy gap, where an agent inherits a server's elevated credentials instead of the requesting user's actual entitlements.

The pattern across all three layers is the same: visibility and enforcement built into the infrastructure itself, ahead of scale, rather than added as a response to a specific failure. That is the general shape the threat taxonomy earlier in this piece points toward, whatever specific tools a given enterprise chooses to implement it with. Some organizations build these layers internally, the way Uber did. The specific implementation matters less than the sequencing. Governance built before scale is what separates the enterprises in the incident reports from the ones still waiting to appear in one.