Quick answerKeep the agent running during an active security incident only if it can be isolated from every system that is part of the incident's blast radius, verified explicitly rather than assumed, and only for the subset of functions that do not touch customer authentication, account modification, or anything the incident response team has flagged as potentially compromised. Have a pre-defined degraded operating mode ready before an incident ever happens, not designed live under pressure, that strips the agent down to read-only, low-risk functions while the isolation is being verified, and give the incident commander unilateral authority to pull the agent fully offline the moment isolation cannot be confirmed with confidence.
This is a harder question than whether to shut the agent down
An emergency kill-switch runbook covers cleanly pulling a misbehaving agent fully offline, a binary decision with a clear trigger. This is a subtler problem: your company has an active security incident somewhere in its systems, and the agent itself is not the cause, but it is also not obviously safe to keep running, since it may have connections into systems that are part of the incident's blast radius. Shutting everything down is the safe default, but it is also often the wrong call if the agent is genuinely isolated and customers still need service; the actual governance question is how to tell the difference under time pressure, not just to default to the safest-looking option.
Verify isolation explicitly, never assume it
An incident response team under pressure will often assume a given system is unaffected because it has 'always been separate,' without actually verifying that assumption against the specific incident at hand. Require explicit confirmation, not an assumption, that the agent's data connections, credentials, and downstream systems fall genuinely outside the incident's blast radius before treating it as safe to keep running, similar in spirit to what if the security breach is on your model provider's side rather than your own systems: in both cases, the default has to be to prove safety, not to assume it, since a misbehaving agent is dramatically easier to reason about than one that is compromised without anyone realizing it yet.
Have a degraded operating mode ready before you ever need it
Designing what functions the agent can safely keep performing during an active incident is not a decision to make live, under pressure, while an incident is unfolding. Pre-define a degraded mode: read-only functions, no account modification, no new authentication flows, no autonomous financial actions, that can be flipped on immediately the moment an incident is declared, regardless of which specific system triggered it. This degraded mode is deliberately more conservative than the thresholds used for a routine partial-degradation incident, since a security incident carries a different risk profile than ordinary service degradation, latency or accuracy problems do not carry the same compromise risk that an active breach does.
Give the incident commander unilateral authority to escalate to full shutdown
Whoever is running the security incident response needs explicit, pre-authorized power to pull the agent fully offline the instant isolation confidence drops, without needing to loop in the agent's own product owner or wait for a separate approval chain. An incident that is actively evolving does not wait for cross-team sign-off, and building that authority into the incident commander role ahead of time removes the delay that would otherwise come from figuring out who has permission to make the call under pressure.
Debrief the degraded-mode decision after the incident closes, regardless of outcome
Whether the agent stayed in degraded mode the whole time, escalated to full shutdown, or returned to normal operation partway through, review the decision points afterward specifically for whether isolation was verified as confidently as it should have been at each stage. This is where the earlier assumption-versus-verification distinction either gets reinforced as a real practice or quietly erodes back into an assumption the next time pressure is high.
FAQ
Is this the same as the emergency kill-switch decision?
No. The kill-switch runbook covers when and how to pull a misbehaving agent offline. This is about the more nuanced case where the agent itself is not the problem but might be exposed by an incident elsewhere in the company's systems.
Should isolation ever be assumed rather than verified?
No. Always require explicit verification that the agent's connections fall outside the incident's blast radius before treating it as safe to keep running, especially under time pressure when assumptions are most tempting.
Who should have authority to pull the agent offline during an incident?
The incident commander, pre-authorized to act unilaterally the moment isolation confidence drops, without waiting for a separate approval chain from the agent's own product owner.