Notifications
Clear all
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.
NHIMG editorial — based on content published by Cycode: OWASP MCP Top 10: A Guide to Securing Model Context Protocol in 2026
By the numbers:
- Security researchers filed more than 30 CVEs 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.
- Cycode’s 2026 State of Product Security report found that 81 percent of organisations lack full visibility into how AI is used across the SDLC.
Questions worth separating out
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility.
Q: Why do MCP servers create new identity risk for AI-native development?
A: MCP servers create risk because they extend delegated access from the model into repositories, data, and workflow tools.
Q: What breaks when tool descriptions or retrieved context are trusted blindly?
A: Blind trust in context lets attacker-controlled text influence decisions that should have been policy checked.
Practitioner guidance
- Inventory every MCP server and connector Build a continuously updated register of MCP servers, tools, and dependent packages across IDEs, CI runners, and production agents.
- Replace long-lived tokens with scoped, short-lived credentials Eliminate static API keys and persistent PATs where MCP integrations can use delegated, audience-bound, and time-limited authentication.
- Quarantine untrusted context before agent execution Treat retrieved documents, tool descriptions, issue text, and server outputs as untrusted input until they pass policy checks.
What's in the full article
Cycode's full guide covers the operational detail this post intentionally leaves for the source:
- Risk-by-risk mapping across all ten OWASP MCP categories, including the specific CVEs and disclosed attacks tied to each one
- The full defense playbook for SDLC and Agentic Development Lifecycle controls, including where to enforce policy in IDE, CLI, CI/CD, and production
- Cycode's control stack for MCP visibility, including continuous discovery, AI guardrails, and audit telemetry across the software factory
- Implementation context for teams evaluating MCP in real environments, including how to prioritise fixes when multiple servers and tools are already connected
👉 Read Cycode's guide to the OWASP MCP Top 10 and AI tool security →
OWASP MCP Top 10: are your AI tool connections actually governed?
Explore further
18/08/2026 3:39 pm
MCP governance is now an identity problem disguised as an integration problem. The article shows that the most damaging failures in MCP come from token exposure, scope creep, and ungoverned tool permissions. That puts MCP squarely in the same control family as NHI lifecycle management and PAM, because every server connection is effectively a machine identity with reach. Practitioners should govern MCP access as a credentialed runtime relationship, not as a convenience plugin.
A question worth separating out:
Q: Who is accountable when an AI agent takes action through an MCP server?
A: The accountable party is the human or team that authorised the agent's access, but only if the organisation can prove that chain. Without immutable logs that connect the initiating identity to the tool call and final action, accountability becomes weak, and legal or compliance teams lose the evidence they need.
👉 Read our full editorial: OWASP MCP Top 10 defines the new security boundary for AI tools
