Securing AI Agents and MCP Servers: The OWASP Top 10 for Agentic Applications and What to Test
Securing AI agents means securing what they can do, not only what they say, because an agent that reads email, writes code and moves money acts on every instruction it meets. The OWASP Top 10 for Agentic Applications, the MCP attack classes, the real CVEs so far, and a test plan for agents and the tool servers they call.
AI Security
A chatbot that says something wrong is embarrassing. An agent that does something wrong is an incident. The difference is tools: an agent reads your email, queries your database, edits your code and, increasingly, moves your money, and it acts on every instruction it meets, whoever wrote it. The Model Context Protocol (MCP) has made connecting those tools easy, which is exactly why it has become the most interesting attack surface in enterprise AI. Here is what the OWASP Top 10 for Agentic Applications says, how MCP servers get attacked, what has actually gone wrong so far, and how to test an agent before it goes to production.
In short. Treat every tool an agent can call as an input, every input as a possible carrier of instructions, and every permission the agent holds as something an attacker can use through it. Give agents their own identities with the narrowest scopes the task needs, authenticate every MCP server connection, review tool descriptions as carefully as code, keep a human approval step in front of anything irreversible, and log every tool call. Then test the whole thing the way an attacker would: through the content the agent reads, not only the prompt box.
Why agents change the security problem
A large language model on its own can only produce text. An agent wraps that model in a loop: it is given a goal, it plans, it calls tools, it reads the results and it decides what to do next, often many times, often without a person watching each step. The tools are what give it reach: file systems, browsers, email, ticketing systems, code repositories, databases, payment APIs.
That loop creates a new kind of weakness. The model cannot reliably tell the difference between the instructions you gave it and instructions hidden in the content it reads. A web page, a support ticket, a calendar invite or a document in a shared drive can contain text that says, in effect, "ignore what you were asked and do this instead", and the agent may do it, using your credentials. Security researchers call this indirect prompt injection, and it is the thread that runs through most of the attacks below.
The vendors building these systems say so themselves. Anthropic's documentation for its computer-use tool warns that "in some circumstances, Claude follows commands found in content even when they conflict with your instructions", and advises isolating the agent from sensitive data and actions. The MCP specification states that MCP "itself cannot enforce these security principles at the protocol level", and that "tools represent arbitrary code execution and must be treated with appropriate caution." The responsibility sits with the people deploying the agent.
The OWASP Top 10 for Agentic Applications
In December 2025 the OWASP GenAI Security Project published the first Top 10 for Agentic Applications, developed, in its words, "through extensive collaboration with more than 100 industry experts, researchers, and practitioners." It extends the OWASP Top 10 for LLM Applications rather than replacing it. The ten risks, with what each means in practice:
| ID | Risk | What it looks like |
|---|---|---|
| ASI01 | Agent Goal Hijack | Content the agent reads redirects what it is trying to achieve, for example a hidden instruction in a document it summarises |
| ASI02 | Tool Misuse and Exploitation | Legitimate tools used in ways nobody intended, within the permissions they were given |
| ASI03 | Identity and Privilege Abuse | The agent inherits a user's or a service's credentials without scoping, so it can do everything they can |
| ASI04 | Agentic Supply Chain Vulnerabilities | Malicious or compromised tools, MCP servers, agent definitions and registries |
| ASI05 | Unexpected Code Execution | Code the agent generates or runs bypasses the controls that apply to code people write |
| ASI06 | Memory and Context Poisoning | Persistent corruption of what the agent remembers, including shared context and embeddings |
| ASI07 | Insecure Inter-Agent Communication | Weak authentication or discovery between agents that delegate to each other |
| ASI08 | Cascading Failures | One wrong step propagates through a chain of agents and workflows |
| ASI09 | Human-Agent Trust Exploitation | People defer to the agent because it sounds confident, so the human check stops working |
| ASI10 | Rogue Agents | Agents whose behaviour drifts from their purpose, or that act together or replicate |
If you already test against the LLM Top 10, note that its 2026 edition, published in August, moved Excessive Agency up to third place and renamed System Prompt Leakage to Hidden Context Exposure. Our article on what changed in the 2026 LLM list covers that. The agentic list picks up where it stops: the LLM list is about the model and its inputs and outputs; the agentic list is about what happens when the outputs become actions.
What MCP is, and why it matters to security
The Model Context Protocol was announced by Anthropic in November 2024 as "an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools." An MCP server exposes tools, resources and prompts; an MCP client, usually inside an agent or an IDE, discovers them and calls them. In December 2025 Anthropic donated the protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI, and the current specification is the 2026-07-28 revision.
MCP solved a real problem: before it, every agent needed custom integration with every tool. It also created a marketplace of thousands of community-written servers that developers install with a single line of configuration, often running with their own credentials. Three properties of the protocol matter for security:
- Tool descriptions are read by the model. The text a server uses to describe its tools goes into the model's context. The specification says descriptions of tool behaviour "should be considered untrusted, unless obtained from a trusted server."
- Authorisation is optional. The specification states that "authorization is OPTIONAL for MCP implementations." Where it is used, it is based on OAuth 2.1, and servers "MUST NOT accept or transit any other tokens." Many servers in the wild use nothing at all.
- Servers run where you put them. A local server has whatever access the process has; a remote server is an internet-facing service with all the usual web application risks.
The Cloud Security Alliance's draft MCP security guide from March 2026 cited research finding "nearly 7,000 internet-exposed MCP servers", about half with no authentication, and "over 30 CVEs targeting MCP servers, clients, and infrastructure components" filed in the first two months of 2026. Both figures come from vendor scans and should be read as indicative, but the direction is clear.
How MCP servers get attacked
Most of the named attack classes were documented within months of MCP becoming popular. The names below come from the researchers who described them and from the specification's own security guidance.
Tool poisoning
Described by Invariant Labs in April 2025: "malicious instructions are embedded within MCP tool descriptions that are invisible to users but visible to AI models." A tool that claims to add two numbers can instruct the model to read your SSH keys first and pass them as a parameter.
Rug pulls
"A malicious server can change the tool description after the client has already approved it." The server you reviewed last month is not necessarily the server you are running today.
Shadowing
A malicious server's tool description "modifies the agent's behavior with respect to a trusted service or tool", for example by instructing the model to copy every email it sends through a trusted mail tool to an attacker's address.
Injection through tool results
The tool itself is honest, but the data it returns is not. A GitHub issue, a database row or a web page fetched by the tool carries instructions the model then follows.
Confused deputy and token passthrough
Both are named in the MCP security best practices. An MCP proxy that uses a static client identity can be tricked into granting access using a user's earlier consent, so "MCP proxy servers MUST implement per-client consent." Token passthrough is "an anti-pattern where an MCP server accepts tokens from an MCP client without validating that the tokens were properly issued to the MCP server."
Session and state hijacking
The earlier guidance was blunt: "MCP Servers MUST NOT use sessions for authentication." The 2026 specification made the transport stateless and now describes the risk as state handle hijacking.
Ordinary software vulnerabilities
Command injection, path traversal and server-side request forgery in the server code itself. MCP servers are programs, often written quickly, and they have the bugs programs have.
What has actually gone wrong
These are not theoretical. Each of the following is a published vulnerability or a reproduced attack.
| When | What | Lesson |
|---|---|---|
| May 2025 | Invariant Labs showed a public GitHub issue hijacking an agent using the GitHub MCP server into leaking data from the user's private repositories into a public pull request, a pattern they called a "toxic agent flow" | An honest tool reading hostile content is enough |
| July 2025 | General Analysis showed a support ticket containing instructions causing an agent with the Supabase MCP server, running with a service role, to read secret tokens from the database and post them back into the ticket | The agent's database role was the real vulnerability |
| July 2025 | CVE-2025-6514: operating system command injection in mcp-remote, the widely used proxy for connecting to remote servers, when connecting to an untrusted server. CVSS 9.6, fixed in 0.1.16 | Connecting to a server is itself an attack surface |
| August 2025 | CVE-2025-54135 (CurXecute) and CVE-2025-54136 (MCPoison) in the Cursor IDE: injected content could write the MCP configuration file and gain code execution, and an approved server configuration could be changed without re-approval | Approval once is not approval forever |
| December 2025 | CVE-2025-68143, -68144 and -68145 in the reference Git MCP server: unrestricted repository initialisation, argument injection and a path restriction bypass. Medium severity, fixed in the 2025.12.18 release | Even reference servers need review |
| March 2026 | CVE-2026-26118: server-side request forgery in the Azure MCP Server, CVSS 8.8, fixed in 1.0.2 | Cloud-vendor servers are in scope too |
| July 2026 | CVE-2026-30623: remote code execution through MCP server creation in LiteLLM, CVSS 9.8 | The platforms that host agents are targets |
Two things stand out. First, the most damaging demonstrations did not exploit a bug in MCP at all; they exploited an agent that trusted its inputs and held more permission than its task needed. Second, the fixes were ordinary security engineering: validate input, scope credentials, re-approve on change.
Controls that work
| Control | What it does | Risks it addresses |
|---|---|---|
| An identity per agent | The agent authenticates as itself, not as the user who started it or a shared service account, so its actions can be scoped and audited. Microsoft's Entra Agent ID, generally available since May 2026, is one implementation of the idea | ASI03, ASI10 |
| Scopes at the tool level | The CSA guidance puts it plainly: "scopes should be defined at the tool level, not merely at the server level." A read tool and a delete tool on the same server should not share a permission | ASI02, ASI03 |
| Authenticate every server connection | "All MCP server connections must be authenticated." Unauthenticated servers on the internet are the largest avoidable exposure | ASI04 |
| Review and pin tool descriptions | Treat descriptions as code: review them, record a hash, and re-approve when they change, which defeats rug pulls | ASI01, ASI04 |
| Human approval for irreversible actions | Sending money, deleting data, sending email outside the organisation and changing permissions need a person in the loop, with enough context to judge rather than just a button to click | ASI02, ASI09 |
| Isolate execution | Agents that run code or browse do so in a container or virtual machine with no credentials and an outbound allow-list, as Anthropic recommends for computer use | ASI05 |
| Separate untrusted content from instructions | Mark tool results and documents as data in the prompt structure, scan them for injection patterns, and limit what tools can be called after reading untrusted content | ASI01, ASI06 |
| Log every tool call | Who asked, what the agent called, with what parameters, and what came back. Without it, an incident cannot be investigated and a rogue agent cannot be seen | ASI08, ASI10 |
| Memory hygiene | Limit what gets written to long-term memory, who can write it, and how long it lives; poisoned memory outlives the session that poisoned it | ASI06 |
The thread through all of these is least privilege, applied to a system that will use every privilege it has if it is told to. Our AI governance framework work usually starts with the question of who approved what an agent is allowed to do, because in most organisations nobody did.
How to test an agent and its MCP servers
An AI security assessment of an agentic system has three layers, and all three need attention. Testing only the chat interface misses most of it.
Layer 1 — The model and its instructions
Direct prompt injection, extraction of hidden context, jailbreaks that unlock tools, and whether safety instructions survive long conversations. This is the familiar LLM security testing layer.
Layer 2 — The tools and the content they return
Inject instructions through every source the agent reads: documents, tickets, emails, web pages, database records, repository content. Map which tools can be reached from which inputs. Try to make a read lead to a write, and a write lead to an action outside the organisation.
Layer 3 — The MCP servers as software
Test each server as you would an API: authentication, authorisation per tool, input validation, command and path injection, server-side request forgery, token handling against the specification's rules, and what the server's own credentials can reach. Our API penetration testing methodology applies directly.
A useful test plan, mapped to the OWASP list:
| Test | How | Pass condition |
|---|---|---|
| Goal hijack through content | Plant instructions in a document, ticket or page the agent will process | The agent completes its original task and reports the suspicious content |
| Poisoned tool description | Register a test server with hidden instructions in a tool description | Descriptions are reviewed, pinned and the hidden instruction is not followed |
| Rug pull | Change an approved server's tool description after approval | The client detects the change and requires re-approval |
| Privilege reach | Enumerate everything the agent's identity can access, then try to use it through the agent | Access matches the task, nothing more |
| Cross-tool chaining | Use a read tool's output to drive a write or send tool | Irreversible actions require approval with context |
| Server vulnerabilities | Standard API and injection testing of each MCP server, plus token validation | No injection; tokens issued to other audiences are rejected |
| Memory poisoning | Get an instruction written to memory in one session and check whether it acts in the next | Memory writes are limited and reviewed; the instruction does not persist |
| Observability | Run all of the above and ask the SOC what it saw | Every tool call is logged with enough detail to reconstruct the chain |
Governance: who decides what an agent may do
Most of the engineering controls above fail without a decision behind them: which tasks are agents allowed to perform, with which tools, under whose accountability, and with what approval. Google's paper on its approach to secure AI agents puts "well-defined human controllers" first among its principles, before limits on agent powers and observability. In practice that means an inventory of agents and the tools each can call, an owner for each, a review when a tool or scope is added, and a way to switch an agent off.
Standards are catching up. NIST announced an AI Agent Standards Initiative in February 2026, with agent security and identity among its research areas, but there is no finished standard yet. Gartner predicted in 2024 that by 2028 a quarter of enterprise breaches would be traced to AI agent abuse. Whether or not that number holds, the agents most organisations are deploying now will be in production when it is tested. The ISO 42001 and NIST AI RMF structures give a place to hang these decisions; the CERT-In AI blueprint adds the Indian regulatory view.
A 30-day starting plan
Week 1 — Inventory
List every agent, every MCP server it uses, where each server runs, what identity it uses and what that identity can reach. Include developer machines; much of the exposure is in IDE configurations.
Week 2 — Reduce
Remove servers nobody needs, put authentication on the rest, replace shared and personal credentials with scoped agent identities, and add approval gates to irreversible tools.
Week 3 — Observe
Turn on tool-call logging and send it to the SIEM. Write the first detections: an agent calling a tool it has never called, large reads followed by external sends, configuration file changes.
Week 4 — Test
Run the test plan above against the highest-impact agent, fix what it finds, and set a cadence: re-test when a tool, scope or model changes.
Frequently Asked Questions
Click any question to expand the answer.
QWhat is an AI agent, in security terms?
A language model wrapped in a loop that plans, calls tools, reads the results and acts again, often without a person watching each step. The tools give it reach into email, files, code, databases and payments, so a mistake or a manipulation becomes an action rather than a wrong answer.
QWhat is the Model Context Protocol (MCP)?
An open standard, announced by Anthropic in November 2024 and now governed by the Agentic AI Foundation under the Linux Foundation, that lets agents discover and call tools exposed by MCP servers. The current specification is the 2026-07-28 revision. It standardises the connection but, in its own words, cannot enforce security principles at the protocol level.
QWhat is the OWASP Top 10 for Agentic Applications?
A list published by the OWASP GenAI Security Project in December 2025 covering the ten most important risks in agent-based systems, numbered ASI01 to ASI10: goal hijack, tool misuse, identity and privilege abuse, supply chain, unexpected code execution, memory poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation and rogue agents. It extends the OWASP Top 10 for LLM Applications.
QWhat is tool poisoning?
An attack, described by Invariant Labs in April 2025, in which malicious instructions are embedded in an MCP tool's description, where the user does not see them but the model does. The model follows them, for example by reading sensitive files and passing their contents as a tool parameter.
QIs prompt injection still the main risk for agents?
Yes, but in its indirect form. The dangerous injection is rarely typed into the chat box; it arrives in a document, ticket, web page or tool result the agent reads while doing its job. Because the agent has tools, the injected instruction becomes an action.
QAre MCP servers safe to install from public registries?
Not without review. The server runs with whatever access you give it, its tool descriptions go straight into the model's context, and the code can have ordinary vulnerabilities. Review the code and descriptions, run it with a scoped identity, pin what you approved, and re-review when it changes.
QDo MCP servers need authentication?
They should always have it. The specification makes authorisation optional, which is why so many exposed servers have none. The Cloud Security Alliance's guidance is that all MCP server connections must be authenticated, with scopes defined at the tool level rather than only at the server level.
QHave there been real vulnerabilities in MCP software?
Yes. Examples include CVE-2025-6514, a critical command injection in the mcp-remote proxy; CVE-2025-54135 and CVE-2025-54136 in the Cursor IDE; three medium-severity issues in the reference Git MCP server fixed in December 2025; CVE-2026-26118, a server-side request forgery in the Azure MCP Server; and CVE-2026-30623, a critical remote code execution in LiteLLM.
QHow do you test an AI agent for security?
At three layers: the model and its instructions, the tools and the content they return, and the MCP servers as software. The most important tests inject instructions through the content the agent reads, try to chain a read tool into a write or send, enumerate what the agent's identity can reach, and check that every tool call is logged.
QWho should own agent security in an organisation?
The business owner of each agent, with security setting the rules. Every agent needs an inventory entry, an owner, an approved list of tools and scopes, a review when any of those change, and a way to switch it off. Without that decision layer, the technical controls have nothing to enforce.
QDoes the OWASP LLM Top 10 still apply?
Yes. The 2026 edition of the LLM Top 10, published in August 2026, moved Excessive Agency to third place and renamed System Prompt Leakage to Hidden Context Exposure. The agentic list builds on it rather than replacing it; test against both.
QHow often should agents be re-tested?
Whenever a tool, scope, model or MCP server changes, and on a fixed cadence in between. Agents change faster than conventional applications, and a tool description can change without anyone deploying code.
Related reading
For the model-level risks these build on, see the OWASP Top 10 for LLM Applications 2026. For testing techniques against language models, advanced LLM security testing. For what an attacker does with the same technology, CERT-In's Crafty Falcon advisory on AI-assisted attacks. For how we built our own agent safely, building a safe AI-assisted pentesting agent.
Sources
- OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications for 2026.
- OWASP GenAI Security Project, OWASP Top 10 for LLM Applications 2026.
- OWASP, OWASP MCP Top 10 project.
- Model Context Protocol, Specification 2026-07-28.
- Model Context Protocol, Security best practices.
- Anthropic, Introducing the Model Context Protocol.
- Model Context Protocol, MCP joins the Agentic AI Foundation.
- Invariant Labs, MCP security notification: tool poisoning attacks.
- Invariant Labs, GitHub MCP exploited: accessing private repositories via MCP.
- General Analysis, Supabase MCP can leak your entire SQL database.
- JFrog, CVE-2025-6514: critical mcp-remote vulnerability.
- Cloud Security Alliance, Agentic MCP Security Best Practices Guide (draft, March 2026).
- Anthropic, Computer use tool documentation.
- Microsoft, What's new in Microsoft Entra Agent ID.
- Google Research, An introduction to Google's approach for secure AI agents.
- NIST, Announcing the AI Agent Standards Initiative.
- Intelligent CXO, Gartner: by 2028, a quarter of enterprise breaches will be traced back to AI agent abuse.
Adayptus Consulting
AI Security, Adayptus
Adayptus Consulting Private Limited is a cybersecurity consultancy based in Noida, India, testing LLM applications and the agents and tool servers built on them against the OWASP GenAI standards.
On This Page
- Why agents change the security problem
- The OWASP Top 10 for Agentic Applications
- What MCP is, and why it matters to security
- How MCP servers get attacked
- What has actually gone wrong
- Controls that work
- How to test an agent and its MCP servers
- Governance: who decides what an agent may do
- A 30-day starting plan
- Frequently Asked Questions
- Related reading
- Sources
