An agent reports that it sent a file to an unexpected destination. The application log shows a timeout. The user asks whether the transfer happened. Restarting the agent cannot answer that question and might repeat the action.
A response plan needs to address both software state and external effects. This guide uses a hypothetical document-transfer incident to show the decisions involved. It is an engineering playbook, not a report of an actual breach or a substitute for your organization’s incident procedures.
NIST SP 800-61 Revision 3 places incident response within broader cybersecurity risk management, connecting preparation, detection, response, and recovery. An agent-specific playbook should extend that existing discipline rather than create a separate process with no owner. NIST incident-response recommendations
Establish who can stop the action
Before an incident, assign ownership for the agent, its execution environment, credentials, external integrations, and communications. A pause control is useful only if someone can operate it and knows its scope.
Distinguish pausing new tasks from stopping in-flight actions. A worker may have already submitted a provider request or scheduled a retry. Stopping the model loop does not necessarily stop those operations.
For a document-transfer system, identify how to disable the affected tool, revoke or restrict the relevant credential, pause queued jobs, and block the destination if warranted. Choose the smallest containment that meaningfully limits further harm; preserve unrelated essential work when doing so does not undermine containment.
Do not assume revoking a credential reverses a transfer already completed. Containment prevents further activity. Determining and addressing past effects is a separate job.
Preserve evidence with an access decision
Capture the task identifier, authenticated actor, tool request, policy decision, approval record, timestamps, provider request identifier, and execution result. Preserve the exact configuration in force, including model, tools, prompt versions, and network policy.
Record what is known and unknown. “The provider timed out” is an observation. “The file was not transferred” is a conclusion that requires additional evidence.
| Evidence | Question it helps answer |
|---|---|
| Authorized task and scope | What should the system have done? |
| Source content and provenance | What external material influenced the proposal? |
| Proposed and executed arguments | Did the action change before execution? |
| Approval and policy records | Which boundary allowed or blocked it? |
| Provider identifiers and receipts | Did the external effect happen? |
| Queue and retry state | Could the effect still occur again? |
These records can contain sensitive information. Restrict their access and retention as part of the investigation. Copying every private document into a general chat channel creates another disclosure path.
Reconcile the external state
For a timed-out transfer, consult the destination service’s request records or other authoritative state. Use a stable request identifier when the integration provides one. Do not replay the request merely to see whether it succeeds on the second attempt.
Classify the result as confirmed completed, confirmed not completed, or unresolved. Keep unresolved work out of automatic retry until the duplication and disclosure risk has been assessed. Where an operation is idempotent, verify what the provider actually guarantees; the presence of an idempotency field alone does not establish safe behavior across every failure mode.
If a transfer completed, determine the payload, destination, access permissions, and any onward actions that are visible. Deleting a local copy does not recall an external disclosure. Follow the organization’s established processes for further containment and communication.
Investigate the boundary, not only the prompt
A malicious document may explain why the model proposed the transfer. It does not explain why the application permitted it. Investigate the full chain: source ingestion, context assembly, proposal, authorization, approval, execution, and retry.
Possible findings in this hypothetical system include overly broad credentials, an unrestricted destination field, an approval not bound to the final payload, or a retry path that bypassed the normal policy check. Each requires a different correction.
Avoid stopping at “the model was confused.” That may describe behavior without identifying a control the team can change. Conversely, do not attribute malicious intent to an external source without evidence; an ordinary document or application defect can produce a harmful outcome too.
Restore through a narrower path
Before resuming, specify the condition that makes the affected operation acceptable again. It could be removing the upload capability, limiting destinations, correcting an authorization bug, or requiring explicit review for the transfer type.
Validate that condition using controlled requests and non-sensitive data. Include the observed incident path and a normal authorized task. A fix that prevents all work is containment, not necessarily a service restoration.
Inspect pending proposals and queued jobs before releasing them. They may contain the old arguments, stale approvals, or source material involved in the incident. Regenerating or reauthorizing them can be appropriate; blindly replaying a backlog is not a neutral recovery step.
Communicate uncertainty directly
Give users a factual status: what operation is paused, what effect is confirmed, what remains unresolved, and when the next update will occur if your response process defines one. Avoid reassuring statements that the evidence cannot support.
Separate internal technical findings from external communication decisions. The incident owner should coordinate any required notifications through established channels. This article does not determine legal reporting obligations, which depend on the facts and jurisdiction.
A post-incident review should identify contributing conditions, corrective actions, responsible owners, and verification evidence. Include gaps in observability: inability to establish whether an action occurred is itself an operational finding.
Turn the incident into a durable improvement
Add a regression case for the failed boundary, update the action policy, and revisit the granted capabilities. Preserve the distinction between fixing a known path and proving resistance to every future attack.
Review dependent memory as well. If the agent stored the hostile instruction or a misleading summary, the next task can encounter the same influence after the immediate source is removed. Trace and invalidate derived records where your system supports that lineage.
Continue with secure agent memory and evaluation design to connect recovery evidence to future release decisions.