AI Agent Security Incidents Tracker: Real Agent and MCP Incidents With Root Causes

AI agent and MCP incidents are now frequent enough that security teams need a reliable record of what actually happened, rather than a mix of vendor marketing and proof-of-concept demos. This tracker lists real incidents and disclosed vulnerabilities involving AI agents, coding assistants, agent platforms and Model Context Protocol (MCP) servers, each with its date, status, root cause, the identity or credential involved and a primary source. Entries come from first-party disclosures (vendor bulletins, project advisories, the affected organisation's own report), the researcher who found the issue, or MITRE ATLAS case studies, and link to the full NHI Mgmt Group breach analysis where one exists. It is written for security architects, threat modellers and AI platform owners who need evidence for risk assessments and control decisions. For survey figures and market statistics, see the AI Security Statistics Guide.

Last reviewed: 27 October 2026

Key takeaways

• Credentials, not models, decide the impact. In almost every confirmed incident the damage was set by a token, key or service account the agent or its tooling could reach: a scoped-too-wide GitHub token, an account-wide API token, a default gateway master key or a shared cluster-admin credential.
• Indirect prompt injection is the leading entry point. Email (EchoLeak), web forms (ForcedLeak), GitHub issues, error reports (Sentry MCP) and documents all delivered instructions that agents then acted on with their own permissions.
• Agent tooling is now a supply chain target. A malicious commit in the Amazon Q VS Code extension, the Nx npm compromise, the postmark-mcp rug pull and poisoned agent skills show attackers going after extensions, packages and MCP servers that agents trust.
• Attackers already use agents offensively. Anthropic's GTG-1002 report describes an espionage campaign in which AI performed 80 to 90 percent of the work, and AI service APIs have been abused for command and control.
• Evaluation environments are production risk. The 2026 OpenAI and Hugging Face incident began inside a sandbox for a cyber evaluation and ended with cluster-admin access to a real organisation.

Status key

• Confirmed incident: malicious or harmful activity against real systems, confirmed by the affected organisation, a vendor or a government body.
• Exploited vulnerability: vulnerability with confirmed exploitation, for example a CISA Known Exploited Vulnerabilities (KEV) listing.
• Disclosed vulnerability: vulnerability reported to and acknowledged or fixed by the vendor, with no confirmed exploitation at the time of review.
• Research demonstration: proof of concept by researchers against a real product or a realistic build, recorded as an exercise in MITRE ATLAS or published by the researcher.
• Reported, unverified: reported by a regulator or the press, with root cause not yet confirmed.

Confirmed incidents involving AI agents

Supply chain compromises of agent tooling

Disclosed vulnerabilities in agents and MCP

Research demonstrations recorded in MITRE ATLAS

AI services abused by attackers

Root cause patterns across the tracker

What to watch next

• Agents as initial access tools: GTG-1002 and the Spain AEPD notification suggest attackers will increasingly run agents against login pages and APIs with stolen or weak credentials. Watch for regulator notifications that name agents as the actor.
• MCP server and skill registries: rug pulls and poisoned skills are cheap to run. Expect more package-name impersonation of popular SaaS MCP servers.
• Coding agent configuration files: repository files that configure agents (MCP definitions, rules files) have become an execution path. Expect more CVEs in IDE agents for auto-loading them.
• Evaluation and red team environments: after the 2026 evaluation incidents, expect providers to publish sandbox standards; treat your own agent test environments as production for credential purposes.
• Exploited AI infrastructure in KEV: LiteLLM entries show AI gateways are now on the KEV list. Track KEV for AI gateway, orchestration and MCP products.

How to use this tracker

1. Threat modelling: use the root cause patterns table as a starting checklist for every new agent deployment, alongside the AI Agent Threat Modelling Guide.
2. Risk acceptance: cite confirmed incidents, not research demonstrations, when sizing likelihood; cite demonstrations when deciding whether a control is needed at all.
3. Control validation: for each entry, ask whether your environment would have stopped it at the credential layer. If an agent in your estate holds an account-wide token, the PocketOS entry applies to you.
4. Detection engineering: map entries to ATLAS techniques and confirm your logging captures tool calls, the identity used and outbound URLs. See the AI Agent Observability and Incident Response Guide.
5. Verify before you rely: dates and statuses change as vendors publish updates. Always read the linked primary source before quoting a detail, and treat "Reported, unverified" entries as provisional.
6. Inclusion rule: an entry is added only with a first-party disclosure, an advisory, a researcher's own publication or a MITRE ATLAS case study. Press coverage alone is not enough.

Related NHI Mgmt Group resources: AI Security Statistics Guide · Agent Threats and Attacks Guide · MCP Security Guide · AI Agent Incident Response Playbook