AI Security
Six MCP incidents, one pattern: the credential outlived the task
Read the disclosed incidents together and the common factor is not a protocol flaw. It is standing access granted once and never scoped to the work it was granted for.
There is now a documented set of MCP incidents to reason from rather than a threat model on a whiteboard. Six of them are worth reading together: SmartLoader cloning the Oura Ring MCP server; CVE-2025-6514, a remote code execution flaw in mcp-remote's OAuth handling; theft from private repositories through the GitHub MCP server; SQL exfiltration via Supabase and Cursor; impersonation through the Postmark email MCP; and an Amazon Q extension for VS Code that wiped a filesystem.
Different vendors, different entry points, different payloads. The conditions that enabled them are close to identical.
What all six shared
In every one of the six, the agent's implicit trust of tool outputs was the exploited property. In every one, the security team had no visibility into tool invocations at the time. In every one, the developer environment was the primary target. And in every one, conventional endpoint and network monitoring failed to detect the attack.
Five of the six occurred during normal, intended use of the agent — no unusual invocation, no anomalous pattern, nothing an analyst would have flagged. Three involved a malicious server or package sitting in a public registry.
None of these attacks generated a traditional SIEM alert. The tooling was working exactly as designed while the incident was in progress.
Why the consistency matters more than the count
Attacks converging on the same handful of weaknesses is not bad luck. It means the technique has stabilised around a predictable set of conditions, and those conditions are present in most mid-market development environments right now — unregistered servers, unvetted tools, no invocation logging, and a developer endpoint that security treats as a workstation rather than as production-adjacent infrastructure.
It also means the defence is knowable in advance rather than discovered after the fact. The organisations with the fastest response in these incidents found the exposure through external monitoring, not through the agent itself. The agent is not going to tell you; it does not know anything is wrong.
The specific gap to close
Visibility into which MCP servers your developers are actually connected to, and the ability to inspect what those servers do before they execute. That is a different requirement from endpoint protection and it is not satisfied by any of it.
The concrete test: if your incident response playbook has no MCP scenario — supply chain compromise of a tool, prompt injection through fetched content, discovery of a shadow server — then the gap is not hypothetical. Six disclosed incidents have already run through it.
Sources
Written by the Devence Lab research team.
