Field guide / defensive incident readiness
When an autonomous system fails, the first question is not whether the model was ‘hacked’. It is which authority, context, tool, data path or dependency crossed its boundary — and what evidence proves that the path is contained.
Stop unsafe activity, revoke or narrow the affected authority, isolate the smallest responsible component, preserve a minimal evidence trail, notify the system owner and incident contact, and record decisions with timestamps. Then prove containment through live behavior. Do not treat a green configuration screen as proof that an agent, tool or credential can no longer act.
Validate what happened, identify the affected agent, tools, identities, environments and data, and assign a priority based on authority gained, mission impact, exposure and detectability. Severity levels prioritize work; they are not public response-time promises.
Pause unsafe side effects, revoke or narrow credentials, disable a tool or route and isolate the smallest component that can stop recurrence. Preserve a safe read-only path when it helps the investigation.
Build a timeline of actors, prompts or inputs, retrieved context, tool calls, destinations, results and side effects. Minimize copied personal or client data, restrict access and hash the artifacts that matter.
Rotate exposed secrets, remove persistence, inspect model, skill, prompt, tool and dependency changes, and distinguish a local symptom from a control failure that can recur elsewhere.
Restore from a known-good state, re-enable authority in stages and watch the actual runtime. Verify identity, approvals, egress, idempotency, logging and stop paths before returning to normal autonomy.
Follow contractual, legal and coordinated-disclosure duties through the owner's path. Write a blameless record, assign follow-ups, add regression gates and update the threat model and runbooks.
Prompt injection, poisoned retrieval or a tool response is treated as policy and changes what the agent believes it may do.
A token, role or service account can read, write, spend or publish beyond the task that created it, with no independent revocation proof.
A timeout or partial response causes a payment, message, upload or durable write to happen twice because correlation and idempotency were not enforced.
A model, skill, MCP server, package or prompt update silently changes tool behavior, egress, provenance or the evidence needed to trust a release.
Preserve the smallest set of logs, traces, configuration versions, tool schemas, identity events and relevant inputs needed to reconstruct the decision. Keep it access-controlled, time-stamped and tied to an evidence hash where practical.
Do not delete logs to make the incident disappear, copy an entire customer dataset “for analysis”, probe an external system without its owner's authorization, or restart an agent repeatedly while its side effects are unknown.
Start with the five-minute readiness checklist → or compare incident-readiness and verification services →
Stop unsafe activity, narrow or revoke the smallest affected authority, preserve only the evidence needed to understand the event, notify the owner and incident contact, and record a timeline. Confirm containment through observed behavior rather than configuration alone.
The response must account for delegated authority, tool side effects, prompt and retrieval context, memory writes, model or skill dependencies, retries and human approvals. The core lifecycle remains triage, containment, eradication, recovery, communication and learning.
Do not destroy evidence or copy more personal data than necessary. Preserve a bounded, access-controlled record with timestamps, identities, inputs, tool calls, destinations, results, side effects and evidence hashes, following the system owner's retention and legal requirements.
No. Severity levels help prioritize work; they are not public response-time promises. Notification, regulatory, contractual and legal duties belong to the system owner and qualified counsel for the relevant jurisdiction.
A bounded engagement may help an authorized owner reconstruct the control failure, contain access, verify remediation and record residual risk. Work starts only with a named owner, written scope, approved data handling and Rules of Engagement for any active technique.