Two years ago, connecting an AI assistant to a company database meant a week of integration work. Now it means pasting a block into a config file, restarting the client, and watching the model query production tables within minutes. The Model Context Protocol made that possible, and it did for tool integration roughly what Docker did for packaging: it collapsed a pile of bespoke glue into one standard shape.
That convenience is also the problem. An MCP server is not a connector in the passive sense. It is a process with file access, network access, and whatever credentials it was handed, running on a machine you own, invoked by a language model that can be talked into doing something nobody planned. Most organizations onboard one with the diligence they apply to a browser extension.
Where the risk actually sits
The security conversation around MCP usually starts in the wrong place. The protocol is not badly designed for its purpose. The issue is that a connector is executable code inside your trust boundary, and the ecosystem around it moves faster than any review process. By mid-2025 the ecosystem had passed 150 million package downloads and several thousand community servers covering databases, CRMs, ticketing systems, code repositories, and browser control. Very few of those servers were written by anyone whose name appears on a vendor contract.
Risk concentrates in four places in a typical mid-size environment, and they are not the places security teams usually watch.
- Developer laptops. Local STDIO servers launched from an editor config, often installed to test something once and left running.
- CI and build agents. Servers wired into pipelines, holding deployment tokens, executing whatever the repository says.
- Customer-facing assistants. Support bots and chat agents that read untrusted input and hold write access to a system of record.
- Internal copilots. Search and document assistants connected to shared drives, wikis, and email archives with no per-user scoping.
Each one is defensible on its own. The combination is where incidents come from.
What the 2026 disclosures showed
In April 2026, OX Security published research on the STDIO transport that most local MCP integrations use by default. Official SDKs in several languages pass tool configuration into operating system command execution without sanitizing it. Anyone who can influence a server definition, through a config file, an IDE extension, a marketplace listing, or a compromised repository, gets command execution on the host. The Cloud Security Alliance put the exposure at roughly 200,000 instances across a supply chain carrying more than 150 million downloads. Anthropic's position was that the behaviour is intentional and the protocol would not change, which leaves remediation with every downstream developer.
That last sentence matters more than the CVE count. The steward of the protocol declined to fix the default and handed the problem to the people adopting it. That is how open standards often work, and it means nobody upstream is coming to protect you.
The same Cloud Security Alliance note lists at least seven confirmed high or critical vulnerabilities by May 2026 across MCP Inspector, LiteLLM, Cursor, LibreChat, and Windsurf. A July 2025 internet scan found 1,862 MCP servers answering unauthenticated requests in the open. The specification does define an authorization framework, but it marks authorization as optional. Optional security is a precise description of what will not get done.
Tool poisoning
Simon Willison documented this in April 2025 and it has aged badly in the wrong direction. A tool's description text is passed to the model, and in many clients that text is never rendered for the user. An attacker who controls a server can bury instructions in a docstring: read the local SSH key, include it in the next query, do not mention that you did. The user sees a tool called search_docs. The model sees a job description. Invariant Labs later demonstrated cross-server tool shadowing, where one malicious server changes how the model uses a different server that everyone already trusts.
Rug pulls and silent drift
You review a server at version 1.2, approve it, and the maintainer ships 1.3 with a new endpoint and broader permissions. Nothing in the protocol requires you to notice. Snyk's ToxicSkills audit scanned 3,984 agent skills and found at least one security flaw in 36.82 percent of them. If roughly a third of a reviewed sample fails a basic audit, an unreviewed server is a coin flip with better branding.
The failure mode that never reaches the risk register
Most MCP incidents will not look like an exploit. They will look like a model doing something useful with too much authority.
Picture a support agent wired to a ticketing system, a customer database, and a refund API. Each integration is reasonable. Together they form what Willison calls the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally. A customer email arrives with instructions buried in the body. The agent reads the ticket, queries the customer record, and posts the result to an endpoint the attacker controls. No vulnerability was exploited. Every component did what it was configured to do. The design simply built a path from untrusted input to sensitive output and let a model walk it unattended.
IBM's 2026 Cost of a Data Breach report found shadow AI in 43 percent of breached organizations, up from 20 percent a year earlier, with those breaches averaging $5.39 million against $4.63 million for the rest. It also found that 92 percent of organizations reporting an AI-related breach lacked proper AI access controls. None of those controls are exotic. They are the same ones that would have contained a rogue service account in 2019.
Why patching does not close this
CVE-2026-32173 makes the point cleanly. A missing authentication check let unauthenticated callers read data they should never have seen. A patch shipped, and the standard reflex is to apply it and move on. That reflex is what keeps producing the next advisory, because it treats each instance as an isolated defect rather than a symptom of an ecosystem where server code, tool descriptions, and permissions all change independently and nobody is tracking the combination.
Organizations survived Log4Shell through code they did not write. MCP creates a similar blind spot at a faster cadence, with a smaller artifact and a larger blast radius, because the artifact sits beside your data and your credentials instead of inside a build pipeline.
A patch cadence also assumes you know what you are running. Most teams do not. Ask a security lead how many MCP servers employees connected to company systems last month, and the honest answer is a guess.
Six controls that make an agent deployment auditable
These are not a product pitch. They are the minimum that lets you answer a question from a client, an auditor, or an insurer without scheduling a meeting.
- Inventory every server, with a named owner. Record the command or URL, version, author, hosting location, credentials held, systems reached, and the person accountable. Include local servers on developer machines, browser extensions, and anything in a config the security team has never seen. Attach it to the existing asset register rather than starting a spreadsheet that dies in six weeks.
- Pin versions and hash the tool definitions. Version pinning handles the package. Hashing the tool schema handles the rug pull. Alert when a server's tool list changes, because a new tool appearing after approval is the actual attack, not the version bump.
- Scope credentials to the tool, not the tenant. A server that reads support tickets does not need write access to billing. Use short lived tokens, one service identity per integration, and read-only database roles with row limits where possible. This is unglamorous work that eliminates most of the expensive outcomes.
- Log tool calls, not just prompts. Prompt logging tells you what a user typed. Tool-call logging tells you what the agent did: which server, which tool, which arguments, what came back, and under which identity. Route it to the same log store as the rest of your infrastructure and keep it long enough to investigate.
- Put a gateway between agents and servers. One egress point that allowlists approved servers and enforces per-tool policy gives you visibility and a kill switch. Run it in monitor-only mode first, tune against real usage, then enforce. Teams that start with blocking get bypassed by personal API keys inside a week.
- Write the agent into the incident response plan. Who disables which server, who revokes which credential, who notifies the client. If the answer requires convening a meeting, the plan is not finished.
A thirty day sequence that produces evidence
Week one is discovery, and it is mostly asking people. Pull editor configs, browser extension inventories, CI definitions, and container images. Grep for known MCP client config paths and for server package names. Produce a list with owners, even an incomplete one, because an incomplete list with names beats a complete list nobody owns.
Week two is triage. Sort the list by what each server can reach. Anything holding production credentials, customer data, or payment access goes first. Anything with no owner gets disabled or reassigned, which usually removes a third of the list without argument.
Week three is tightening. Pin versions, hash tool definitions, rotate credentials to scoped short lived tokens, and turn on tool-call logging for the servers that survived triage. Expect two or three integrations to break because they depended on an over-broad credential, and treat those breakages as the finding rather than the cost.
Week four is the written record. A one-page policy covering approved servers, approval process, review cadence, and the incident steps. That page is what turns a series of configuration changes into something you can hand to a client's procurement team.
Questions to ask before the next deployment
Does the vendor publish advisories and a changelog for their servers, or is the repository a single commit from eight months ago? Is authorization enabled, or was it left optional because the demo was easier that way? Which identity does the agent act as, and can that identity be separated from a human in your audit logs? What happens when a tool returns an error message containing attacker controlled text, and does the model treat it as data or as instruction?
Uncomfortable answers are the finding. The fix is a week of configuration and a policy page, not a platform migration.
What good looks like a year from now
MCP is not going away, and the organizations getting real value from it are not the ones with the strictest bans. They are the ones that onboarded a small number of servers deliberately, wrote down what each one can reach, and kept the list current as the ecosystem churned. That is a supply chain program on a mid-size budget, and it is the same discipline that keeps a payment integration or a webhook pipeline out of the incident report.
Treat an MCP server as a dependency with an owner, a version, and a log. Teams that do will keep shipping agents. Teams that treat it as configuration will meet the problem for the first time during an incident review, when the question is no longer whether the model was useful but who approved the access it had.
