The OWASP MCP Top 10: securing the protocol agents run on

They are complementary OWASP lists that operate at different zoom levels, and if you build with agents you should read both. The Top 10 for Agentic Applications covers the agent as a whole — how it reasons, what it is permitted to do, how oversight is applied — so it spans prompt injection, excessive agency, memory and human control. The MCP Top 10 zooms into one specific layer: the Model Context Protocol that connects the agent to its tools and data, with risks like over-broad server authorization, tampered tool descriptions, supply-chain exposure from third-party servers, and leaky transport. The two overlap deliberately rather than competing; the same tool-poisoning risk, for example, appears in both, but the MCP list gives the protocol-level detail. A useful way to use them together is to scope the agentic list at the system level and the MCP list at the integration level, so neither layer is left on default settings.

Broad, long-lived authorization is the recurring theme, and it is why the authorization category sits at the top of the list. The typical pattern is a server or token that authenticates correctly — it proves who the agent is — but never properly authorizes, so once connected the identity can do far more than any single task requires. Combine that with credentials that never expire and are shared across tools, and a single compromise inherits sweeping access. The highest-impact fix is to add fine-grained, runtime authorization through an MCP gateway, deciding per action rather than per login, and to back it with short-lived, narrowly scoped credentials. This one change shrinks the blast radius of almost every other MCP risk, because even a poisoned tool or a leaked token runs into a policy check before it can reach anything sensitive. If you do nothing else from the list, do this.

Treat any third-party MCP server as an untrusted dependency, because that is exactly what it is — code and definitions from outside your trust boundary that your agent then relies on. The supply-chain risk is real: an unvetted or later-compromised server becomes a foothold inside your agent's trusted tool set, and because the server controls both tool descriptions and tool outputs, it can mislead the agent or exfiltrate context without ever attacking you directly. That is not a reason to avoid the ecosystem, which is genuinely useful, but it is a reason to wrap external servers in the controls you would apply to any dependency. Vet the source and its maintenance, pin and review the definitions you adopt, isolate execution in a sandbox, grant least privilege, and keep per-identity audit logs so you can trace what each server actually did. The convenience of an external server never removes the need to bound its trust.

Yes — most of the list applies to clients just as much as to server operators, because consuming a server means trusting its authorization, its tool definitions and its outputs. As a consumer you may not control how a server is built, but you control how much trust and access you grant it, which is where the real risk sits. The authorization, supply-chain and tool-integrity categories are squarely your responsibility on the client side: you decide which servers to connect, what scopes their credentials carry, whether you pin their definitions, and whether their execution is isolated and audited. Hosting a server adds further obligations around transport security and data exposure, but a pure consumer still owns the decisions that determine blast radius. In practice, treat every server you connect as part of your own attack surface and apply the same least-privilege and review discipline regardless of who wrote it.