When an AI agent can call tools, the security question stops being “what might the model say?” and becomes “what can the model do, and who stops it?” The OWASP Gen AI Security Project has answered the first half of that with a taxonomy of agentic threats. This page answers the second half from one specific vantage point: the Model Context Protocol (MCP) layer, where an agent’s tool calls actually cross the wire. For each OWASP risk we give a one-line explanation and the concrete MCP-layer control that mitigates it — and we’re honest about the risks a gateway barely touches, because a checklist that overclaims is worse than no checklist.
This is a reference, not a sales page. The controls below are ones any well-run MCP deployment can adopt; where an MCP gateway like Meandr makes a control easier to apply consistently, we say so plainly, and we flag the many places where the control is your own configuration or architecture, not something a gateway can hand you.
Which OWASP list this maps
OWASP now publishes several overlapping documents in this space, and it’s worth being precise about which one this page uses:
- The OWASP Top 10 for Agentic Applications (ASI01–ASI10), announced at Black Hat Europe 2025 — the ranked “agentic top 10” this page is built around.
- The companion Agentic AI — Threats and Mitigations guide, the deeper threat-and-mitigation catalogue the Top 10 distils.
- The OWASP MCP Top 10 (MCP01:2025–MCP10:2025, currently a beta release) — a separate list scoped specifically to the MCP transport and servers. We reference its items where they line up with a control below.
The naming has churned as these documents matured, so treat OWASP’s own pages as the source of truth and check them for the current wording. IDs and titles below are quoted from the OWASP pages linked at the top of each row as of writing.
The seven controls, in one place
Every mitigation on this page is one of a small set of MCP-layer controls. Naming them once keeps the mapping short:
- Least-privilege tool access — an agent can reach only the servers and tools it needs, not everything the platform can see.
- Argument-level policy — allow, deny, or require-approval decided on the actual arguments of a call, not just the tool name. (In Meandr: priority-ordered rules, first match wins, with a default policy always in force.)
- Human-in-the-loop approval — a sensitive call pauses until a named person decides; deny or timeout means it never runs.
- Audit logging — a durable, tamper-evident record of who called what, with which arguments, and what was decided.
- Rate limiting — a ceiling on call volume that caps the blast radius of a runaway or hijacked agent.
- Auth / credential isolation — upstream credentials live at the boundary, not in the agent, so a compromised agent never holds the secret.
- Not trusting tool output — treating whatever a tool returns as untrusted data, never as instructions or as authority.
None of these is a cure. They are containment: they shrink what a fooled, buggy, or malicious agent can accomplish, and they make sure that whatever it does is on the record. That framing matters for every row below.
ASI01–ASI10, mapped
Read each row as: the OWASP risk in one line, then the MCP-layer control that meaningfully reduces it, then an honest note on the limit of that control.
| OWASP risk | What it is | MCP-layer control | Honest limit |
|---|---|---|---|
| ASI01 — Agent Goal Hijack | Hidden or injected content redirects the agent’s objective, e.g. indirect prompt injection buried in a document or a tool result. | Argument-level policy and least-privilege tool access so a hijacked agent still can’t reach a dangerous tool or argument; approval on sensitive calls; don’t trust tool output. | A gateway cannot stop the model from being fooled. It constrains what a fooled agent can do — this is containment, not a prompt-injection fix. |
| ASI02 — Tool Misuse | The agent uses a legitimate tool in a destructive way — a valid call with harmful arguments. | Argument-level policy to deny destructive arguments and require approval on destructive tools; least-privilege allow-listing; rate limits. | Policy is only as good as the arguments it can see and the rules you write; a tool with coarse, high-level arguments gives policy less to grip. |
| ASI03 — Identity & Privilege Abuse | Leaked or over-scoped credentials let an agent operate far beyond its intended scope. | Credential isolation: the upstream secret (API key, OAuth, mTLS, AWS SigV4) lives at the gateway, not in the agent; per-agent / per-project scoping enforces least privilege. | The gateway holds the credential, but the scope of that credential upstream is still yours to set narrowly. Broad upstream grants defeat isolation. |
| ASI04 — Agentic Supply Chain | Compromised or malicious MCP servers, tools, or dependencies enter the runtime — including unsanctioned “shadow” servers. | A curated, approved-only set of reachable upstreams (counters shadow MCP); name-collision flagging; audit of exactly which server and tool ran. | A gateway controls what is reachable and records what ran; it does not vet a server’s own code or dependencies. Vetting servers stays your responsibility. |
| ASI05 — Unexpected Code Execution | Natural-language paths reach code- or command-execution, opening remote-code-execution avenues. | Least-privilege (don’t expose shell/exec tools at all where possible); argument-level deny/approve on exec-style tools; approval gate. | Sandboxing and hardening the server that actually runs the code is the server operator’s job, not the gateway’s. |
| ASI06 — Memory & Context Poisoning | An attacker seeds the agent’s long-term memory or RAG store, reshaping behaviour in later sessions. | At the boundary: don’t trust tool output, and use argument policy so a poisoned plan still can’t execute a dangerous call; audit records what data flowed through a call. | Largely outside a gateway’s scope — the memory/vector store belongs to the app. A gateway only touches the tool-call boundary, not what the app persists. |
| ASI07 — Insecure Inter-Agent Communication | Spoofed or tampered messages between agents misdirect a multi-agent cluster. | Where agents reach tools through the gateway, per-agent identity/auth and audit help attribute and scope each agent’s actions. | Mostly out of scope: agent-to-agent (A2A) messaging usually doesn’t traverse an MCP tool gateway at all. This is an A2A / transport-security problem first. |
| ASI08 — Cascading Failures | A small error or false signal propagates through automated pipelines with escalating impact. | Rate limiting to cap blast radius across the fleet, project, or agent; approval checkpoints that break an otherwise fully automated chain; audit for detection. | Rate limits and checkpoints slow and bound a cascade; they don’t fix the flawed logic that starts one. |
| ASI09 — Human-Agent Trust Exploitation | Confident, polished explanations mislead a human operator into approving a harmful action. | Approvals that surface the frozen request body and the real tool/server/arguments, so a person decides on facts rather than the agent’s narrative; attribution of who approved; audit. | Approvals cut both ways: too many prompts cause approval fatigue (a risk in its own right). Fire them only on genuinely sensitive calls, or you train people to rubber-stamp. |
| ASI10 — Rogue Agents | A misaligned or compromised agent acts on its own, concealing intent while appearing legitimate. | Default-deny posture, least-privilege allow-list, rate limits, and full audit of every call for detection; policy can cut the agent off. | A gateway sees only what routes through it. An agent with side channels outside the gateway is invisible to it — coverage depends on all traffic actually flowing through the chokepoint. |
How the controls concentrate
Reading down the table, a pattern emerges. A handful of controls do most of the work, and they cluster on the risks a tool-call boundary can genuinely see:
- Argument-level policy is the workhorse — it appears against goal hijack, tool misuse, unexpected code execution, and memory poisoning, because all four ultimately try to turn into a dangerous call, and that is exactly what policy inspects. This is the heart of MCP governance: decisions made on the actual arguments, not just the tool name.
- Credential isolation is the cleanest single answer to identity and privilege abuse (ASI03) — if the agent never holds the upstream secret, a leak of the agent leaks nothing to spend. See MCP security for how a gateway holds and signs upstream auth (including AWS SigV4) on the agent’s behalf.
- Human approval is the right tool precisely where automation shouldn’t have the last word — destructive tools, and the trust-exploitation case (ASI09) where a person is in the loop by design. The discipline is to gate sparingly. See human approvals.
- Audit underwrites every row, because none of the above is trustworthy if you can’t reconstruct what happened. It’s also the only control that helps with the risks a gateway can’t prevent (poisoning, rogue behaviour): if you can’t stop it, you had better be able to see it. See audit.
Where a gateway earns its keep — and where it doesn’t
An MCP gateway is a chokepoint control. It is strongest on the risks that resolve into a tool call it can see and decide on: tool misuse (ASI02), privilege abuse (ASI03), unexpected execution (ASI05), and — for containment and detection — cascading failures (ASI08) and rogue agents (ASI10). It is a partial, boundary-only help on goal hijack (ASI01) and memory poisoning (ASI06), which begin inside the model or the app’s own stores. And it is largely the wrong layer for inter-agent communication (ASI07), which mostly never touches the tool boundary at all.
That honesty is the point of a reference like this. Buying or deploying a gateway does not “cover” the OWASP agentic top 10; it covers the slice of it that lives at the tool-call boundary, and it makes the rest auditable. The remaining slices — vetting the servers you connect (ASI04), sandboxing execution (ASI05), securing your memory store (ASI06), hardening A2A transport (ASI07), and designing agents that don’t drown humans in approvals (ASI09) — are architecture and configuration you own. A gateway that claimed otherwise would be selling the checklist, not helping you pass it.
Using this as a checklist
For each agent you run against MCP tools, walk the ten rows and answer three questions: Which control applies here? Is it actually turned on? And if the risk lands anyway, will the audit trail show it? A row where the answer to all three is yes is a row you’ve contained. A row where the honest answer is “this one is on us, not the gateway” is not a gap to hide — it’s the part of your threat model that needs an owner.
To go deeper on the mechanisms named above: what an MCP gateway is covers the chokepoint model, approval patterns covers the human-in-the-loop control in detail, and what’s in an audit log covers the record every row leans on. And read OWASP’s own Top 10 for Agentic Applications and MCP Top 10 directly — they are the authority here, and this page is only a map onto one layer of the stack.