Notifications
Clear all
Topic starter
19/08/2026 3:32 pm
TL;DR: The OWASP MCP Top 10 maps to three control planes, not ten isolated features: runtime and network, identity and policy, and the agent/model layer, with about eight items sitting in the runtime domain and two requiring controls above it, according to Stacklok. That split matters because MCP governance fails when teams treat gateway controls as a substitute for agent-layer intent and context controls.
NHIMG editorial — based on content published by Stacklok: How to evaluate MCP runtimes against the OWASP Top 10
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: How should security teams evaluate MCP runtimes against the OWASP Top 10?
A: They should evaluate runtimes by control plane, not by checklist coverage.
Q: Why do MCP runtimes not solve every OWASP MCP risk?
A: Because some risks live in the model's reasoning and context window, not in the gateway.
Q: What breaks when MCP security is treated as a single control layer?
A: Teams overestimate runtime coverage and miss the risks that sit above it.
Practitioner guidance
- Map every MCP control to its owning plane Separate runtime, identity, and agent-layer controls before buying or deploying any MCP runtime.
- Replace shared credentials with user-scoped token exchange Use short-lived per-user tokens for backend calls and remove long-lived shared service accounts wherever possible.
- Require tool-definition trust at session start Ask vendors how they pin tool schemas, verify manifests, and detect description drift when a client connects.
What's in the full article
Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:
- How ToolHive maps individual OWASP MCP items to runtime, identity, and agent-layer controls in practice
- The specific container, registry, and policy mechanisms used to constrain malicious or misconfigured MCP servers
- Stacklok's detailed guidance on MCP03 tool poisoning, including signed-manifest and schema-pinning questions
- The exact audit, telemetry, and token-handling patterns used to reduce secret exposure in real deployments
👉 Read Stacklok's analysis of how MCP runtimes map to the OWASP Top 10 →
MCP runtimes and the OWASP Top 10: what can they actually cover?
Explore further
19/08/2026 4:14 pm
MCP governance is really a three-plane identity problem, not a ten-control checklist. The runtime plane, identity plane, and agent plane each absorb different risks, and only the first two are fully reachable from an MCP gateway. That means teams that buy for "MCP security" without mapping the plane of control will overestimate coverage and underfund the missing layer. The practical conclusion is that architecture must start with control-plane ownership, not feature counting.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of Secrets Sprawl 2026.
- Hardcoded secrets and configuration-file exposure remain persistent entry points, and 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone.
A question worth separating out:
Q: Who should own governance for shadow MCP servers and tool trust?
A: Platform security, identity governance, and application owners all have a role, but no single team can own it alone. Discovery belongs with exposure management, authorization belongs with identity, and tool-definition trust belongs with the MCP runtime or agent framework.
👉 Read our full editorial: MCP runtimes solve three planes, not ten separate controls
