An AI Agent Was Stopped. What Evidence Makes It Safe to Restart?
Interpret October 2026 voluntary NIST guidance in scope, then build a practical incident drill that separates containment, evidence, side effects and restart tests.
An inventory assistant is supposed to read records and draft a report. A monitoring system detects a write request, blocks it and pauses the job. The obvious next step is to fix the prompt and try again. The more useful next step is to establish what actually happened and whether the controls still work.
On 16 October 2026, NIST announced ten voluntary practices for incident readiness and response during super intelligence training and evaluation. The document's primary audience is organizations training or evaluating highly capable agents on long tasks with limited human supervision. It is not a universal legal requirement for every chatbot.
This article develops an original, smaller report-job drill. The fictional assistant is not claimed to be super intelligence, and no real breach is alleged.
Separate a bad answer from a control incident
A report with a wrong total is a quality failure. An agent attempting an out-of-scope write is also a control concern, even if the gateway blocks the request. The investigation should distinguish attempted behavior, actual access and completed effects.
The joint October publication defines its own class of SI control incidents and covers preparation, monitoring, response, recovery and reporting. Its scope includes significant uninstructed actions that compromise task boundaries or oversight. Do not silently relabel every ordinary model error as that specific class of incident.
For the fictional reporting system, define an internal near-miss category for denied out-of-scope tool requests. Define a more severe category when a write succeeds or when the evidence cannot establish the boundary. Document these local definitions before a drill so severity is not negotiated around a preferred outcome.
Contain behavior at the boundary that can enforce it
In the exercise, a job has read-only authorization but submits a write request. Pause new work from that job and enforce the intended access restriction at the tool or service boundary. A message asking the model to stop is not the same as an access control that rejects further actions.
Check queued tasks, delegated workers, scheduled retries and credentials associated with the run. The relevant containment target is the set of capabilities that can produce effects.
These are proposed drill steps for this fictional system, not a universal sequence for all incidents. When harmful activity is ongoing, do not leave it running merely to collect a more complete trace. Prepare evidence collection in advance so responders can contain and preserve useful records together.
Preserve a versioned evidence package
NIST SP 800-61 Revision 3, published in April 2025, treats incident response as part of cybersecurity risk management. Its analysis guidance emphasizes preserving incident data and metadata with integrity and provenance, safeguarding records, and following the organization's retention procedures.
For our report-job drill, an evidence package could contain:
| Artifact | Question it helps answer | Important limitation |
|---|---|---|
| Task and authorization snapshot | What was the job allowed to do? | A later policy edit is not the original policy |
| Tool requests and gateway decisions | Which actions were attempted and denied? | Gateway visibility may be incomplete |
| Downstream service records | Which effects were actually accepted? | A missing record is not always proof of absence |
| Queue and worker inventory | What work could still run? | Inventory must include delegated execution |
| Model, harness and tool versions | What configuration produced the behavior? | Version labels alone may not identify artifacts |
| Response action log | Who changed what, when and why? | Clock differences can complicate ordering |
Record collection time, source, access restrictions and artifact identifiers. Preserve the original evidence securely; produce a redacted working copy when appropriate. Prompts and tool responses can contain personal data, credentials or confidential records, so indiscriminate logging creates another exposure.
Reconcile attempts with completed side effects
Suppose the gateway shows one blocked write and the queue contains two pending retries. That does not mean three records were changed. It also does not justify claiming that the system is clean merely because one request was denied.
In this original drill, responders cancel the pending retries and compare gateway records with service transaction records for the relevant job identity and time window. They record zero accepted writes found in those inspected records. The scope of that statement stays attached: inspected identities, services and timestamps.
If a separate tool used a shared credential, the search may need to expand. If downstream logs are missing, record an unresolved exposure rather than converting “unknown” into “none.” Reconcile retries before restarting so old work cannot execute under a supposedly fresh run.
Test the boundary rather than only rewriting the prompt
A root-cause review might find that the prompt was unclear, the tool exposed unnecessary write methods, or an authorization check trusted an agent-supplied role. Those explanations require different fixes.
For the example system, a regression test should submit the same prohibited action through the ordinary tool path and confirm rejection independently of model wording. A positive test should confirm that the intended read operation still works. Verify that the alert identifies the correct run and that the response mechanism pauses the relevant workers.
Changing the model or adding a more emphatic instruction may affect behavior, but it does not establish that the permission boundary is enforced. Keep behavioral evaluation and authorization testing as separate evidence. The trust-boundary guide explains the related distinction between receiving information and granting it authority.
Make restart an explicit evidence-based decision
The October publication specifically emphasizes strengthening and checking containment before resuming activity. It also discusses recovery from verified baselines and documenting remaining risk. Those are selected recommendations within its stated audience, not proof that an adapted checklist guarantees safety.
For this drill, the accountable owner reviews four local gates: pending work is reconciled; relevant credentials and permissions are reviewed; the configuration is restored to a known, identified baseline; and both denial and permitted-operation tests pass. Any uninspected service path remains visible as a residual risk.
Restart first with a restricted, observable job appropriate to the incident's scope. Establish a stop criterion and a review point. Do not define success solely as the agent failing to repeat the exact wording of the original action.
Practice reporting before the real incident
Prepare an internal update that distinguishes confirmed facts, working hypotheses and unknowns. Assign an incident owner and identify who decides on notifications. The applicable obligations depend on contracts, jurisdiction, data and impact; the October document's voluntary nature does not determine those separate requirements.
After the drill, record what responders could not answer quickly. Missing job identities, shared credentials and inaccessible downstream logs are concrete readiness findings. Assign owners to repair those gaps and repeat the exercise against the updated system.
Stopping an agent is an action. Demonstrating what was stopped, what remains uncertain and why restart is justified is the operational result a review should produce.
Sources and scope
- NIST announcement, 16 October 2026: release date, voluntary nature and primary audience.
- Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation, October 2026, version 1.0: primary joint publication; audience, incident scope and selected recovery practices reviewed.
- NIST SP 800-61 Revision 3, April 2025: incident-response evidence integrity, provenance, retention and confidentiality considerations.
Sources checked 30 October 2026. All report-job events, local severity definitions and restart gates are original illustrative proposals. No claim of regulatory compliance, actual compromise or independently validated containment is made.