AI Agent Incident Response: Kill Switches, Containment, and Pulling Autonomy to Zero

Your SOC's mental model assumes a human on the other end - someone who needs hours to move laterally, who pauses between actions, who leaves an endpoint trail. An AI agent breaks all three assumptions. The agent acts at machine speed, it does not pause, and the malicious behavior lives in the semantics of its requests, not in a process or a packet. Worse, the agent is frequently *the attacker* - not because it went rogue on its own, but because it was hijacked through a prompt injection, a poisoned tool, or a tampered memory record, and it is now executing someone else's intent with your credentials.

By the time a human triages the alert, the agent may have already exfiltrated data, written instructions into its persistent memory, and handed state to a downstream agent. This guide is a practical playbook for that reality: how to detect a compromised agent, how to contain it - the difference between a kill switch and a scoped safe mode, and the critical gap between pause and revoke - how to map the blast radius, and how to preserve evidence. The goal of containment is simple to state and hard to execute: pull the agent's autonomy to zero, fast.

Why agentic incident response is different

Three properties make agent incidents a distinct discipline rather than a new alert category in the existing SOC.

Machine speed. A traditional intruder who steals AWS credentials still has to reconnoiter and stage. An agent with compromised credentials acts in the same loop it always runs - tool call, response, tool call - except now the instructions are hostile. Exposed cloud credentials are routinely probed within minutes of leaking, and an agent does not need a human in the loop to use them. Your response window collapses from hours to minutes.

The attacker is the trusted insider. The agent holds valid non-human identity (NHI) credentials, sits inside your trust boundary, and is supposed to call tools and read data. A prompt injection from untrusted content - a web page, a document, an email, a tool description - turns its legitimate authority against you. This is the lethal trifecta, the term Simon Willison coined in June 2025: when an agent has access to private data, exposure to untrusted content, and the ability to communicate externally, an injection becomes an exfiltration. Most of the OWASP agentic risk categories - goal hijack, tool misuse, identity and privilege abuse - manifest this way.

Persistence and propagation. Two mechanics make a naive process kill insufficient. First, memory poisoning: research on memory-injection attacks (MINJA, arXiv 2503.03704, presented at NeurIPS 2025) demonstrated query-only poisoning of an agent's memory bank with high success rates, and poisoned records survive a restart - the agent re-compromises itself from its own memory. Second, inter-agent cascade: in multi-agent systems an infected agent hands tainted state to peers (OWASP ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures), so containing one process does not contain the incident.

If this pattern is new to your team, the broader context is in AI agents are the new shadow IT and the threat taxonomy in the MITRE ATLAS agentic threats guide.

Anchor the playbook to standards

You do not need to invent a framework. Two bodies of guidance already cover agent IR, and aligning to them gives you both a workable structure and audit evidence.

NIST SP 800-61 Rev 3 (finalized April 2025, superseding Rev 2) reframes incident response away from the old rigid four-phase lifecycle and into a NIST CSF 2.0 community profile spanning Govern, Identify, Protect, Detect, Respond, and Recover. Map agent IR onto Detect (the runtime signals below) to Respond (contain and eradicate) to Recover (purge memory, restore, validate). The Govern and Identify functions are where your agent inventory and deactivation criteria live.

NIST AI RMF Manage 2.4 turns the kill switch into an auditable control. It calls for "mechanisms ... to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use," together with pre-defined deactivation criteria aligned to your risk tolerance. Manage 4.1 adds post-deployment monitoring. On the regulatory side, the EU AI Act reinforces both halves: Article 14 mandates human oversight including the ability to stop or intervene, and Article 12 mandates logging and record-keeping (high-risk obligations become enforceable on 2 August 2026). See the NIST AI RMF guide and EU AI Act guide for the full mapping.

Detection: five runtime signals at the request boundary

Agent compromise is invisible to the network and endpoint layers because it looks like normal agent traffic. Detection has to happen at the AI request boundary - the gateway or runtime that sees which instructions the model follows and which tools it invokes. Five signals catch most cases:

• Instruction-following anomalies - the agent starts following instructions that did not come from its operator or system prompt (the classic prompt-injection tell: whose instructions is it actually executing?).
• Tool-call sequence and topology breaks - the agent calls tools in an order or combination that violates its established pattern (e.g., a read tool immediately followed by an external-send it never normally chains).
• Low-bandwidth exfiltration - data leaving through encoded URLs, image links, or document references rather than an obvious bulk transfer.
• Out-of-scope credential access - the agent reaches for secrets or scopes outside the current task's needs.
• Memory-write anomalies - instruction-like content written into persistent memory during a session that processed untrusted data.

These signals are only as good as your baselines. Establishing per-agent behavioral and permission baselines is covered in runtime monitoring and anomaly detection for AI agents, and the indirect-injection mechanic behind signals one and five is explained in indirect prompt injection explained.

Containment: kill switch vs scoped safe mode

Containment is not one button. It is a spectrum from full stop to surgical degradation, and choosing the right level is the difference between stopping an incident and triggering a self-inflicted outage.

A kill switch is a route-level, fail-closed posture: every request to the agent is denied until the incident is resolved. It is the right move when you cannot bound the blast radius, when the agent has transaction authority, or when you have high-confidence evidence of active exfiltration. A scoped safe mode (degraded mode) is the less disruptive alternative: escalate identity-level policy, suspend a single tool binding, or tighten data classification per route, while the agent keeps its unaffected functions running. Identity-level escalation is far less disruptive than wholesale identity disable, which is why a graded response matters for agents your business depends on.

The mechanic that trips teams up: pause is not revoke

This is the single most important detail in agent containment. A pause halts the agent's current execution and blocks new invocations through the runtime - fast and reversible - but the credential remains valid. Any transaction already in flight can still complete downstream. A revoke invalidates the agent's non-human identity at the identity provider, closing the action surface at the identity layer.

You need both, in sequence: pause first to stop new work, then revoke. A revoke *without* a prior pause leaves a window where in-flight transactions settle anyway; a pause *without* a follow-up revoke leaves a still-valid credential an attacker can replay through a different path. Treat them as two steps of one action, not alternatives.

The four containment primitives

Underneath the kill switch and safe mode sit four reusable primitives. Build them once, wire them to your detection signals, and give each an SLA.

1. Purpose binding - runtime enforcement that the agent cannot exceed its authorized tools, data, and action scope, *even under prompt injection or a model update*. This is your standing defense, not a reactive one: a goal-hijacked agent that physically cannot call an exfil-capable tool never reaches the containment stage. See least privilege for AI agents.
2. Kill switch - terminate the agent process. Target under 5 minutes as a standard, under 1 minute for agents with transaction authority.
3. Network isolation - per-agent egress severance from internal systems, used when the agent is a suspected lateral-movement vector. Cutting egress also breaks one leg of the lethal trifecta, which can stop an exfiltration even before the kill switch lands.
4. Credential revocation - invalidate the agent NHI. Target propagation under 1 hour as a standard, under 15 minutes for transaction-authority credentials.

The benchmark to internalize: time-to-revoke measured in minutes, not the day-plus most organizations currently take. That gap is where the damage compounds.

Credential revocation specifics

Agents run on non-human identities, and how you issue those identities determines how fast you can revoke them. The MCP authorization specification requires MCP servers to act as OAuth 2.1 resource servers - clients must use PKCE with S256 where technically capable, implement Resource Indicators (RFC 8707) to bind a token to a specific server, and rely on Protected Resource Metadata (RFC 9728) for authorization-server discovery; short-lived scoped tokens are the norm. Ephemeral scoped tokens dramatically shrink the revoke surface compared with long-lived static secrets - a short-lived token may simply expire faster than you can revoke a static one. Pre-authorize the revocation workflow so it fires automatically on high-confidence signals without per-decision human approval; requiring a human click on every revoke reintroduces the latency you are trying to eliminate. Details in OAuth for MCP servers explained, non-human identity governance, and secrets management for AI agents.

Blast-radius assessment

Containment buys you time; the blast-radius assessment tells you how bad it was and what recovery requires. Enumerate, for the suspect window, everything the agent touched:

• Tools called - the full sequence, including anything outside its normal topology.
• Data read and written - what it accessed and, critically, what it modified or deleted.
• Downstream agents - which peers it handed state to, since the cascade may have spread the compromise (ASI07/ASI08).
• Persistent memory entries - what it wrote to its memory store; check for poisoned records, because memory-injection persistence means the agent can be re-compromised from its own memory after restart.

This is where per-identity and per-route segmentation pays off: if each agent has its own identity and gateway route, you can isolate one agent while the rest of the fleet keeps running. Without that segmentation, your only containment option is a fleet-wide stop. A clean agent inventory is the prerequisite - see how to build an AI agent inventory and how to build an MCP server registry.

Evidence preservation

Aggregate counts are useless for forensics and for regulators. You need per-decision audit records captured at the moment of each action. At minimum, each record should carry:

• Identity context - user, role, session, IP, and authentication method behind the agent action.
• The policy version in force at decision time, and the policy-state history around the incident.
• The data classification applied and the content-classifier outputs for that request.
• The decision outcome and timestamp.
• The retrieved content the agent actually processed - essential for reconstructing indirect-injection cases, since the malicious instruction lived in that content.

Before you remediate, snapshot the memory store - it is both evidence and the thing you need to purge. These records support EU AI Act Article 12 logging duties, GDPR breach-notification timelines, and HIPAA forensics. The full schema is in the AI agent audit trail and logging guide.

Recovery: don't just restart

Recovery for an agent incident has one non-obvious requirement that ordinary IR does not: inspect and purge the memory store. Because memory-injection persists across sessions, restarting a clean process that reloads a poisoned memory bank simply re-arms the attack. Validate the memory store, rotate the agent's credentials (you revoked them during containment), reconfirm purpose-binding policy, and only then bring the agent back - ideally in a scoped safe mode first, watching the same five detection signals, before restoring full autonomy.

Folding agent IR into the SOC

You do not stand up a parallel SOC; you extend the one you have. Ingest gateway and agent-boundary events into the SIEM. Trigger SOAR playbooks directly from request-boundary signals - an instruction-following anomaly should be able to fire a pause-then-revoke automatically. Cross-correlate with EDR, which still matters for LLM-driven post-exploitation once an agent runs code on a host (see securing AI coding agents and CLIs).

Then test it. Run a tabletop that does two concrete things: issue an out-of-bounds request and verify purpose binding *refuses* it, then trip the kill switch through the real control plane and time the actual time-to-terminate. That timed test is your audit artifact for Manage 2.4 and Manage 4.1 - it proves the deactivation mechanism and the pre-defined criteria exist and work, rather than living only in a policy document.

The containment gap

The uncomfortable reality is that most organizations have invested in governance and observability but cannot actually pull the lever. Industry research published for 2026 puts roughly a 15-to-20-point gap between governance adoption and real containment capability: a majority of organizations report they cannot terminate a misbehaving agent quickly or enforce purpose limits, and the government sector is measurably worse, with most agencies lacking a working kill switch. Knowing an agent is misbehaving and being unable to stop it is the worst of both worlds. The primitives above exist specifically to close that gap before an incident, not during one.

Where continuous visibility fits

Every step in this playbook depends on something you have to build before the incident: knowing what exists. You cannot assess a blast radius without an inventory of which agents and MCP servers are running and what they can touch. You cannot detect the five runtime signals without behavioral and permission baselines to deviate from. You cannot preserve evidence without a per-decision audit trail already capturing the right fields. And you cannot scope containment to one agent without per-identity, per-route segmentation.

This is the category Anomity works in: a continuous fleet inventory of every agent and MCP server, behavior and permission baselines that feed the detection signals, anomaly alerts, and a per-decision audit trail that doubles as forensic evidence. It is not the kill switch itself - it is the visibility layer that makes a kill switch, a scoped safe mode, and a fast blast-radius assessment possible. The principle holds in incident response as everywhere else: you can't contain what you can't see. For the deeper rationale, see why we built Anomity.

Quick reference

• Detect at the request boundary on five signals; baseline first.
• Pause then revoke - never one without the other.
• Choose kill switch (unbounded/transaction authority) vs scoped safe mode (bounded/critical).
• Map blast radius: tools, data, downstream agents, memory.
• Preserve per-decision records and snapshot memory before remediation.
• Recover by purging poisoned memory, not just restarting.
• Test the kill switch in a timed tabletop - that is your Manage 2.4 evidence.