Start with the capability causing harm
When an agent performs an unexpected action, “turn off the AI” is too imprecise to be a complete containment instruction. A stopped conversation may leave a scheduled job, a token or a changed record behind. The relevant question is which capability can continue the harm and which owner can restrict it safely.
Containment is an operational decision. The incident lead and system owners weigh ongoing impact, continuity and evidence preservation. This guide organises those decisions; it does not authorise changes to an environment. If a live event is underway, use the organisation’s established incident and emergency channels.
Compare the available boundaries
| Boundary | What it may restrict | What to verify afterwards |
|---|---|---|
| Pause a run or workflow | Further orchestration from that execution path | Retries, scheduled runs and jobs already launched |
| Disable a tool or connector | A specific downstream capability | Other tools reaching the same destination |
| Restrict or revoke delegated access | Operations under the implicated authority | Other grants, sessions and dependent workloads |
| Quarantine a retrieval source | New context from suspect material | Caches, replicas, stored context and persistent memory |
| Isolate an execution environment | Activity from an affected host or runtime | External jobs, connected credentials and operational fallback |
Preserve the record of what you change
Before a change, where compatible with stopping harm, identify the run, deployment, principal and relevant record sources. Capture the current configuration and the observed state through authorised owners. Record who approved the change, when it took effect, its expected consequence and the verification result.
Avoid a silent sequence of prompt edits, permission changes and redeployments. It can leave the investigation unable to determine which configuration handled the original action. When urgent containment takes priority over collection, record that decision and what evidence was not preserved. Missing evidence is a limitation to explain, not a reason to invent a complete timeline.
Do not confuse a quiet agent with a closed incident
After restriction, inspect the destination system. Confirm whether the operation completed, partially applied or remains queued. Identify business owners for correction or reversal. A customer communication, fund movement or external disclosure may not be reversible through a technical rollback.
Also review how the agent obtained its authority. If several workloads share the same identity, a broad revocation can affect unrelated services; a narrow pause may leave the compromised authority usable elsewhere. The incident scope should record this dependency and the owner’s decision.
Define the restart check before restarting
- The implicated input, source, permission or tool boundary has been addressed.
- Required legitimate actions still work under the intended identity.
- The identified unsafe condition is rejected or constrained in an approved test.
- Queued work and downstream state have been reviewed.
- Evidence gaps and remaining risks are documented.
- The authorised service owner accepts staged restoration and observation.
Connect the decision to the response service
Our AI agent incident response workstream scopes these questions with the customer. Use MCP incident response when servers and connectors form part of the path, and the evidence checklist to prepare collection ownership. For the overall service, see AI incident response from Atlant Security.
The Microsoft AI agent shared-responsibility guidance is useful background for distinguishing responsibilities across components. The decision matrix above is a planning aid; actual containment depends on the deployed system and agreed authority.
