Notifications
Clear all
Topic starter
19/08/2026 3:35 pm
TL;DR: MCP risk is concentrated in secrets exposure, over-privilege, weak authentication, audit gaps, and shadow deployments, while some issues like intent flow subversion still need model-layer controls, according to Stacklok’s comparison of ToolHive against the OWASP MCP Top 10. The practical lesson is that MCP governance is an identity problem first, and runtime enforcement only works when scoped credentials, policy decisions, and audit trails are designed together.
NHIMG editorial — based on content published by Stacklok: How Stacklok addresses the OWASP MCP Top 10
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams govern MCP tool access in enterprise environments?
A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools.
Q: Why do MCP servers create more NHI risk than ordinary service integrations?
A: MCP servers often sit in front of multiple tools and data sources, so a single exposed secret can grant broad downstream access.
Q: What breaks when MCP servers are not registered centrally?
A: Unregistered servers create shadow deployment.
Practitioner guidance
- Enforce request-time policy decisions Bind every MCP tool call to a policy decision at the request boundary, not to a broad session grant.
- Remove plaintext secrets from MCP artifacts Keep API keys, tokens, and backend credentials out of configuration files, container images, and logs.
- Build a sanctioned-path registry for MCP servers Require every production MCP server to be registered, versioned, and mapped to an owner before it can be called.
What's in the full article
Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:
- Per-risk capability mapping across all ten OWASP MCP Top 10 items, including where the runtime coverage is partial rather than complete.
- Concrete configuration examples for Cedar policies, tool filtering, token exchange, and audit logging.
- Documentation references for runtime deployment patterns, registry criteria, and container isolation settings.
- Limits of gateway-only enforcement for intent flow subversion and context over-sharing.
👉 Read Stacklok's analysis of OWASP MCP Top 10 coverage and runtime controls →
OWASP MCP Top 10 coverage: what it means for IAM teams?
Explore further
19/08/2026 4:16 pm
MCP governance is really identity governance with a protocol wrapper. The article shows that the highest-value controls are not cosmetic protocol features but authorization, token handling, auditability, and server discovery. That is why NHI teams should treat MCP runtimes as part of the identity plane, not as a separate AI-only problem.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Which controls matter most when evaluating MCP security tools?
A: Prioritise controls that manage secrets, enforce per-request authorization, preserve auditability, and prevent shadow deployment. If a control only hardens the model but does not govern identity, it will miss the main operational risks that MCP introduces into production environments.
👉 Read our full editorial: How Stacklok maps OWASP MCP risks to runtime controls
