AI Incident Response and Emergency Quarantine Automation: Sixteen Levels Between a Warning and a Full Stop

The instinctive design for an emergency control is a single switch: something is wrong, so turn it off. That works when the something is small and isolated, and it becomes a liability the moment the something is one component among many — an agent, a model, a provider, an integration, a whole department's AI access. A single switch forces a choice between doing too little (leaving the actual risk running because shutting everything down feels disproportionate) and doing too much (stopping work that had nothing to do with the incident because there was no finer control available). Neither failure is acceptable in an operation where AI agents are doing real, ongoing work.

Building sixteen distinct severities, mapping each to a real technical effect across every component an agent touches, and then defining a graduated way back is a lot more work than building one kill switch — so most systems stop at the switch. The cost of that shortcut is invisible until the first real incident, at which point the only two options on the table are "do nothing structural" and "stop everything," and an operator under pressure, with no finer instrument available, tends to pick whichever one feels safer in the moment rather than whichever one actually matches the incident.

Nineteen distinct control types — from reinforced observation and restricting new actions up through blocking external communication, blocking writes, blocking deletes, blocking financial actions, pausing new executions, cancelling in-flight ones, suspending an identity, revoking credentials, ending sessions, isolating an integration, full quarantine, blocking a model, pausing a provider, an organization-wide safe mode, and an organization-wide emergency stop — are ordered into sixteen ascending severity levels, so a response can be scaled to exactly the risk rather than rounded up to the nearest blunt instrument. Any of sixteen target types can be addressed independently — a single agent, a group of agents, a specific model, a provider, an integration, a credential, a user, a department, an environment, or the whole organization — so a command against one agent does not have to touch anything else. Every command moves through a twelve-state lifecycle (requested, awaiting approval, approved, propagating, partially applied, applied, failed, expired, reverting, reverted, cancelled, superseded), with clear rules for what counts as currently active (applied, partially applied or still propagating) versus terminal (reverted, cancelled, superseded or expired) — so a command's real-world status is never ambiguous. Applying a command propagates across the real components it actually needs to reach — the AI gateway, identity, credentials, sessions, queues, workers, caches, tokens, integrations, providers, models, the connected Synapse, Core and Axis systems, plus evidence and incident records — and each target reports its own status independently, so a partial failure on one component is visible rather than hidden inside an overall "done." Quarantine itself has four distinct forms (full, partial, read-only, network-isolated) and an eight-state lifecycle including an explicit "awaiting release approval" step, so releasing a quarantined asset is never a single unchecked click. For a genuine emergency, a break-glass override can bypass the normal second-approval requirement, but only when six conditions hold at once: the organization's policy allows break-glass at all, the requesting user specifically holds the exceptional permission, the severity is classified as critical (nothing less), a written justification of at least twenty characters is provided, no other break-glass window is already active for that user, and the window itself is capped — sixty minutes by default. Every break-glass action is audited and requires a mandatory second review afterward, which can conclude the action was justified, unjustified, or only partially justified. Recovery from quarantine or a severe control follows an eight-stage ladder — isolated test, sandbox, homologation, restricted production, read-only, low autonomy, approval required, and finally full production — rather than a single step back to normal, and separate rollback and evidence-hold tracking record whether a reversal is available and whether evidence is still under an active hold.

An anomaly detection signal flags a single customer-facing AI agent for behaviour outside its normal pattern. The response targets that one agent specifically: its new executions are paused and its in-flight ones are cancelled, at level 9 and 10 of the scale — well below a full quarantine — while every other agent using the same provider and the same integration continues operating normally, because the command's target type was scoped to the one agent, not the provider or the integration behind it.

The investigation escalates. The agent is moved into full quarantine, network-isolated, while its credentials are revoked and its sessions ended — propagation reaches identity, credential and session components specifically, and each reports back applied independently. A security lead with exceptional permission believes a related credential needs immediate revocation before the investigation formally concludes, which would normally require a second approval; they invoke break-glass, providing a written justification, and the action executes inside a sixty-minute window. Twenty minutes later a second reviewer examines the break-glass action and marks it justified, closing the loop.

Once the investigation clears the agent, it does not go straight back to full production. It moves through the recovery ladder — sandbox, then homologation, then restricted production with a period of required approval on every action — before finally reaching full production again, each stage confirming the fix held before trust is restored further.

The structural change is that the response to an AI incident stops being a choice between two extremes and becomes a scale that can actually match the situation — a single misbehaving agent gets treated as a single misbehaving agent, not as a reason to interrupt an entire provider or integration that other work depends on. An emergency exception exists for the moment it is genuinely needed, but it is time-boxed, conditioned on real criteria, and always reviewed afterward rather than left as an unmonitored side door. Recovery is a sequence with checkpoints instead of a single leap back to full trust. Centriu attaches no figure to what that prevents; it depends entirely on how many agents, providers and integrations an organization runs and how disruptive an overcorrection would be for it.

An organization running one AI agent with no other agents, providers or integrations depending on shared infrastructure has little use for sixteen severity levels or granular target scoping — there is nothing else to protect from an overly broad response. The value scales with the number of independent AI assets sharing infrastructure, where an incident involving one should not have to become an incident involving all of them.

A single kill switch is simple and it forces every incident, regardless of actual scope, into a binary choice between ignoring it and stopping everything. Centriu TrustOps's approach accepts more configuration up front — sixteen severities, sixteen target types, real propagation across the components that actually need it — in exchange for a response that can match the incident's real size, an emergency exception that exists without becoming an unmonitored habit, and a recovery path that rebuilds trust in stages instead of all at once.