How should security teams evaluate MCP runtimes against the OWASP Top 10?

Why This Matters for Security Teams

MCP runtimes sit in the trust path between agents, tools, and sensitive data, so evaluating them against the OWASP Top 10 is really a question of where control actually lives. A runtime that looks compliant on paper can still fail if it cannot prove per-request authorisation, isolate sessions, or constrain tool use once an agent starts chaining actions. Current guidance suggests teams should test the runtime, identity layer, and agent layer together rather than treating MCP as a standalone platform risk. OWASP’s OWASP Top 10 for Agentic Applications 2026 is useful here because it frames the problem as emergent behaviour, not just configuration hygiene.

That distinction matters because agents do not behave like static service accounts. They can request new tools, reinterpret prompts, and escalate from one API to another in ways that ordinary IAM reviews miss. NHIMG’s AI Agents: The New Attack Surface report found that 80% of organisations have already seen AI agents act beyond intended scope, which shows why checklist-style vendor claims are often incomplete. In practice, many security teams discover runtime gaps only after an agent has already accessed something it should never have reached.

How It Works in Practice

An effective review starts by mapping each OWASP item to the control plane that can actually enforce it. For MCP runtimes, that usually means asking three questions: what the runtime blocks, what the identity system proves, and what only the agent orchestration layer can decide at execution time. Static role-based access is often too coarse for autonomous workloads, because the access pattern changes with the task. Instead, the runtime should support intent-aware or context-aware authorisation, short-lived credentials, and auditable session boundaries.

Practitioners should test for these behaviours explicitly:

• Per-request authorisation, not just login-time access checks.
• Short-lived tokens or ephemeral secrets that expire after task completion.
• Workload identity for the agent or service, such as cryptographic proof of what the workload is.
• Audit logs that preserve the tool, session, and policy decision for each action.
• Session-level trust in tool definitions, so a changed or injected tool spec does not inherit old permissions.

This is where guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s Top 10 NHI Issues becomes practical: both emphasise that identity is not just a credential, it is an enforceable trust boundary. For implementation, teams should also check whether the runtime can integrate with workload identity standards such as SPIFFE/SPIRE and whether policy decisions can be evaluated at request time using policy-as-code. These controls tend to break down in loosely coupled multi-agent stacks because the agent, tool server, and identity provider often have different trust assumptions.

Common Variations and Edge Cases

Tighter runtime control often increases integration overhead, requiring organisations to balance security assurance against developer friction and latency. That tradeoff becomes sharper when MCP servers are shared across multiple agents or environments, because one overly permissive connector can undermine the whole model. Best practice is evolving here, and there is no universal standard for how much of the OWASP Top 10 should be enforced in the runtime versus the orchestration layer.

Edge cases usually appear in three situations. First, if the runtime only brokers tool calls but does not own identity, then OWASP issues tied to secrets handling and privilege boundaries must be evaluated upstream in the agent platform. Second, if tools are dynamically discovered, the team should treat tool metadata as an input that needs trust validation, not as a harmless description. Third, if the system supports long-running sessions, short TTLs alone are not enough because re-authentication and revocation must also work mid-session. NHIMG’s The State of Secrets in AppSec is a useful reminder that secret sprawl and delayed remediation are still common operational weaknesses. The practical test is simple: can the product prove what was allowed, by whom, for which task, at the exact moment the tool was invoked?

Related resources from NHI Mgmt Group

• What are the core risks identified by the OWASP Agentic Top 10?
• What is MCP in the context of AI security?
• How should security teams govern machine identity credentials in agentic AI environments?
• How should security teams manage permissions for AI agents?