// Security

MCP made AI Agents useful and dangerous

Two years ago, connecting a language model to your company’s data meant a custom integration, a security review, and a few weeks of engineering. Today an employee can point an AI agent at your CRM, your codebase, and your ticketing system before lunch, using a single open standard called the Model Context Protocol. That standard, MCP, is the reason agents suddenly feel useful inside real companies. It is also the reason your attack surface grew this year in ways most security teams have not mapped.

It helps to understand MCP by what it does rather than how it works. Anthropic released it in late 2024 as a common way for AI models to reach tools and data. Think of it as the port that every agent plugs into, the way USB-C became the single port for every device. Before MCP, each link between a model and a system was bespoke. After MCP, an agent can discover a tool, read its description, and start calling it with almost no friction. The upside is obvious, and it is real. So is the trade. You have handed a probabilistic system a set of credentials and told it to act on your behalf, across systems that were never designed to treat a model as a user.

The agent is an insider, and it behaves like one#

Start with what is already happening, before agents even enter the picture. Verizon’s 2026 Data Breach Investigations Report found that 45 percent of enterprise employees now use AI on corporate devices, up from 15 percent a year earlier. Two thirds of them reach those services through personal accounts the company cannot see or govern. Shadow AI has become the third most common non-malicious insider action in data loss datasets, and the single data type most often walking out the door is source code.1

Now add MCP. An agent with protocol access is not a chatbot answering questions in a browser tab. It is an insider with broad reach, standing credentials, and no instinct for what it should not touch. It will read the record you pointed it at, and it will also follow a link inside that record, call a second tool, and pass data between the two, because that is what you built it to do. The judgment that stops a human employee from pasting a customer list into the wrong system is exactly the judgment an agent does not have. When people describe agentic AI risk, they usually picture a clever external attacker. The more accurate picture is a fast, tireless insider with your keys and a short memory.

What the connector actually exposes#

The uncomfortable part is that the protocol was designed for a single developer running tools on a laptop, not for a bank running hundreds of agents against production systems. In June 2026 the NSA published a Cybersecurity Information Sheet on MCP, and its findings read like a list of defaults that a security team would never sign off on if they saw them written down.2

Access control is optional. MCP components can be configured to read and process data with no required check on who or what is asking. Authorization has no mandated lifecycle, which leaves the door open to replayed tokens and hijacked sessions. Structured objects move between components without strict schema validation, so a malicious payload can ride inside what looks like ordinary tool output. Most implementations log almost nothing, which means that when something goes wrong, your incident responders are working blind. The pattern across all of it is the same. The specification made security the developer’s problem and then trusted every developer to solve it. In practice, most reach for the default, and the default is open.

When a prompt becomes a shell#

This is not theoretical. In May 2026, Microsoft’s own security researchers disclosed two vulnerabilities in Semantic Kernel, a widely used open-source agent framework with more than 27,000 stars on GitHub. Both show the same escalation path: a prompt injection turns into code running on the host.3

The first, tracked as CVE-2026-26030, lived in a search filter that built a Python expression out of model output and ran it through eval. A crafted input broke out of the string and reached the operating system. The second, CVE-2026-25592, exposed a file-write function to the model that let a payload be written into the Windows startup folder, so it would run the next time the user logged in. Neither needed a browser exploit or memory corruption. They needed only what an agent already has, which is the ability to be talked into doing something. That is the shift worth sitting with. In a traditional application, untrusted input is data. In an agent, untrusted input is instructions, and the protocol is the thing that turns those instructions into actions on real systems.

The enterprise version arrives this week, and it moves the risk#

The timing here is not academic. A major revision to the MCP specification lands on July 28, moving the protocol from a single-user, session-based design to a stateless architecture built for cloud-scale, multi-tenant deployment. It fixes real problems. Session hijacking gets harder, and servers can no longer push unsolicited prompts at clients. Enterprises should adopt it. They should also understand that it relocates risk rather than removing it.4

A stateless design leans on tracking identifiers and state objects instead of persistent sessions, which introduces its own failure modes: hijacking an active workflow, reaching data that belongs to a different agent, and triggering actions across tenant boundaries. New protocol headers make it easy for a developer to map a token or a piece of personal data into a place where every proxy, load balancer, and logging system can read it. Interactive MCP apps bring the classic web problems, including stored cross-site scripting, into the agent surface. Long-running asynchronous tasks open a denial-of-service path, where one cheap request spawns an expensive operation and then disconnects. The lesson for anyone approving this migration is simple. A cleaner protocol still puts the weight of security on your implementation, and you now have a defined window to get that implementation right before the agents multiply on top of it.

What leaders should require before they connect an agent to anything#

The good news is that the fixes are known, and none of them wait on a vendor. What they need is someone with authority to make them non-negotiable before a project ships.

Start with an inventory, because you cannot defend what you cannot see. Independent research on shadow AI suggests organizations have no visibility into roughly 89 percent of the AI activity on their networks, and the same blind spot applies to MCP servers quietly standing up inside teams.5 Scan for them the way you scan for any other unmanaged endpoint, and keep a live list of what is connected to what.

From there, treat every agent connection as a privilege decision. Give each one the narrowest set of tools and data it needs, segment those tools by sensitivity so a low-trust agent cannot reach high-value systems, and require an explicit human approval when an agent’s access is about to change. Assume tool output is hostile until proven otherwise, and validate it against a schema rather than passing it along. Run tool execution in a sandbox with operating-system-level isolation, so a prompt that becomes a shell finds itself in a box rather than on your network. Sign and timestamp the messages moving between components. And route agent activity into the same logging and monitoring your security team already uses, so an agent doing something strange at two in the morning generates an alert instead of a mystery.

None of this is exotic. It is the discipline your organization already applies to human access, extended to a new kind of user that happens to be software. The reason it gets skipped is that agents are being adopted through enthusiasm and speed, and the connector is invisible in every demo. The model is what gets the applause. The connector is what gets the breach. Put your governance, your budget, and your hardest questions where the reach actually is, which is the protocol quietly wiring your agents into everything you care about.


  1. Verizon, 2026 Data Breach Investigations Report, shadow AI findings, as analyzed by LayerX Security. https://layerxsecurity.com/learn/dbir-2026-shadow-ai/ ↩︎

  2. National Security Agency, “Security Design Considerations for AI-Driven Automation Using the Model Context Protocol,” Cybersecurity Information Sheet, June 2026. https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF ↩︎

  3. Microsoft Security Blog, “When prompts become shells: RCE vulnerabilities in AI agent frameworks,” May 7, 2026. https://www.microsoft.com/en-us/security/blog/2026/05/07/prompts-become-shells-rce-vulnerabilities-ai-agent-frameworks/ ↩︎

  4. SecurityWeek, “New Enterprise-Ready MCP Specification Brings New Security Challenges.” https://www.securityweek.com/new-enterprise-ready-mcp-specification-brings-new-security-challenges/ ↩︎

  5. LayerX Security, analysis of shadow AI visibility gaps drawing on 2026 DBIR data. https://layerxsecurity.com/learn/dbir-2026-shadow-ai/ ↩︎