Model Context Protocol (MCP) Exploits: How AI Agents Are Being Compromised in Production

Recently Casey Bleeker, CEO of Surepath AI, explained how Model Context Protocol (MCP) exploits actually work. At first glance nothing appears to go wrong. An AI agent processes a request, selects a tool, and executes an action exactly as designed. An email gets sent, a database is queried, a workflow completes. The system behaves normally. And that is exactly where the problem begins.

In MCP environments, actions are executed, not just suggested. The protocol connects AI agents directly to tools, APIs, and internal systems. It lets them move from reasoning to real-world action in one continuous step. Once a tool is available, the model treats it as valid. Once access is granted, the system assumes it can be used. Those assumptions stay active as the agent runs.

So how do these attacks actually happen? They don’t start by breaking into the system. They start by operating inside it. Attackers influence the instructions the model receives — through tool descriptions, external inputs, or connected systems. The model processes those instructions as legitimate and carries them out without pause. No boundary is crossed. No alert is triggered. The system simply follows the path it was given.

This article breaks down how MCP exploits work in practice. It looks at how attackers manipulate tools, inputs, and permissions to control execution, and why most AI deployments still lack governance at the exact point where it matters most — when the system decides to act.

How MCP Actually Works

In a typical MCP setup, an AI agent does more than generate an answer. It turns that answer into an action. A request comes in, the model processes it, selects a tool exposed by an MCP server, and that tool runs against a real system. That could mean sending an email, querying a database, or triggering an internal workflow. Once the tool is selected, the system moves forward without stopping.

There is no moment where it pauses to ask whether this action should still happen. It continues because that is exactly how it was built to function.

That flow carries something important with it. The model treats every available tool as something it is allowed to use. That belief comes from earlier decisions about what was connected and what permissions were given. Those decisions stay in place as the system runs. When the agent reaches the point where it needs to act, it follows the path in front of it without stepping back to reconsider whether that path still makes sense.

If you watch this system over time, a pattern becomes clear. A request turns into an instruction, and that instruction turns into execution in one continuous motion. The loop repeats every time the agent runs. Each cycle depends on the same set of assumptions that were put in place earlier. When those assumptions shift, even slightly, the outcome shifts with them. The system still behaves in a consistent way, but what it produces can drift away from what was originally expected.

This is what makes MCP important to understand. It takes what the model decides and carries it directly into the real world. Every exploit works somewhere inside that flow. The system continues doing exactly what it was set up to do, while the instructions guiding it change just enough to alter what actually gets executed.

Tool Poisoning

How does a tool that starts out perfectly normal end up steering the system in a dangerous direction? It begins with something small that looks completely routine. A new MCP tool is added to the environment. Its description explains what it does, how it should be used, and why it exists. The agent reads that description and treats it as reliable. From that point on, the tool becomes part of the system’s available actions.

Over time, that description can change. The tool can update how it presents itself without drawing attention. The agent does not go back and question whether the tool still behaves the same way it did when it was first introduced. It continues using it because it is already part of the environment. The path is already there.

So what actually changes? The instructions attached to the tool. The agent does not inspect the underlying behavior line by line. It relies on the description to understand how the tool works. When that description shifts, even slightly, the agent adjusts with it. The action still looks the same on the surface, but the outcome begins to move in a different direction.

If you follow this closely, the same pattern shows up again. A tool is trusted, then used, then reused without reevaluation. Each cycle builds on the last one. The system continues operating smoothly, while the instructions guiding that operation begin to drift. The tool does not need to break anything to change the result. It only needs to be trusted.

Prompt Injection

How does control move through a system without triggering any obvious alarms? This time the instructions do not come from a tool. They come from the data the system is asked to process. That could be a support ticket, an email, a document, or any external input the agent is allowed to read.

At first everything looks routine. The agent reads the content, extracts meaning, and prepares to act on it. That is what it is designed to do. But inside that content, an instruction can be placed in a way that blends in with everything else. It does not need to look suspicious. It only needs to be readable by the model.

The system follows it because it processes all text in the same way. It does not naturally separate what is information from what is instruction. If something is written clearly enough, the model can treat it as guidance. When that happens, the system moves forward with it just like it would with any other task.

There are cases where that instruction is not even visible to a person reviewing the content. Hidden characters or formatting can carry commands that the model reads but a human does not notice. The system continues its workflow, unaware that the direction it is following was placed there intentionally.

When you look at it over time, the same structure holds. Input becomes instruction, and instruction becomes execution. The system stays consistent. The source of the instruction changes, and the outcome changes with it.

Access and Execution Combine Inside the Same System

At what point does influence turn into something that actually carries risk? It happens when the system already has access to the things it is acting on. MCP does not just connect tools. It connects credentials, permissions, and live systems that those tools operate against. When the agent selects a tool, it is not making a harmless request. It is executing with real authority.

Those permissions are usually set up ahead of time. API keys, tokens, and service accounts are configured so the system can operate smoothly. The agent does not question those permissions when it runs. It uses them because they are already part of the environment. The access is assumed to be valid because it was approved earlier.

Now consider what happens when the instructions guiding that execution shift. The system still has the same level of access. The same tools are available. The same credentials are in place. The only difference is the direction the system is being guided to take. When that direction changes, the system carries it out with the full authority it was given.

This does not stay contained to one action. MCP environments often connect multiple systems together. A single execution can move across tools, triggering workflows in other systems without interruption. One action leads to another because everything is already connected. The system continues operating as designed, but the scope of that operation expands as it moves.

If you follow the pattern, the same structure appears again. Access is granted once, then reused continuously. Execution happens repeatedly without reevaluation. The system does not need new permissions to create impact. It only needs the instructions guiding it to shift while everything else stays the same.

Where Control Breaks Inside the System

At this point the system is doing everything it was designed to do. It processes requests, selects tools, and executes actions using the access it was given. Nothing appears to be out of place. Each step follows the same structure, and each action can be traced back to a valid instruction. From the outside, the system still looks controlled.

That is where the problem settles in. The system is governed at the moment decisions are made about what tools to connect and what permissions to grant. Policies are written, access is approved, and everything is configured before the system begins running. Once those decisions are in place, they remain active as the system operates.

What does not happen is a continuous check at the moment of execution. When the agent moves from deciding to acting, there is no built-in step that asks whether the instruction still aligns with the original intent. The system assumes that earlier decisions still apply. It continues forward because nothing interrupts that flow.

If you observe this over time, the same pattern holds. Setup happens once. Execution happens repeatedly. The system remains compliant with how it was configured, but the outcomes begin to shift as the instructions guiding it change. Everything stays within the rules that were defined, even as the results move away from what those rules were meant to produce.

This is where control actually breaks. Not at the level of access or configuration, but at the point where execution is carried out without reevaluation. The system continues to behave correctly according to its design, while the direction it follows gradually moves beyond what that design was intended to handle.