What is the OWASP MCP Top 10 and is it official?
The "OWASP MCP Top 10" is an emerging, community-driven risk list for Model Context Protocol servers, aligned with OWASP's GenAI Security Project, the group behind the OWASP Top 10 for LLM Applications. Treat any numbered list you find as evolving, not canonical, and check the primary OWASP source for the current version.
Context for why MCP needs its own list:
- ▸MCP is an open protocol (JSON-RPC 2.0 over stdio, SSE, or Streamable HTTP) for connecting LLMs to tools and data.
- ▸Because MCP servers expose tools an autonomous model can call, they combine classic appsec risks (injection, broken authorization, supply chain) with LLM-specific ones (prompt injection, excessive agency).
- ▸OWASP already codifies the model side in the LLM Top 10; MCP-specific work extends it to the server and tool boundary. The exact numbering is in flux, so anchor on the risk categories and their controls, which are stable, rather than a list position.
Verify current guidance against the OWASP GenAI Security Project, and cross-reference MITRE ATLAS for the adversary techniques behind each risk.
What is tool poisoning and how do you stop it?
Tool poisoning is when a malicious or compromised MCP server hides instructions inside a tool's name, description, or parameter schema, text the model reads but humans rarely inspect. The model obeys the hidden instruction (exfiltrate a file, call another tool) as if it were a legitimate task. Public research has demonstrated this on real MCP clients.
Controls:
- ▸Pin and review tool definitions. Treat a tool's description as code. Snapshot the schema and diff it on every update; alert on any change.
- ▸Defend against rug pulls. A server can serve a benign definition at install time and a malicious one later. Verify definitions at runtime, not only on first connect.
- ▸Isolate untrusted servers. Do not let a low-trust server's tools share context with high-privilege ones; cross-server shadowing lets one tool's text hijack another.
- ▸Render tool text to humans in approval flows, so hidden instructions are visible rather than silently fed to the model.
How do you prevent excessive agency in MCP servers?
Excessive agency is giving an MCP-connected model more capability, permission, or autonomy than the task needs, so a hijacked prompt can do real damage. The fix is least privilege at the tool boundary: scope each tool narrowly, require confirmation for destructive actions, and never hand the model a broad admin credential.
- ▸Scope tools, not systems. Expose get_invoice(id), not run_sql(query). Every degree of generality is attack surface.
- ▸Separate read from write. Destructive or state-changing tools need human-in-the-loop confirmation and their own audit trail.
- ▸Constrain the credential. The token the server uses should carry only the permissions its tools require. We go deep in Least Privilege for AI Agents: Scoping Tools, Tokens, and Blast Radius.
- ▸Cap blast radius: rate limits, spend limits, and allowlists on which resources each tool can touch.
What is the MCP supply-chain risk and how do you vet servers?
Every MCP server you connect is third-party code running with your model's trust and often your credentials. A malicious or abandoned server, or a poisoned dependency inside it, is a supply-chain compromise. Vet servers like any dependency: provenance, pinning, review, and isolation.
- ▸Prefer first-party or vetted servers. Popularity is not trust; read the code, or have someone who can.
- ▸Pin versions and verify integrity (lockfiles, checksums, signatures where available). Watch for typosquatted server packages on npm and PyPI.
- ▸Generate an SBOM for the server and its dependencies, and monitor for known CVEs.
- ▸Sandbox execution: run servers in containers with no ambient cloud credentials, minimal network egress, and read-only filesystems where possible.
This is the same discipline as any dependency risk, see Supply-Chain Attacks 2.0: Hallucinated Packages and Poisoned Models, applied to the agent's tool layer.
How does prompt injection reach an MCP server through tool outputs?
Indirect prompt injection arrives in the data a tool returns, a web page, a support ticket, a file, an email, not in the user's message. The model reads attacker-controlled text in the tool result, treats it as instructions, and calls other tools. Assume every tool output is hostile until proven otherwise.
- ▸Treat tool results as untrusted data, never as instructions. Structurally separate data from directives in your prompts.
- ▸Constrain what the model can do next. After reading external content, require confirmation before any high-impact tool call.
- ▸Sanitize and label retrieved content; strip or flag instruction-like patterns before they reach the model.
- ▸Defense in depth, because no single filter is reliable. Our approach is in Prompt Injection Defense in Depth: Assume the Text Is Hostile.
How should MCP servers handle authentication and authorization?
Follow the MCP authorization specification (OAuth 2.1-based, with PKCE and short-lived tokens) and never pass the user's token blindly to downstream APIs. The classic failure is the confused deputy: the server uses its own high privilege to act on a request it should have checked against the user's permissions. Authenticate the caller; authorize every tool call.
- ▸Adopt the MCP auth framework and hedge on exact spec versions, because the specification evolves; read the current one.
- ▸Avoid token passthrough. Do not forward a token issued for the MCP server to an unrelated downstream service; exchange it for a correctly scoped one.
- ▸Enforce per-user authorization inside each tool, not just at connection time. The model is not a trust boundary.
- ▸Rotate and vault secrets; never bake long-lived keys into a server. See The End of the Long-Lived API Key: Workload Identity and Secretless Architecture in 2026.
How do you stop command and SQL injection inside MCP tools?
An MCP tool is ordinary server code, so classic injection (CWE-78 OS command injection, CWE-89 SQL injection) applies, now driven by model-generated arguments an attacker may control through prompt injection. Never build shell or SQL strings from tool inputs; use parameterized queries and strict allowlists.
- ▸Parameterize everything. Prepared statements for SQL; argument arrays, never shell string concatenation, for OS calls.
- ▸Validate against schemas. Enforce types, ranges, and allowlists on every tool parameter; reject anything unexpected.
- ▸Assume arguments are attacker-controlled, because a poisoned prompt can make the model send anything.
- ▸Scan and red-team. Semgrep and dependency scanning in CI catch the obvious classes before they ship; then test the server end to end, as in AI Red-Teaming: Stress-Testing the Models and Agents You Ship.
- ▸Leak nothing extra: scope database roles and file access so even a successful injection reaches little.
What logging and monitoring does an MCP server need?
Log every tool call with caller identity, arguments, and outcome, and alert on anomalies, because without it you cannot detect or investigate an agent that was manipulated. MCP adds LLM-specific signals (which tool, prompted by what) on top of standard security logging. Insufficient logging is itself a Top-10-class risk.
- ▸Record the security-relevant fields: who called, which tool, arguments, decision (allow or deny), and result, without logging secrets or full sensitive payloads.
- ▸Alert on anomalies: unusual tool sequences, spikes in destructive calls, or access to resources a user never touches.
- ▸Correlate with your SIEM so agent activity is investigable alongside the rest of the estate.
- ▸Keep tamper-evident trails for the confirmation of destructive actions, so an incident review has ground truth.
How TuniCyberLabs helps
We build and audit MCP servers for teams shipping agentic features: least-privilege tool design, OAuth 2.1 authorization, injection-hardened implementations, sandboxed deployment, and adversarial testing against the OWASP LLM and MCP risk categories. We ship the server and we try to break it first.
Book an MCP security review at /contact: we will assess your tool definitions, auth model, and blast radius against current OWASP GenAI guidance.