Topic starter
18/08/2026 2:59 pm
TL;DR: More than 30 MCP CVEs were filed in early 2026 and Unit 42 measured a 78.3% attack success rate when five MCP servers were connected to one AI agent, showing that protocol-level trust gaps are already exploitable, according to Cycode. The security question has shifted from model safety to governed tool access, scoped context, and auditable runtime controls.
Editorial analysis by NHI Mgmt Group, based on content published by Cycode: “OWASP MCP Top 10: A Guide to Securing Model Context Protocol in 2026”.
By the numbers:
- More than 30 CVEs were filed against Model Context Protocol servers, clients and infrastructure between January and February 2026.
- Palo Alto Networks Unit 42 measured a 78.3 percent attack success rate when five MCP servers were connected to a single AI agent.
- CVE-2025-6514 in mcp-remote carried a CVSS score of 9.6 and affected a package downloaded more than 437,000 times.
Key questions
Q: What breaks when AI tools are exposed through loosely governed MCP servers?
A: Loose governance lets model-driven tools cross from context retrieval into state-changing actions without enough oversight.
Q: Why do shared credentials create so much risk in MCP deployments?
A: Shared credentials erase accountability and make containment harder because every tool call appears to come from the same identity.
Q: How do security teams know whether MCP server governance is working?
A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact.
Practitioner guidance
- Inventory every MCP server Continuously discover MCP servers across repos, developer machines, CI runners and production so no shadow connection sits outside governance.
- Scope credentials to each server Use short-lived, server-specific credentials with audience validation and revoke any token that can be reused across tools or environments.
- Quarantine untrusted context Treat retrieved documents, tool descriptions and tool outputs as untrusted input and block sensitive actions until the context is verified.
Bottom line: MCP changes the security problem from model behaviour to governed tool access, and that shift exposes identity, inventory and telemetry gaps that traditional AppSec scanning will miss.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:39 pm
MCP governance is now an identity problem, not just an application integration problem. The protocol moves tool authority into the AI runtime, which means credential scope, audience validation and offboarding now matter as much as code review. Once a server can act on behalf of a user or workflow, the control question becomes who or what is allowed to speak for that identity at runtime. Practitioners should treat MCP as part of the identity perimeter, not a side channel.
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: Should organisations treat MCP access like third-party software risk or IAM risk?
A: Both. MCP server onboarding is a third-party trust decision, while tool permissions, authorization, and revocation are identity governance decisions. If either side is handled in isolation, the organisation can approve a connector that still gives AI systems too much practical access.
👉 Read our full editorial: OWASP MCP Top 10 defines the new security boundary for AI tools