Notifications
Clear all
Topic starter
10/06/2026 10:55 pm
TL;DR: A consolidated timeline of MCP-related breaches shows recurring failures in authentication, input validation, isolation, and privilege scope, with incidents ranging from command injection to supply-chain compromise across tools and registries, according to Authzed. AI changes the interface, but not the security fundamentals: least privilege, trust boundaries, and lifecycle control still determine blast radius.
NHIMG editorial — based on content published by Authzed: LLMjacking and recurring MCP breach patterns across 2025 and 2026
By the numbers:
- Over 150 million downloads were affected by the MCP STDIO transport design flaw.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: What breaks when MCP tools can reach system commands without strong validation?
A: The control boundary breaks immediately because untrusted input stops being data and becomes execution.
Q: Why do MCP integrations so often become non-human identity risks?
A: Because the integration usually runs on service accounts, API keys, or delegated tokens that are broader than the task requires.
Q: What do security teams get wrong about MCP supply-chain risk?
A: They often focus on the server code and ignore the registry, build pipeline, and metadata layer that deliver it.
Practitioner guidance
- Inventory every MCP-connected identity Map each MCP server, proxy, registry, and inspector to the service account, API key, or token it uses.
- Remove command execution from untrusted input paths Audit all MCP integrations for shell calls, subprocess execution, and command templating.
- Scope credentials to a single tool and tenant Replace shared or broad-scope tokens with short-lived, purpose-built credentials that cannot be reused across registries, clients, or environments.
What's in the full article
Authzed's full article covers the incident-by-incident detail this post intentionally leaves for the source:
- A chronological breach timeline with the specific month, product, and failure pattern for each MCP incident
- Named CVEs, affected platforms, and exposure paths across hosted MCP tools, registries, and proxies
- The recurring breach patterns section that groups the incidents by over-privilege, tool poisoning, and supply-chain exposure
- The article's own FAQ on recurring MCP breach patterns and production-use safeguards
👉 Read Authzed's consolidated timeline of MCP breach patterns and failures →
MCP breach patterns: what IAM teams are missing?
Explore further
12/06/2026 4:39 am
MCP has become an identity surface before it became a security product category. The breach timeline is not really about one protocol flaw, it is about what happens when tool connectivity inherits privilege without lifecycle discipline. Once AI systems can call tools, the question shifts from whether the model is safe to whether the connected identity and authorization model is constrained enough to survive abuse. Practitioners should treat MCP as governed identity infrastructure, not a convenience layer.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
A question worth separating out:
Q: How should organisations govern AI tool access when MCP is involved?
A: They should apply the same governance discipline used for other high-trust non-human identities. That means explicit ownership, per-tool scoping, short-lived credentials, tenant separation, and revocation when the relationship changes. If the tool can reach production data or infrastructure, it should be governed like privileged machine access, not like a convenience integration.
👉 Read our full editorial: Recurring MCP breach patterns show why AI interfaces still need IAM
