OWASP MCP Top 10: each risk, and how to check for it

OWASP’s MCP Top 10 is the closest thing the ecosystem has to a shared list of what goes wrong with Model Context Protocol deployments. Here is each risk in plain language, what to check, and an honest map of where an open-source scanner helps and where it does not.

The list is maintained by the OWASP MCP Top 10 project, currently a beta release. The summaries below are our own; read OWASP’s pages for their full descriptions. The coverage column describes what Hecate’s rules and runtime guard do today.

OWASP riskHecateCoverage
MCP01 Token mismanagement and secret exposureMCP006Partial
MCP02 Privilege escalation via scope creepMCP004, MCP002, guardPartial
MCP03 Tool poisoningMCP001, MCP002, MCP003, guardCovered
MCP04 Supply chain attacksMCP007, MCP008Partial
MCP05 Command injection and executionMCP004, guardPartial
MCP06 Prompt injection via contextual payloadsMCP005, guardPartial
MCP07 Insufficient authentication and authorizationMCP008Limited
MCP08 Lack of audit and telemetryguard audit logCovered (with the SDK)
MCP09 Shadow MCP serversMCP007 allowlistPartial
MCP10 Context injection and over-sharingMCP005Limited

MCP01: Token mismanagement and secret exposure

Credentials end up where they should not: in plain text in client configs, in tool definitions, in model context, in logs. Anything that can read them can use them, including an agent with a file tool.

Check: no literal keys, tokens or passwords in .mcp.json, .cursor/mcp.json, .vscode/mcp.json or Claude Desktop’s config; secrets come from the environment; logs do not record raw tool arguments.

Hecate: MCP006 finds known token formats, secret-named values and passwords in URLs in configs and tool definitions, without printing them. The SDK’s audit log stores a hash of call arguments unless you opt in to raw values. It cannot see secrets that only appear at runtime in model context.

MCP02: Privilege escalation via scope creep

Tools and servers gain more capability than the task needs, or quietly gain more over time.

Check: each agent has only the servers it needs; filesystem servers are scoped to a directory; command execution is gated; tool definitions do not widen after approval.

Hecate: MCP004 flags command-execution tools and servers given / or a home directory; MCP002 catches definitions that change after approval; the SDK guard enforces guard.tools.allow and deny and requires approval for command execution.

MCP03: Tool poisoning

Malicious instructions in tool metadata manipulate the model. See the full guide: MCP tool poisoning.

Check: every tool definition reviewed before first use, then pinned, with changes caught.

Hecate: MCP001 (hidden and injected instructions), MCP002 (changes after approval), MCP003 (instructions aimed at other servers’ tools). The SDK guard hides poisoned and changed tools from the model. Detection is pattern-based, so rephrased injections can slip past; pinning and least privilege do not depend on the wording.

MCP04: Software supply chain attacks and dependency tampering

MCP servers are packages and images. A malicious publish or a compromised dependency changes what the agent runs, as with postmark-mcp.

Check: exact versions and image digests; known-malicious and vulnerable versions blocked; an allowlist of approved servers.

Hecate: MCP008 flags unpinned packages and images; MCP007 blocks a small, sourced list of known-bad packages and enforces your allow and deny lists. It does not scan server code or pull a live vulnerability feed; pair it with your dependency scanner.

MCP05: Command injection and execution

Untrusted input reaches a shell or interpreter, through a server’s own bug or a tool that runs commands by design.

Check: which tools can run commands, whether untrusted content can reach them, and whether a human approves each run.

Hecate: MCP004 finds command-execution tools (critical when the agent also reads untrusted content); the SDK guard requires approval before they run. It does not audit a server’s code for injection bugs.

MCP06: Prompt injection via contextual payloads

Instructions arrive in content the agent reads (a web page, an email, an issue) rather than in a tool definition.

Check: no agent combines untrusted content, private data and an outbound channel without approval.

Hecate: MCP005 finds that combination across servers (the lethal trifecta). The SDK guard tracks when a session has read untrusted content and then requires approval for outbound tools, and can limit outbound URLs to an allowlist. It does not inspect or filter the content itself.

MCP07: Insufficient authentication and authorization

Servers that accept unauthenticated requests, weak OAuth flows, tokens with too much scope.

Check: remote servers use HTTPS and real authentication; tokens are scoped to the task.

Hecate: MCP008 flags remote servers over plain HTTP. It does not evaluate OAuth configuration or token scopes.

MCP08: Lack of audit and telemetry

Without a record of which tools were called, with what, and why they were allowed, you cannot investigate an incident.

Check: every tool call and policy decision is logged somewhere reviewable.

Hecate: the SDK guard writes a JSONL audit event for every tool list, call decision and result. Covered for agents that use the SDK; other clients need their own logging.

MCP09: Shadow MCP servers

Servers running outside any review: added by a developer to their editor, left over from an experiment, started with default settings.

Check: an inventory of every MCP client config in use, and an allowlist of approved servers.

Hecate: scanning a client config reports every server in it, and a policy servers.allow list makes anything unapproved a finding (MCP007). It only sees configs you point it at; it does not discover servers on a network.

MCP10: Context injection and over-sharing

Shared context windows or memory leak information across users, sessions or agents.

Check: agents and sessions are isolated; sensitive data is not placed in shared context.

Hecate: MCP005 shows which tools give one agent access to private data alongside untrusted content. Isolation between users and sessions is an architecture question outside a scanner’s view.