Prepare an incident runbook for the tools an agent can actually use

An alert reports that an assistant attempted an unexpected outbound request after reading a document. The final answer says the task completed normally. You need to determine whether data actually left the system, which credential was used and whether the same path is still available.

A transcript alone will not answer all of those questions. Neither will a generic rule to restart the service. An agent incident runbook should follow the tools, resources and downstream effects that make the application consequential.

Prepare that runbook before an alert forces the team to discover who owns each part of the execution path.

Decide who can stop which capability

Name an incident coordinator, an application operator and the owners of important downstream integrations. Record how to reach them without relying on the affected assistant. A runbook stored only inside a service that may be unavailable is hard to use when it matters.

Define containment controls at useful levels: a single tool, an integration credential, a tenant, a server release or the whole service. The narrowest effective control can preserve unrelated work, but do not let a preference for uptime leave a harmful action path open.

Test these controls in a non-production exercise. Confirm whether disabling a tool prevents new calls, queued calls and retries. A switch that removes a button but leaves an active worker running does not contain the same set of operations.

NIST SP 800-61 Revision 3 places incident response within broader cybersecurity risk management, including preparation, detection, response and recovery. The procedure below is an application-specific adaptation, not a prescribed NIST sequence or a claim of compliance.

Separate an attempted effect from a completed effect

Begin with a small set of factual questions. What operation was proposed? What did the policy layer allow or deny? Did the executor send a request? Did the downstream service accept it? What result can be independently verified?

A denied tool call is different from a successful transfer. A timeout after a write is different from proof that the write did not occur. Keep those states distinct in the incident record, including what remains unknown.

For the unexpected outbound request, inspect the execution ledger and the authorized network or downstream-service logs. A hostile sentence in the retrieved document may explain the attempted behavior, but it does not by itself establish that the model obeyed it or that the destination received private data.

Preserve uncertainty explicitly. “No completed transfer found in the available logs” is a narrower statement than “no data was disclosed,” especially when logging or retention has a known gap.

Preserve the causal chain

Collect the release artifact identifier, configuration revision, tool catalog revision, relevant policy version, authenticated principal reference and operation identifiers. Preserve the source document or a controlled evidence copy where your retention and access policy permits it.

Avoid distributing sensitive evidence through ordinary chat channels. Use an access-controlled incident record with a clear owner. Record collection times and evidence provenance so another responder can distinguish original records from later reproductions or annotations.

Retain the raw evidence needed for analysis before applying destructive cleanup, where doing so is compatible with immediate containment. Hashes can help detect later changes to evidence, but a digest without the corresponding record does not explain what happened.

Do not rerun a suspicious tool with production credentials merely to see whether it fails again. Construct a reproduction with synthetic data and restricted permissions after the immediate operating risk is controlled.

Work through a contained exercise

Suppose an internal document contains a request to send private notes to a new destination. A test alert fires because the assistant proposed a delivery action outside the user's approved recipient list.

The response can proceed along an evidence checklist:

The exercise should use harmless test records and a controlled sink, not real private notes. Its purpose is to establish whether the team can gather evidence and operate the controls, not to simulate a real disclosure with customer data.

Revocation must be verified

Changing a secret in configuration does not prove that the old credential is unusable. The downstream system may still accept it, a running process may still hold it, or another deployment may share it. Follow the credential owner's revocation procedure and verify the intended result through authorized checks.

Inspect related credentials and scopes without assuming they are all compromised. A shared administrator token creates a different containment problem from a narrowly scoped per-user token. This is one reason to document credential ownership before an incident.

Review session and job behavior after revocation. A long-running operation may need cancellation or isolation separately. Make clear which changes prevent new work and which changes stop work already accepted.

Recover against an explicit hypothesis

A patch should address the failure you identified: an authorization check missing at execution, an overly broad credential, a changed tool description, an unsafe destination rule or a compromised artifact. Restoring service without stating that hypothesis makes it difficult to judge whether the control is relevant.

Before recovery, test the failing scenario with synthetic data, the normal authorized scenario and a nearby edge case. Verify the deployed artifact and configuration, not only the source change. Watch for retries or delayed work that could repeat the original effect after service resumes.

Set a limited recovery scope and an owner who can stop it. Keep unresolved questions visible rather than translating an operational recovery into an assertion that every aspect of the incident is understood.

Close with changes to the system

The review should identify which boundary failed, which evidence was missing and which control was difficult to operate. Give each improvement an owner and an acceptance test. Avoid a conclusion that only says the model should have followed its instructions more carefully.

Add a minimal synthetic regression case to the evaluation suite. Update the permission inventory and the runbook if the incident exposed an undocumented dependency or credential. Review whether logs collected too much sensitive content or too little operational evidence.

A useful incident process leaves the next responder with fewer guesses. The assistant's final answer is one part of the story; the durable record is what the system was authorized to do, what it actually did and how you established that the dangerous path was closed.