Why this matters

An instruction is not a control boundary

NIST, NSA and CISA have published ten voluntary practices for incident readiness during frontier-system training and evaluation. Their focus is unusually specific: significant uninstructed actions by a highly capable agent that defeat an operator's intended limits or human oversight. That is not the same as a prompt-injection attack, where an adversary steers the system with hostile input.

Even so, the operational questions travel well. A team cannot investigate an unexpected action if it cannot identify the agent, its tool calls, credentials and reachable resources. It cannot contain the action if stopping the workflow leaves its access tokens alive. And it cannot claim recovery merely because a process restarted without repeating the visible symptom.

Scope note

The joint publication targets frontier training and evaluation, not every chatbot or ordinary automation. The checklist below is a defender's adaptation of its incident-response principles, not a claim that the guidance directly mandates these steps for all deployments.

Field checklist

Five questions to answer before the incident

  1. 1

    What can it do?. Inventory the agent's tools, connected data, network reach, service identities and approval gates. Distinguish read access from write or deployment authority, and make privileges narrow enough to revoke.

  2. 2

    What evidence will remain?. Keep action logs, tool-call records, identity events and relevant outputs with timestamps and a stable workflow ID. Protect the monitors and logs from the same permissions the agent uses; redact secrets without erasing the sequence responders need.

  3. 3

    Who can stop it?. Name an owner and rehearse disabling the workflow, revoking credentials and isolating connected tools without depending on the agent to cooperate. Define when humans must approve an action before it occurs.

  4. 4

    How will you explain the action?. Separate observed behaviour from cause. Was the action requested by a user, induced by untrusted content, produced by a tool defect or chosen by the agent while pursuing a legitimate task? Similar logs can support different explanations.

  5. 5

    What proves recovery?. Before restart, verify containment, correct the authority or software path that allowed the action, check for downstream changes, and test the resumed workflow under reduced permissions. Record near-misses as well as confirmed incidents.

Defender note

The useful exercise is a rehearsal, not a policy document

Pick one real agent workflow and ask its owner to demonstrate a shutdown while a task is in progress. Then try to reconstruct the last five tool actions and identify every credential that remained usable after the stop. The gaps you find will be more actionable than a general promise to keep a human in the loop. NIST's broader incident-response framework reinforces the same lesson: preparation, detection, containment and recovery depend on decisions made before an incident starts.