AI agent incident response
It reaches the live database; snapshots and some tables are outside it
every questionOn this page
Minute one: stop, and know precisely what stopping does not do
There are three blunt instruments and they differ in scope and latency rather than in strength. A kill switch can be scoped to one agent, one team or the whole estate; it is checked first in the evaluation order, before the lifecycle state, before permissions, before ceilings and before any policy, so nothing else can let a request past it. Engaging one requires a named actor and a stated reason, and both go into the audit record — which is the only account anyone will ever have of why a fleet stopped. Team targeting is deliberately case-insensitive, because a team name is typed by a human under pressure.
Suspending an agent flips its lifecycle status, and the evaluator refuses that agent on its lifecycle check. The refusal is taken inside the decision step rather than at the door, so the attempt is still recorded against the trace rather than vanishing, and the transition is published as an event so paging and ticketing systems learn about it without polling. Revoking a credential is one write and takes effect on the next authentication attempt: any process still holding the key starts failing.
What none of them does is reach backwards. A request already dispatched to a provider completes. A tool call already executing completes. An effect already committed in a downstream system stays committed. If the agent is in a loop, stopping the loop is the immediate win; if it has already issued the refund, the kill switch is not the control that helps and the reversal path is a separate exercise covered further down.
Two smaller things belong in the first five minutes. Note the identifier: every gateway response carries a trace identifier, including refusals, so whoever reported the incident probably has one. And decide the scope deliberately rather than reflexively — halting an entire estate has its own cost, and the record of why you did it is what you will be discussing afterwards.
kill switch scope: global | team | agent
checked first, before lifecycle, RBAC, ceilings, policy
named actor + reason, audited, event published
-> refuses NEW work; does not recall a dispatched call
suspend agent lifecycle -> suspended
refused on the lifecycle check at the next request
attempt still recorded against the trace
revoke key one write; effective on next authentication
any process still holding the token starts failingMinute ten: what did it actually do, and what can the record answer
Work from the record the enforcement point produced rather than from the agent’s own logs, for the obvious reason. A trace opens before the decision, so it covers the calls that were refused as well as the ones that succeeded, and the refusals are frequently the more informative half — an agent working through tool names it was never granted is a pattern that only exists in the record if refusals were recorded.
The questions a governed trace answers are: which agent, on whose behalf, through which delegation chain, with which effective grants; which model and provider actually served the call, which may not be the one asked for once routing was applied; which tools it called and with which arguments; which policies matched, what each did, and whether each was enforcing or observing; what was redacted, by kind; which human approved what and when; and what it cost. Search over that corpus is a constrained filter rather than a free-form query translated into SQL, and where a natural-language search exists it emits a validated filter object rather than a query.
Be equally clear about what it cannot answer, because an incident is a bad time to discover a boundary. There is no hidden model reasoning in the record, because the gateway never sees it. The model’s answer text is not stored. The prompt survives as a bounded excerpt taken after redaction, which means the search index cannot contain what the redactor removed — good for minimisation, and a limit when you are trying to reconstruct exactly what the model read. And there is one asymmetry worth knowing: an approval record can hold a short excerpt of the model-proposed tool arguments unredacted, which makes approvals the one place payload-adjacent text survives a trace purge.
Then widen from the trace to the estate. Was this agent alone, or is the same grant held by others? The registry answers that from the same rows the gateway enforces against. Was this a policy that was supposed to catch it? The decision events say whether the rule was enforcing or in shadow at the time.
The question the incident review will turn on: was the control engaged
Every incident review reaches the same fork. Either the control was on and did not catch this, which is a design question, or the control was not on, which is a process question, and the two have completely different remediations. A governance layer that cannot tell you which is which has failed at the moment it was most needed.
The mechanism that answers it is that every rule which matched writes a decision event naming the policy, its mode, its action and why it matched — including rules running in observation mode. A shadow match is evidence that the rule was running and would have acted; the absence of any match is evidence the rule did not fire; and a policy that was disabled is a change in the audit record with a name against it.
The same reasoning extends past policy. A spend ceiling with no price row for the model that was actually served is a ceiling that admits everything, which is why an unpriced route refuses before egress for any agent that has a ceiling configured, and why an agent with no ceiling at all is a separate and visible category rather than a silently unbudgeted one. A discovery source that stopped delivering evidence produces an empty findings list that renders identically to a clean estate, which is why coverage is reported per source, separating a connector that is alive from one that is actually delivering rows, and why a source may only clear a finding when its run completed rather than failed or timed out.
The practical instruction is to ask three questions in every review and to write the answers down: was the rule enforcing at the time, was the agent inside the set the rule’s scope selects, and was the estate inside the coverage the discovery surface claims. A no to any of those changes the remediation entirely.
Reversal, compensation, and the honest limit of both
If the agent did something with an external effect, the reversal question is separate from the containment question and usually slower. Three cases are worth distinguishing.
The effect did not happen. The call was refused, or the tool result was withheld — and note that a withheld result is a completed action whose output is not being shown, which is why such a refusal has to be terminal and explicit: an agent that reads it as retryable will run the side effect again. Nothing to reverse; the work is establishing why it was proposed.
The effect happened and the system it happened in has a compensating action. This is where a bounded contract around the call earns its cost: a declared expectation of what committing looks like, verified externally from evidence rather than from the tool’s own response, a defined compensation path with its own verifier, and a run that stays in a verifying state until fresh evidence matches every compensation condition. Token Observe requires the recovery binding to carry a business key the client already knows rather than depending on a response that may have been lost, retries pending observations within a bounded attempt window, and never lets stale or exhausted evidence advance a terminal success.
The effect happened and nobody can establish automatically whether it did. This is the case that needs a person, and the honest framing is important: an operator adjudication is an attributable attestation of what that operator established, not retroactive independent proof, and it terminally records the outcome without releasing the business key for replay. There is also no distributed exactly-once claim on offer — the downstream system has to honour the supplied idempotency key, and the custody of the verifier and receipt keys is the customer’s problem. Anyone promising exactly-once across a boundary they do not control is describing a wish.
Handling the evidence while the incident is live
Record the chain head before you do anything else. Reading the head is one call and it returns the attested sequence and hash at a recorded time; writing that tuple down somewhere outside the system is what makes every later verification meaningful. Verification compares against something, and the field that says what it compared against is the one to read: a head you supplied externally is the only form that survives a restore, because a restore that lost its tail also lost the attestation of that tail and will verify clean against its own stored state.
Take the export while the window is still inside your retention period, and read the caps. Token Observe’s compliance bundle covers traces and events, approvals with approver identity and rationale, audit entries and a chain verification result, over a default thirty-day window, with limits on how many of each it will include and a truncation flag set inside the file when a cap bites. Only the trace cap is repeated beside the download control in the console today; the others are documented rather than displayed, which means a covering note is where they belong until that changes. A partial bundle described as complete is a worse outcome than a narrower window.
Read the seal for what it is. The bundle carries a SHA-256 digest over the canonical JSON of its body, generated at a recorded time. That is a seal, not a signature: it lets a recipient confirm the file is byte-for-byte the one whose digest they were given through some other channel, and anyone who can rewrite the bundle can recompute it. Durable origin evidence comes from the keyed chain and the off-box anchor, not from the export.
Two failure modes are worth naming because they surprise people. If verification finds intrinsic corruption in the chain, Token Observe returns the detecting request as invalid, deliberately does not append an audit row onto a chain it has just found unsafe, and latches readiness so later governed requests receive a typed unavailable error until a restart. That is a fail-closed design and it looks like an outage; knowing it in advance turns a confusing incident into an expected one. And anchoring refuses rather than signing when the chain does not verify, when the head has moved backwards, or when an already-anchored entry no longer matches — because signing over a rewrite would launder it under a key an auditor was told to trust, while refusing leaves the previous anchor standing, and that anchor still contradicts the rewrite.
Afterwards: erasure, remediation and the parts erasure does not reach
If the incident involved personal data reaching a place it should not have, there is a subject erasure path and it is worth knowing its exact shape before you promise anything. Token Observe erases one data subject’s traces, matched on the named human, the session identifier or either, with a dry run that returns the count before anything goes. Both the preview and the deletion are audited — the preview because reading the prompt corpus for a named person is itself an act worth recording — and the audit entry carries a digest of the subject identifier rather than the identifier, along with the trace ids removed, so the erasure record does not become a fresh copy of the thing erased.
Now the boundary, stated plainly, because a retention or erasure statement that omits it is inaccurate and a data protection officer will ask. Erasure and the retention window act on traces and everything hanging off them: the events, the search index and the scores. The audit chain is never touched, by design, which is what lets the record of a deletion outlive the deleted data. Approvals are not purged and cannot be erased by subject, and they are the one place a short unredacted excerpt of proposed tool arguments survives. Discovery findings are not purged and may carry staff usernames and workstation hostnames from evidence somebody supplied. Webhook delivery records keep the exact bytes that were posted. Identity group snapshots age out on their own authority-aligned window rather than inheriting the trace setting, and so do gateway caller sightings, on a different window again.
The larger boundary is backups. These controls act on the live primary. A retained snapshot preserves whatever existed when it was taken, so restoring a pre-erasure snapshot can resurrect erased traces and can lose the audit row that recorded the erasure. Token Observe leaves a quarantine marker after a restore that blocks a normal boot, and does not ship an offline authority writer, so reconciling the deletions in a lost interval is a controlled procedure rather than an automatic one. The precise claim is erased from the live primary, not gone from every copy.
Then the remediation that actually changes the next incident, in rough order of value: cut the grant that made the action reachable; move the rule that would have caught it from observation to enforcing, having read what it would have stopped; add a payload-bound approval on the specific action rather than on the category; and, if the answer to any of the three review questions was that the agent was outside the coverage, fix the coverage before congratulating yourself on the rest.
How to put AI agent incident response into practice
- 01
Stop the narrowest thing that stops the harm
Kill switch on the agent, the team or the estate; suspend the agent; revoke the key. Name yourself and give a reason, because that reason is the record of why work stopped. - 02
Record the chain head externally, before anything else changes
Read the attested sequence and hash and write the tuple down outside the system. It is the only form of verification that survives a restore. - 03
Pull the trace and the surrounding window
Start from the identifier on the response, then widen by agent, session and time. Read the refusals as carefully as the successes, and note which policies matched in which mode. - 04
Establish whether the control was engaged
Was the rule enforcing, was this agent inside its scope, and was the estate inside the coverage the discovery surface claims. The three answers decide which remediation is the right one. - 05
Decide the reversal path deliberately
Nothing to reverse, a compensating action verified from external evidence, or a human adjudication recorded as an attestation. Do not assume a downstream system honoured an idempotency key it was never given. - 06
Export the evidence while it is inside retention
Take the bundle, check the truncation flag, narrow the window rather than sending a partial file described as complete, and state that the digest is a seal rather than a signature. - 07
Remediate authority before detection
Cut the grant, promote the rule that would have caught it after reading what it would have stopped, and gate the specific irreversible action on a payload-bound approval. - 08
Rehearse it once on a quiet day
Engage and release a kill switch, take an export, verify a chain against an externally held head, and run an erasure dry run. Every one of them behaves differently than the documentation reads until you have done it once.
Where this argument meets an implementation
Audit chain
Every administrative act hash-chained; seal it under a key held off the box, and anchor it with a signature your auditor can check alone.
Flight recorder
Every governed request in a timeline a compliance officer can read, and a search box that never writes SQL.
Human approvals
One human decision, bound to one exact payload, spendable once.
Effect contracts
The action leaves once, and success is what a second pinned tool observed.
Those pages are one product's implementation of what this guide argues for; describe what your agents actually do and you will get a straight answer about whether you need any of it, including when the answer is no.
Talk it throughDoes a kill switch stop a request that has already been sent to the provider?
No. A kill switch is admission control: it is checked first in the evaluation order, before lifecycle, permissions, ceilings and policy, so nothing gets past it — but it acts at the door. A request already dispatched upstream completes, a tool call already executing completes, and an effect already committed downstream stays committed. The same is true of suspending an agent, which takes effect on its next call, and of revoking a credential, which takes effect on the next authentication attempt. Plan the runbook around that rather than around the assumption that a big red button reaches backwards.
How do you tell whether a policy was actually enforcing at the time?
From the decision events on the trace, which name the policy, its mode, its action and why it matched — and which are written for rules running in observation mode as well as enforcing ones. A shadow match proves the rule was running and would have acted; no match proves it did not fire; and a rule that was disabled or demoted appears in the audit record with the person who did it. This is the single most useful property of a governance record in a review, because an estate where every rule is in shadow and an estate with no rules at all produce identical outcomes and completely different remediations.
What should be preserved before restoring from a backup?
The chain head, recorded outside the system, and an export of the relevant window if it is still inside retention. The reason is specific: verification tells you what it compared against, and a head you supplied externally is the only comparison that survives a restore. A snapshot that lost its tail lost the attestation of that tail too, so it verifies clean against its own stored state and against nothing at all — which is exactly the situation where an externally held head is the difference between knowing and assuming.
Can you erase one person’s data from the record after an incident?
From the live primary, yes, with a dry run first and an audit entry on both the preview and the deletion, carrying a digest of the subject identifier rather than the identifier itself. The boundary needs stating in the same breath: it reaches traces, their events, the search index and their scores, and it does not reach approvals, discovery findings or webhook delivery records, none of which are purged. It also does not reach retained snapshots, so restoring a pre-erasure backup can resurrect erased traces. The accurate sentence is erased from the live primary rather than gone from every copy.
What happens if the audit chain itself is found to be broken?
The detecting request returns invalid, no audit row is appended onto a chain that has just been found unsafe, and readiness latches so later governed requests receive a typed unavailable error until a restart. It behaves like an outage and it is deliberate: appending to compromised evidence, or continuing to serve while the integrity of the record is unknown, are both worse than stopping. Anchoring behaves the same way — it refuses to sign a chain that does not verify, a head that has moved backwards, or a rewritten anchored entry, and leaves the previous anchor standing to contradict the rewrite rather than laundering it under a trusted key.
Prefer to ask a person? Write to us →
Bring us the question this guide did not answer.
Write to hello@tenhaw.com with what your agents do, which providers they call and what would have to be true for you to put something in front of them. James Rooney replies. You will get a straight answer about whether Token Observe fits, including when it does not.
no form · no qualification step · no sales desk · the other three ways in