The Question Nobody Practices
Every security architecture answers “how do we prevent the breach?” Almost none answer “who pulls the plug when it happens — and how?” For a fleet of autonomous agents, the incident response question is not a drill. It is a design requirement, because there may be no human watching when the incident starts. The threat model in S7.4 priced the damage; the audit layer in S7.7 records it. This article sits between them: what the fleet actually does when something goes wrong, who has authority to act, and how the system stays honest while it is bleeding.
Why autonomous systems need incident response designed in
A single server has a runbook: detect, isolate, contain, recover. A fleet has the same stages but a harder shape, because every stage involves agents making decisions about other agents. Three properties of the Council architecture make incident response a first-class design problem:
- Autonomy. Workers run without a human watching. A breach at 3 a.m. is handled by the system itself, or it is not handled.
- Shared state. The kanban board is the fleet’s memory. A compromised agent writing to the board poisons downstream workers before anyone notices the write was wrong.
- Delegation. Agents spawn agents. A compromised parent can spawn a compromised child under a valid lineage, and the audit log records the lineage but not the malice.
The consequence: incident response cannot be a document that says “call the on-call engineer.” It has to be an automated decision procedure with a defined chain of command — the same chain the Council uses for normal operations, so that emergency authority is not a new, untested mechanism.
The kill chain: budget, counterparty, violation
The Council’s kill semantics (documented in the governance series) define three ways a running agent is stopped:
- Budget. The credit-safety architecture gives every agent a hard cap on spend. When the cap is hit, the gate blocks further calls. Budget kills are automatic and impersonal — the system stops the agent because the meter ran out, not because anyone judged it malicious.
- Counterparty. If an agent’s counterparty — the service it talks to, the key it uses, the channel it publishes through — is revoked, the agent cannot continue even if its own budget is fine. Counterparty kills are how a compromised credential is neutralized without touching every agent that ever used it.
- Violation. The gate’s inspection pipeline flags rule violations: out-of-scope tool calls, taint crossings, forged-signature attempts. Violation kills are the sharpest intervention — the agent is stopped mid-task because what it just did is provably against policy.
These three kill types map onto the three residual risks in the threat model. Budget kills bound runaway behavior. Counterparty kills bound key compromise. Violation kills bound policy breaks. An incident response plan that uses all three can neutralize a compromised agent without a human in the loop — and with a full audit trail of why.
Who has authority: the escalation ladder
Authority in the fleet is not a free-for-all. The escalation ladder mirrors the Council hierarchy: a child agent’s anomaly is handled by its parent; a parent’s anomaly escalates to the Council; a Council-level anomaly escalates to the human operator with a signed, verified account of what happened and what the system recommends. The key design choice is that escalation is triggered by evidence, not by panic. The anomaly detector produces a signed incident summary — what was observed, which kill type fired, what the audit ledger shows — and the recipient can verify the summary the same way every handoff is verified (S7.3).
This matters because in a fleet, the person receiving the escalation is not the first responder. The system is. The human is the court of appeal, not the fire department. Designing the ladder this way means the system can act in seconds while the human decides in minutes — and the human’s decision is grounded in verified evidence rather than a frantic message.
Isolation before recovery
The instinct in an incident is to fix things — restore the service, get the pipeline running again. The discipline in the Council is the reverse: isolate first, recover second. The steps are mechanical:
- Freeze the board. New task consumption stops so that poisoned shared state cannot propagate to workers that have not read it yet.
- Revoke keys. The compromised identity’s signing keys are revoked at the counterparty level, so even a running agent cannot authenticate further actions.
- Snapshot the ledger. The audit log and board history are snapshotted before any cleanup, so the evidence of what happened is preserved even if the investigation changes state.
- Quarantine the lineage. The compromised agent’s parent-child subtree is suspended — not deleted, because deletion destroys evidence, but suspended so no further spawns or handoffs can flow through it.
- Recover from verified state. Work resumes from a board state that has been re-verified, not from the last state that happened to be running.
The order is not cosmetic. Freezing before revoking prevents new writes; revoking before snapshotting would lose the evidence of what the revoked key did; snapshotting before cleanup preserves what cleanup would erase. Incident response is a sequence with dependencies, and the sequence is enforced mechanically by the system, not by a checklist that a panicked operator might skip.
Post-incident: the ledger does not lie
After the incident is contained, the Council runs the post-mortem the same way it runs everything else: on evidence. The audit layer’s immutable log is replayed to answer three questions — what did the compromised agent actually do, which defenses fired correctly, and which assumptions in the threat model turned out to be wrong. The answers update the model. The updated model generates new architectural requirements. That is the loop that turns every incident into a hardening event instead of a scare.
The honest part of this: a post-mortem that finds no model error is a red flag. The threat model in S7.4 is a list of priced assumptions, and an incident is the fleet’s best test of whether those prices were right. If the system survived because the attacker was sloppy, that is luck, not architecture — and the model should say so.
What customers should ask
For a sovereign-infrastructure business (the S6 series), incident response is a sales question hiding as a technical one. The right question is not “how do you prevent breaches?” — the answer to that is always a marketing list. The right question is “when one of your agents is compromised, what happens automatically, what evidence do you produce, and who decides when work resumes?” A fleet that answers with a documented kill chain, an escalation ladder, and an immutable audit log is describing a system that treats incidents as part of the design. A fleet that answers with promises is describing hope. The customer dashboard (S6.7) exposes the observable half of this — status, budget, health — and the audit layer (S7.7) exposes the verifiable half. Together they turn incident response from a claim into a demonstration.
Grounded in wiki concepts credit-safe-architecture, narrow-gate-principle, zero-trust, kill-semantics, entity openfang, and the S7 security series. Design notes on a running system.
