MCP Security Risks in Enterprise Agent Deployments

MCP security in enterprise agent deployments is a three-layer problem. Its risks span the instructions agents consume, the infrastructure they can reach, and the actions security teams cannot see. Closing that gap requires controls at every layer, with agent autonomy tied to what an enterprise can safely authorize, observe, and stop.

Why MCP's security problem is architectural, not incidental

MCP was designed to solve an integration problem. It standardizes how AI agents connect to tools, data sources, and services through JSON-RPC 2.0, making those connections easier to build and reuse. But a shared way to connect also gives attackers a shared surface to target. The Cloud Security Alliance's best practices guide names three separate trust boundaries, which are LLM-to-client, client-to-server, and server-to-downstream systems. A failure at one boundary can cascade through the pipeline.

Use of that design spread before security governance caught up. Anthropic's December 2025 announcement placed MCP under the Linux Foundation's Agentic AI Foundation, co-founded by Anthropic, Block, and OpenAI. The Cloud Security Alliance's guide reports that by early 2026, nearly 7,000 internet-exposed MCP servers had been catalogued, with roughly half lacking authentication controls. The same guide lists more than 30 CVEs that targeted MCP servers, clients, and infrastructure components between January and February 2026. The protocol, infrastructure, and operational attack surfaces follow from how MCP connects systems.

The protocol layer: how MCP's trust model makes tool metadata an attack surface

When an agent connects to an MCP server, it gets tool names, descriptions, and parameter schemas. It uses this metadata to decide what to call and how, so descriptive text gains influence over action. The Cloud Security Alliance's guide states that the LLM cannot independently verify whether those descriptions are accurate or unmodified. The MCP specification says descriptions of tool behavior should be treated as untrusted unless they come from a trusted server. That warning matters because an instruction to distrust metadata is not itself a mechanism for checking it.

Tool poisoning exploits this gap by placing malicious instructions in the metadata an agent consumes. A rug pull adds time to the trick, presenting legitimate metadata during approval and changing behavior afterward. Better instruction-following can make a more capable model more compliant with malicious metadata. The helpful assistant can become a very diligent accomplice.

Indirect prompt injection takes advantage of the same weakness through material agents work with, including GitHub issues, support tickets, and web pages. Language models have no hard boundary between data and instructions in their context. The GitHub MCP incident illustrates that pattern. In chained workflows, one agent's compromised output can become another's input, while growing tool inventories make correct tool selection harder.

The infrastructure layer: exposed servers, credential sprawl, and the authentication gap

Even trustworthy tool descriptions would not make the servers behind them safe. MCP servers can hold credentials for several enterprise systems, so access to all of them sits in one place. Developers often use credentials they already have, including admin-level API keys and service accounts with broad privileges. When those permissions survive into production, compromising one server can expose far more than one task requires.

Keeping that access in one place is riskier with plaintext configuration, long-lived tokens, and exposed endpoints. The Claude Code RCE incidents in January–February 2026 involved API key exfiltration through repository configuration files. The Azure DevOps MCP authentication bypass in April 2026 exposed API keys and tokens without credentials. These are infrastructure failures even when the agent's reasoning works exactly as intended.

Package distribution creates another entry point. Socket's disclosure describes how the Sandworm_Mode campaign used npm typosquatting to install rogue MCP servers through packages mimicking popular utilities. Embedded prompt injection then targeted SSH keys, AWS credentials, and npm tokens for exfiltration. As more servers and packages enter the ecosystem, the number of places that require authentication and provenance checks grows with them.

What these incidents looked like in practice: a pattern, not a parade of edge cases

Invariant Labs' May 26, 2025 disclosure showed how a malicious GitHub Issue could hijack an agent with elevated repository access. The agent encountered embedded instructions during its normal workflow and exfiltrated private repository data, including salary details and personal information, through a public pull request. The attacker did not need to replace the user's request. Content the agent was expected to read supplied the redirection, and legitimate permissions supplied the means.

The Azure DevOps MCP authentication bypass, CVE-2026-32211, reached sensitive credentials by a different route. Its CVSS 9.1 rating reflected exposure without authentication, rather than an agent confusing data with instructions. Tenet Security's June 2026 Sentry MCP event-injection finding returned to the content route, identifying injectable DSNs across a large number of organizations and a high agent execution rate in testing. Sentry declined remediation and deployed a payload-string filter, leaving the underlying architectural risk unfixed.

These incidents are not mechanically identical, which is precisely the point. Injection controls would not repair an authentication bypass, and authentication alone would not make a malicious issue safe to process. Traditional WAFs, API gateways, and DLP tools were not built to evaluate the intent behind an agent's tool call. Security has to cover both access to the machinery and what that machinery is being induced to do.

The operational layer: what enterprises cannot see, they cannot govern

The third layer concerns what defenders can reconstruct after an agent acts. The Cloud Security Alliance's guide identifies behavioral monitoring and audit logging as a distinct control domain that most current deployments do not implement. Without that visibility, a security team cannot reliably connect an action to the agent, input, permission, and approval behind it.

Unreviewed server configurations and unmapped agent-to-agent communication deepen that blind spot. An approved agent can participate in a workflow whose other connections have never been reviewed. Too many permissions and installing dependencies through trial and error make it even harder to tell where authorized work ends and uncontrolled change begins. Cisco's State of AI Security 2026 report finds that only a minority of organizations feel ready to secure agentic AI applications.

For regulated work, the missing account makes it harder to meet the rules that apply. High-risk MCP actions bring logging, human oversight, data governance, and cybersecurity into scope under the EU AI Act. Cloud-hosted interactions also create data residency exposure for organizations with HIPAA, GDPR, or financial services obligations. A vendor's security posture does not answer where a particular workflow sent data or who authorized the action.

Protocol-layer controls: treating tool metadata as untrusted configuration

The first design decision is to treat tool metadata as untrusted configuration. Approve MCP servers by publisher, version, transport, permissions, and deployment path. Block unapproved dynamic tool additions rather than trusting a server because its first introduction looked respectable. A tool description is closer to executable policy than a brochure.

Approval must also survive change. OWASP Secure Coding with AI guidance recommends pinning tool definitions and using snapshot-and-diff checks to detect updates after initial approval. Rules files such as AGENTS.md and CLAUDE.md need the same checks as CI/CD pipeline changes and must be explicitly approved. Otherwise, a workflow that has been reviewed can get new instructions without anyone deciding whether they are safe.

Microsoft Threat Intelligence's “Agents Rule of Two” supplies a further design constraint. A workflow should never simultaneously process untrusted input, access sensitive systems or secrets through tools, and have the ability to change state or communicate externally. Keeping one of those capabilities out of the same workflow limits what malicious instructions can achieve. In multi-agent pipelines, validate and sanitize outputs at each boundary rather than passing trust down the chain with the text.

Infrastructure-layer controls: scoped identity, sandboxing, and supply chain validation

Infrastructure controls begin by separating the agent's authority from the developer's authority. Give each agent only the permissions its task needs, and keep the developer's admin credentials out of its hands. Separate development, testing, and production credentials, rotate credentials in agent configuration files, and treat plaintext API keys there as potentially compromised. NIST's agent identity concept paper makes the broader requirement explicit through identification, authentication, authorization, audit, and binding agent actions to human authority.

Remote servers need enforceable authentication and validated provenance. The November 2025 MCP specification formalized OAuth 2.1 for remote servers, so enforce it. Scan for exposed endpoints through /mcp and /sse paths and check for 0.0.0.0 bindings. Pin and review package versions, include agent configuration paths in code review, and block server auto-approval settings.

Execution boundaries then limit what a compromise can reach. Its safe outputs buffer writes, validate them, and apply them in separate jobs with scoped permissions. These protections belong in development environments too, because the Claude Code incidents show that a developer's machine is an infrastructure node.

Operational-layer controls: visibility, human oversight, and a governance maturity model

Operational controls give the other layers a feedback loop. Maintain a registry and allowlist of approved servers and tools, with review for agent instructions and custom agents. An MCP gateway can enforce scoped identity and allowlists while providing audit logging. Record tool discovery, inputs, outputs, identity, approval decisions, and results at each call. Without those records, an approval policy is a rule with no reliable account of whether it was followed.

Human oversight belongs where consequences warrant it. The MCP specification recommends that a human should be able to deny tool invocations. Show the exact operation and require approval for high-impact actions.

Governance maturity should be measured separately from adoption. The Cloud Security Alliance's four-level MCP Security Maturity Model provides an internal audit framework, progressing from basic authentication and transport security to continuous verification. That progression makes oversight and regulatory obligations technically achievable. These controls make the consequences of MCP's original design priorities observable and governable.

How an autonomy slider changes the MCP risk calculus for engineering teams

Agent autonomy is a dial. At the low end, an agent that makes suggestions without external tool calls has little chance to turn poisoned metadata into action outside itself. As it gains terminal access, API calls, repository writes, and CI/CD responsibilities, the same malicious instruction can have greater consequences. Each increase in independence makes another control necessary.

This matters when agents work across a development environment, terminal, team messaging platform, and GitHub. Those locations are not interchangeable permissions simply because they share a conversational interface. An autonomy setting should govern what the agent can do, which systems it can reach, and which actions remain subject to developer approval. Microsoft's Rule of Two belongs in that configuration.

Parallel agents add a second dimension to the decision. Their communication flows must be mapped and scoped before broad deployment, because one agent's work can become another's instructions. Routing simpler tasks to cost-efficient models and harder tasks to frontier models also spreads the attack surface across models, making orchestration security central.

What enterprises should do before the next MCP server goes into production

Audit the MCP servers connected to development environments and establish the approved set of servers, tool definitions, and rules files. Then check the deployment boundary through endpoint scanning, credential rotation and separation, OAuth 2.1 enforcement, and sandboxed execution for agents with write access. Finally, put the gateway, audit trail, human approvals, and output security checks in place. The sequence matters because permission should follow evidence of control.

Known tooling vulnerabilities also need explicit closure. Update Claude Code and other MCP-connected development tools to current patched versions. CVE-2025-59536 is patched in Claude Code 1.0.111+, and CVE-2026-21852 is patched in Claude Code 2.0.65+. Add agents and MCP servers to the threat model as infrastructure nodes, and map dependencies on AI providers and MCP servers before scaling the next pilot.

Use the Cloud Security Alliance's maturity model to assess that readiness. MCP governance is now a prerequisite for scaling enterprise agentic AI. The enterprises positioned to move pilots into production will treat MCP with the rigor of an API gateway or identity provider, because that is the level of authority they are giving it.