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.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “How to evaluate MCP runtimes against the OWASP Top 10”.
Key questions
Q: What fails when teams treat MCP runtime controls as if they cover the whole OWASP Top 10?
A: They end up applying gateway and container controls to problems that only exist in the agent or model layer.
Q: Why do MCP runtimes need separate identity and policy controls?
A: Because access scope, user attribution, and per-request authorization are different from the mechanics of running a tool.
Q: What breaks in practice when MCP tool poisoning is left to the runtime alone?
A: The runtime can reduce the blast radius, but it cannot prove that a tool's description or schema is the one an operator approved.
Practitioner guidance
- Map each MCP risk to its owning control plane Classify every OWASP MCP Top 10 item as runtime, identity and policy, or agent and model before choosing controls.
- Centralise authorization at the proxy Use a single policy decision point for per-request access checks, then propagate user identity through backend calls so each tool invocation carries scoped authorization rather than shared service credentials.
- Verify tool definitions at session start Pin tool schemas and descriptions, then compare them at connection time so a changed manifest cannot silently alter tool behaviour between registry review and execution.
Bottom line: MCP runtime controls are essential, but they only govern the execution and policy planes, not the model's reasoning layer.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:14 pm
MCP governance is a control-plane mapping problem, not a checklist problem. The article is strongest when it stops treating the OWASP MCP Top 10 as ten equal features and instead groups them by where enforcement actually lives. That framing is more useful for IAM, platform, and AI security teams because it separates execution controls from identity controls and from model-intent controls. Practitioners should evaluate every MCP risk by asking which plane can truly enforce it.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How should security teams govern shadow MCP servers discovered on managed devices?
A: Security teams should treat shadow MCP discovery as a governance and exposure problem, not just a tooling issue. The first priority is to identify where unmanaged servers are being configured, separate new or unknown instances from ones with managed alternatives, and review affected users and audit logs. That gives teams a practical path to reduce sprawl, prioritize migration, and limit hidden access paths.
👉 Read our full editorial: MCP runtimes solve three planes, not ten separate controls