MCP Incident Response: Detection, Containment, and Recovery

When a security incident hits your MCP infrastructure, the speed and quality of your response determines whether the event remains a contained anomaly or escalates into a full-scale data breach. MCP incidents present unique challenges that traditional IT incident response playbooks weren't designed to handle: the compromised entity is an AI agent whose behaviour is influenced by its context rather than by executable code, the attack vector may be a carefully crafted prompt rather than a network exploit, the affected data may span every system the agent has tool access to, and the evidence trail lives in conversation logs and tool invocation records rather than in system logs and network captures. This playbook provides a comprehensive, MCP-specific incident response framework covering the five phases of detection, triage, containment, eradication, and recovery, with detailed procedures, decision trees, and communication templates that your team can activate within minutes of detecting an anomaly. It is based on real incidents we have responded to across enterprise MCP deployments and incorporates the lessons learned from each one.

Phase 1: Detection — Identifying MCP Security Anomalies

Detection in MCP environments requires monitoring at multiple layers simultaneously. At the application layer, watch for anomalous tool invocation patterns: an agent that typically makes three database queries per session suddenly making thirty, a tool being invoked with parameters that don't match the user's stated request, or tool calls occurring after the conversation has ostensibly ended. At the data layer, monitor for unusual access patterns such as bulk data retrieval, access to tables or records outside the agent's normal scope, or queries that return sensitive data types like social security numbers or API keys. At the network layer, watch for unexpected egress connections from MCP servers, traffic volume spikes, or connections to IP addresses not on the egress allowlist. At the model layer, monitor for outputs that suggest the agent's behaviour has been altered by injection: responses that include encoded data, tool calls that the user didn't request, or unusual formatting patterns that might indicate the agent is following injected instructions. Effective detection combines rule-based alerting for known attack patterns with machine learning models that baseline normal behaviour and flag statistical anomalies, ensuring coverage of both known and novel attack techniques.

Phase 2-3: Triage and Containment

Once an anomaly is detected, the triage phase determines its severity and scope. The incident commander should immediately gather the agent's identity and session context, the full tool invocation history for the affected session, the data accessed or modified during the anomalous period, any related alerts from other monitoring systems, and the potential blast radius based on the agent's permissions. Severity classification follows a three-tier model: critical incidents involve confirmed data exfiltration, modification of production systems, or evidence of persistent compromise; high-severity incidents involve successful prompt injection with tool invocation but no confirmed data loss; moderate incidents involve anomalous patterns that haven't resulted in confirmed misuse. Containment procedures scale with severity. For critical incidents, immediately revoke all tokens for the affected agent, isolate the MCP server from the network using the kill-switch, preserve all logs and session recordings for forensic analysis, and notify the legal and compliance teams. For high-severity incidents, suspend the specific agent session while keeping the MCP server operational for other sessions, restrict the agent role to read-only access pending investigation, and begin log analysis. The key principle is to stop the bleeding as fast as possible while preserving evidence for the investigation phase.

Phase 4-5: Eradication, Recovery, and Lessons Learned

Eradication focuses on removing the root cause and ensuring the attacker can no longer access your systems. If the incident originated from a prompt injection, identify the injection vector—user input, poisoned data source, compromised tool output—and deploy specific mitigations such as input filtering rules, data source quarantine, or tool output sanitisation. Rotate all credentials associated with the affected MCP server and any downstream services it connects to. If the incident involved a compromised third-party MCP server, remove it from your infrastructure and assess whether any data it processed has been exfiltrated. Recovery proceeds in stages: first, restore services with enhanced monitoring and restricted permissions; then, gradually relax restrictions as confidence builds that the threat has been eliminated; finally, return to normal operations while maintaining the enhanced monitoring for a cooldown period. The lessons learned phase is where the real value emerges. Conduct a blameless post-incident review within seventy-two hours that documents the full timeline, identifies what worked well in the response, what gaps were exposed, and what specific improvements should be made to detection rules, containment procedures, access controls, and training. Update the playbook with new detection signatures, response procedures, and decision criteria based on what was learned. The organisations that improve fastest after incidents are those that treat every incident as a learning opportunity and systematically feed findings back into their security posture.