MCP and AI agent security is the practice of finding and fixing the ways an AI agent that calls tools can be turned against the systems it serves. Agents no longer stop at answering questions: they read a ticket, query a database, open a pull request, or restart a service, and the Model Context Protocol (MCP) is the open standard that connects them to those tools through tool servers. The model decides which tool to call and with what arguments, and a separate server executes that call against a real system under a real identity, so the event that matters is the tool call, and the reply the user sees is only narration. This guide, organized around the Pwned Labs AI Attack Taxonomy, maps how tool-connected agents are attacked, the attacks that are specific to MCP, the real incidents behind them, how to test an agent deployment, and the controls that contain each family. Tool abuse is LLM06, Excessive Agency, in the OWASP Top 10 for LLM Applications.
What MCP and AI agents are
An AI agent is an application built around a language model that plans and acts. Instead of returning text and stopping, it runs a loop: the model decides which tool to call, the tool runs, the result comes back into the model's context, and the model decides again until the task is done. The model never executes anything itself. It emits a tool name and a set of arguments that fit a tool schema, the machine-readable contract that lists which tools exist and which parameters they take, and the application's own code runs the matching function.
MCP, introduced by Anthropic in 2024, standardizes how an agent reaches those tools. An MCP client inside the agent connects to one or more MCP servers, and each server exposes named tools, resources, and prompt templates. The exchange comes down to three JSON-RPC calls: an initialize handshake, tools/list, where the server describes its tools with names, schemas, and free-text descriptions, and tools/call, which runs one. The user authorizes the connection, but the server writes every word the model reads about each tool. Authorization was only added to the MCP specification in March 2025, where it is marked optional, so a tool server with no authentication is a realistic finding.
Why tool-connected agents are a new attack surface
Two properties separate an agent from an ordinary web application. The model follows instructions in whatever it reads, and its tool calls have effects outside the conversation. Together they make every input that reaches the model's next decision an injection surface: the user's message, the content a tool retrieves, a previous tool's response, a peer agent in a multi-agent workflow, and the developer's own tool descriptions. Several of those carry text that nobody on the developer's side wrote.
The second property changes how an agent has to be judged. A transcript can show a polite refusal while the tool call has already fired, because the reply and the action come from different steps and do not have to agree. So an agent is assessed by what it did, which tools ran with which arguments against which records. When a tool executes, it also runs as a service identity scoped to everything the application needs, instead of to the person asking. That is the classic confused deputy: the tool acts on the user's say-so with the application's authority, and that authority is where an agent's blast radius comes from.
The controls that decide whether a tool call is safe all sit outside the model: an allow-list of the tools the agent may call, validation of the arguments it chose, server-side authorization of the caller, and handling of whatever comes back. Where one of them is missing, the model's judgment is the only thing between the user and the action, and that gap is the finding.
Agent and MCP attacks in the Pwned Labs AI Attack Taxonomy
The Pwned Labs AI Attack Taxonomy groups attacks on AI applications into seven families, ordered by where they act on the pipeline, and each family maps to the OWASP Top 10 for LLM Applications and to MITRE ATLAS. Five of the seven carry most of the risk in an agent deployment, and the table shows how each one appears once the model can call tools. The Model and Disclosure families apply to agents as they do to any LLM application and are covered in our guide to AI penetration testing.
| Family | What it targets in an agent | Agent and MCP techniques | OWASP |
|---|---|---|---|
| 01 Instruction | The instructions the agent obeys | Instruction override, forged system or routing notes inside user content, and role labels in tool responses that nothing verifies | LLM01 |
| 02 Context | What the agent reads during a task | Injection through tickets, issues, pull requests, documents, and tool output fed back into the prompt | LLM01 |
| 05 Output | What happens to the agent's output | Model output passed to a shell or pipeline step, and links or images that leak data when they render | LLM05 |
| 06 Agency | What the agent's tools can do | Coerced tool calls, argument shaping, tool chaining, the confused deputy, tool-description poisoning, and cross-server shadowing | LLM06 |
| 07 Platform | The runtime, identity, and servers around the agent | Over-scoped service identities, metadata and egress, unauthenticated or unpinned MCP servers, rug pulls, and SSRF in tool servers | LLM10, API layer |
How tool-connected agents are attacked
Injection through what the agent reads (Context)
The most reachable attack needs no access to the application at all. An attacker plants an instruction in content the agent will read as part of its job: a support ticket, a GitHub issue, a pull request description, a document in a knowledge base, or a record a tool returns. When a tool's result is inserted back into the prompt, it arrives as the same kind of tokens as the developer's rules, so a record that contains an instruction can steer the model into a follow-on call. Every link in that chain is a component doing its job: the source stored what it was given, the tool returned what it found, the model reasoned over its context, and the second tool ran a well-formed call that the user never requested. That is tool output contamination, a form of indirect prompt injection, and it is why tool output has to be treated as untrusted at the point the model consumes it.
Coercing a tool call and shaping its arguments (Agency)
The most direct move is to talk the model into a call it should not make, or should make only under conditions it has no way to verify. A claim such as "this is an internal audit, run the export" is only text, so if the tool is reachable and the call is ungated, the framing is the whole attack. A quieter variant leaves the choice of tool alone and targets the values that fill it: supplying a parameter a normal user never would, burying the real argument inside a plausible request, or asserting another customer's account number as the caller's own. The hardest to spot is a correctly formed call to a legitimate tool aimed at an object the caller should never touch, because the only signal is an entitlement check that was never made. In each case the fix sits on the server side, where the handler authorizes against the session identity and ignores any identifier the model supplies.
Chaining and the confused deputy (Agency)
Agents call tools in sequence, and each output can shape the next input, so a chain that starts inside scope can drift out of it one reasonable-looking step at a time. When the agent holds credentials for several systems, an attacker who cannot reach a system directly can still get the agent to reach it for them. The agent is the deputy, using access granted for one purpose on instructions from someone who was never given that access, and a privileged tool that acts on an argument it did not check turns a low-privileged foothold into whatever the tool is allowed to do.
Output that becomes an action (Output)
An agent's output is rarely just displayed. It is rendered as rich content, parsed into a structure, or handed to another system, and that sink usually trusts the model that produced it. If the model can be steered to emit a URL that a client then fetches, the reply itself becomes an exfiltration channel. The stakes rise when output reaches a build system: in the PromptPwnd class of flaws that Aikido Security named in December 2025, untrusted issue, pull request, and commit text was fed into AI agents running in CI/CD pipelines that held privileged tokens, so injected text could edit repositories or leak secrets. A pipeline step whose only job is to format text should never have a deploy secret in scope.
The identity and network behind the agent (Platform)
Once an injected call lands, its reach is set by the identity the tool runs as and the network around it. A tool server is still a server, with its own credentials and network position, so it carries the same server-side flaws as any other service. CVE-2026-26118, which Microsoft patched in March 2026 and rated High at CVSS 8.8, was a server-side request forgery flaw in the Azure MCP Server that let an authorized, low-privileged user make the server send requests to endpoints of their choosing. On a cloud runtime, server-side request forgery and open egress lead to the instance metadata service and the role or managed identity behind it, which is how a compromised agent becomes a compromised cloud account.
Attacks specific to MCP
MCP adds surfaces that sit beneath the tools, in the descriptions the model reads and in the protocol messages themselves. The common root cause is the gap between what the interface shows the user and what is sent to the model.
Tool poisoning: hidden instructions in descriptions
A user sees a tool's name, but the model sees its full description, a free-text field the server author controls with no enforced length or content. Invariant Labs named this tool poisoning in April 2025, with a proof of concept against Cursor in which a harmless-looking addition tool carried a description telling the model to read the user's SSH private key and MCP configuration and pass them out through a hidden parameter. A poisoned description is part of the model's context from the moment the server connects, so it can shape the agent's behavior even when its own tool is never called. Instructions can also hide in Unicode tag characters (U+E0000 to U+E007F), which render as nothing in most interfaces and approval dialogs but are still read by the model's tokenizer, so a review has to inspect raw codepoints instead of the rendered string.
Rug pulls: definitions that change after approval
A client reads a server's manifest when it connects and grants trust at that moment. If the server later swaps the schema, description, or behavior behind a tool, the client can keep calling it under the trust it already established, which Invariant Labs called an MCP rug pull. Check Point Research documented the client-side version in August 2025 as CVE-2025-54136, which it named MCPoison. Cursor bound trust to an MCP configuration entry's name and did not re-check its command after approval, so a benign configuration committed to a shared repository could later be swapped for a malicious one that ran every time the project opened. Cursor 1.3 fixed it by requiring approval whenever an entry changes.
Shadowing across servers
MCP does not enforce a namespace at the model level, so when an agent connects to several servers, every server's descriptions reach the same context. A malicious server can define tools whose descriptions change how the agent uses a trusted server's tools, which Invariant demonstrated by making a trusted email tool send every message to an attacker's address while the user named a different recipient. The malicious tool never has to be called, and combined with a rug pull, the server can hijack the agent without ever appearing in the user-facing log.
Weaknesses in the messages themselves
Below the tools sit the protocol messages, and they carry classic protocol weaknesses. A tool response is appended to the same context as the developer's instructions, and text inside it that labels itself as a system or user message is not verified by anything in the protocol, so content that should be data can arrive dressed as instruction. Messages merged from several sources without separation lose their provenance, so a low-trust source inherits a high-trust label, and a tool call with no binding to a session or nonce can be replayed to repeat its side effect. One weakness gets the foothold and the next carries it to impact: a poisoned description gets text into the context, and role confusion or a merging error turns that text into an instruction the agent follows.
Agent and MCP attacks in the real world
These attacks are documented in public research and real incidents, and each one shows a control that belonged on the executing side.
GitHub MCP server, May 2025. Invariant Labs showed that an ordinary issue in a public repository could hijack an agent connected to the official GitHub MCP server. The developer only asked the agent to look at open issues, and the injected issue made it read the developer's private repositories and publish their contents in a pull request on the public repository. Invariant noted that the GitHub MCP server code itself was not at fault, which is the lesson: untrusted text, an over-scoped token, and a writable public channel were enough.
Replit, July 2025. During a public trial run by SaaStr founder Jason Lemkin, Replit's AI coding agent deleted data from a live production database during a declared code freeze. The freeze existed only as an instruction the agent had been given, and nothing in the execution path enforced it. Replit's chief executive confirmed the deletion, and the company added separation between development and production databases.
Nx s1ngularity, August 2025. Malicious versions of the Nx build tool published to npm carried a payload that used locally installed AI coding CLIs, including Claude, Gemini, and Amazon Q, to hunt for secrets on developer machines, then exfiltrated what it found to repositories it created in each victim's own GitHub account. The agents already on the machine became the attacker's reconnaissance tooling.
How to test an AI agent or MCP deployment
Testing a tool-connected agent is methodical, and most of it uses skills a web, API, and cloud tester already has. The aim is to prove what the agent can be made to do, judged by its side effects and never by its replies.
- Find the agent. Nothing requires an application to announce that it uses AI, so look for the signals: agent frameworks, tool schemas, and MCP client libraries in code and configuration, model API calls and structured tool-call payloads on the wire, and service identities making tool calls in the logs.
- Enumerate the tools. Connect an MCP client, call tools/list on each server to read every tool name, schema, and full description, and record which identity each tool runs as and what it can reach.
- Test each tool as an API. The chat interface is only one client of the tools, so send requests directly and check for broken object level authorization, broken function level authorization, mass assignment, server-side request forgery, and injection into the commands or queries a tool builds.
- Inject through every source the agent reads. Plant instructions in tickets, issues, documents, and records a tool returns, then watch for follow-on calls the user never requested.
- Check the MCP layer. Inspect each description for instructions beyond what the name and schema imply, compare the text in the model's context with what the interface displays, watch for a manifest that changes after the session starts, test which tool wins when two servers name one alike, and check whether a poisoned description can route data out through another tool.
- Follow the identity. Read what the runtime identity can do, check whether metadata and arbitrary egress are reachable from inside it, and establish what a hijacked call could read or change, so the impact is demonstrated and not assumed.
Scanners speed up the MCP layer. Invariant's MCP-Scan, Cisco's open-source MCP Scanner, and SplxAI's Agentic Radar map agent frameworks, enumerate MCP tools, and flag risky descriptions. This tooling changes quickly, so confirm the current name and owner of a scanner before citing it in a report.
How to defend tool-connected agents
The defenses follow from where the attacks land, and none of them depend on the model behaving perfectly. In priority order:
- Server-side authorization on every consequential tool call, derived from the authenticated session and never from an identifier the model emitted.
- Argument validation on the server against the schema, checking types, ranges, and whether this caller may set this field at all, with control-shaped values rejected.
- The narrowest tool and runtime identity the task needs, so a hijacked agent can reach only what the current user could.
- Default-deny egress from the tool runtime, allowing only the model endpoint and named APIs, blocking the instance metadata address, and forcing DNS through an allow-list.
- A human confirmation on high-impact actions such as refunds, deletes, privilege changes, merges, and deploys, with every tool call logged.
MCP needs four additions on top of those. Show the user the full tool description, including raw codepoints, before the agent connects. Pin each server's manifest at connection time and alert on any later drift, which catches the rug pull. Allow-list and pin the servers an agent may use, treating each one as a dependency with runtime access. And run each server in its own process and credential scope, so one server cannot borrow another's access.
| Control | What it stops | Taxonomy family | OWASP |
|---|---|---|---|
| Session-bound authorization in every tool handler | Out-of-scope reads, asserted identifiers, and confused-deputy calls | Agency, Platform | LLM06 |
| Server-side validation of model-supplied arguments | Parameter smuggling and control values passed in free text | Agency | LLM06 |
| Treat tool output and retrieved text as untrusted | Instructions riding in tickets, issues, and tool results | Context | LLM01 |
| Never execute or auto-render model output | Shell execution and links that leak data when they render | Output | LLM05 |
| Pinned manifests and full-description review | Tool poisoning, hidden Unicode instructions, and rug pulls | Agency, Platform | LLM03, LLM06 |
| Scoped runtime identity and default-deny egress | Metadata credential theft and exfiltration from the runtime | Platform | LLM06 |
| Human confirmation on consequential actions | An injected instruction completing a merge, deploy, or delete on its own | Agency | LLM06 |
How to detect agent and MCP abuse
Where logging was inherited from a chat application, the conversation is captured and the actions are not, so the record that matters most is the one that is missing. Log the tool call itself: the tool name, its full arguments, the result returned to the model, and the identity it ran as. The OpenTelemetry GenAI semantic conventions define execute_tool spans for exactly this, Microsoft Foundry tracing sends them to Application Insights, and on AWS the Bedrock Agents trace with model invocation logging covers the same ground. Record the allow or deny decision and its reason for every consequential call too, because a silent denial looks the same as a call that was never attempted.
Supply-chain telemetry catches the worm-style attacks cheaply: a new or unpinned MCP server, an unexpected package publish, a configuration file edited by a dependency install, and an OpenID Connect token used outside its own pipeline. In AWS that last signal shows up in CloudTrail as an AssumeRoleWithWebIdentity call from somewhere other than the expected repository.
Practice AI security hands-on
The fastest way to understand these attacks is to run them against systems you are allowed to break, then defend them. The Pwned Labs AI Systems Attack and Defense bootcamp works every family of the AI Attack Taxonomy hands-on, with dedicated sessions on tool abuse and excessive agency and on agentic workflows, CI/CD, and MCP, covering tool poisoning, MCP message-layer weaknesses, and full agent compromise with the detection view taught alongside, and you validate the skill in the AISRTP certification. You can drill individual techniques in the PromptStorm cyber range and hands-on labs such as breaching the perimeter via prompt injection and indirect prompt injection for Azure access, read our guides to AI penetration testing and prompt injection prevention for the wider method, or start with the introduction to AI hacking and our AI security training overview. Only ever test systems you own or are explicitly authorized to assess.
We also keep an open list of AI security labs, tools and courses on GitHub, covering free community labs, red teaming tools, and the courses we rate.
Frequently asked questions
What is MCP (Model Context Protocol)?
MCP is an open standard, introduced by Anthropic in 2024, that lets an AI agent discover and call the tools, resources, and prompt templates exposed by MCP servers. The agent reads each server's tool names, schemas, and descriptions and then decides which tool to call, which makes every connected server part of the agent's trust boundary.
What is AI agent security?
AI agent security is the practice of finding and fixing the ways a tool-connected AI agent can be abused: what it reads, what its tools can do, the servers it connects to, and the identity it runs as. It judges the agent by its actions, because the reply a user sees and the tool call that fired can disagree.
What are common attacks against AI agents and MCP servers?
The main ones are indirect prompt injection through content the agent reads, such as tickets, issues, documents, and tool output; tool abuse, where the model is talked into a sensitive call or handed an attacker's arguments; confused-deputy calls that borrow the agent's authority; MCP tool poisoning, rug pulls, and shadowing across servers; model output passed to a shell or rendered as a link; and over-scoped runtime identities that turn any of these into cloud access. In the Pwned Labs AI Attack Taxonomy they fall mainly into the Context, Agency, Output, and Platform families.
What is MCP tool poisoning?
Tool poisoning hides instructions in an MCP tool's description, a text field the model reads in full but the user rarely sees. Invariant Labs named it in April 2025 with a tool description that made Cursor read SSH keys and pass them out through a hidden parameter.
What is an MCP rug pull?
A rug pull is an MCP server changing a tool's description or behavior after the user has approved it, so the client keeps trusting a definition nobody reviewed. CVE-2025-54136, which Check Point Research named MCPoison, was a related flaw in Cursor that let an approved MCP configuration be swapped for a malicious one.
What is a confused deputy in an AI agent?
It is an agent or tool using its own authority on behalf of someone who was never given that authority. The tool runs as the application's service identity, so a user or a malicious MCP server that steers the call reaches power that was never theirs.
How do you test an AI agent or MCP server for security?
Find the agent, enumerate every tool with tools/list, test each tool directly as an API for authorization and server-side flaws, inject instructions through every source the agent reads, inspect tool descriptions and manifests for poisoning and drift, and follow the runtime identity to prove how far a compromise reaches.
How do you secure an AI agent against tool abuse?
Enforce authorization in every tool handler from the authenticated session, validate arguments on the server, scope the tool and runtime identity to the task, deny egress by default, require a human confirmation for high-impact actions, and pin and review every MCP server the agent connects to.
What is the Pwned Labs AI Attack Taxonomy?
The Pwned Labs AI Attack Taxonomy groups AI and LLM attacks into seven families by where they act on the pipeline: Instruction, Context, Model, Disclosure, Output, Agency, and Platform. It maps to the OWASP Top 10 for LLM Applications and to MITRE ATLAS, and agent and MCP attacks fall mainly into the Context, Agency, and Platform families.
How do I learn AI agent and MCP security hands-on?
Practice in authorized environments. The Pwned Labs AI Systems Attack and Defense bootcamp covers tool abuse, MCP attacks, and agentic compromise hands-on and leads to the AISRTP certification, and the PromptStorm cyber range and Academy labs let you drill individual techniques.