AckuityRequest assessmentThe agent is stopped. A customer record has already changed. A report is waiting in a queue. A delegated worker may still have its own credentials. Which part of the incident is over?
The stop button answers one question: can this agent continue from here? An incident response runbook must answer another: what has already happened, what can still happen, and what makes it safe to resume? That requires records from the systems that accepted the work, alongside the agent's trace.
This is Ackuity's proposed operational runbook, not a completed product test or an incident-response service commitment. The example is synthetic. The downloadable worksheet is blank; its six rehearsal cases are unrun.
CONTAINMENT IS A CHECKPOINT
What does stopping the agent actually stop?
Begin with a containment map. List the agent process, its runtime, its sessions, the tools it can reach and any delegated workers. Assign a human incident owner with authority to coordinate the application, identity and target-system teams. Do not ask the agent under investigation to certify its own containment.
Record which control was applied and when. A process termination, a network restriction, an expired approval and a credential revocation affect different boundaries. Confirm what each control covers in your deployment. Treat a missing acknowledgement as unresolved rather than successful containment. Where active harm is occurring, containment can take priority over collecting every artifact; record that tradeoff and preserve evidence where feasible.
NIST SP 800-61 Revision 3, published in April 2025, places incident response within broader cybersecurity risk management and covers detection, response and recovery. The action ledger below is our proposed way to apply that operational discipline to agents. It is not a NIST certification or a claim that NIST prescribes this worksheet.
FOLLOW THE WORK
Which actions can still finish after containment?
Inventory work by its state, not just by the name of the agent that requested it. A target may have accepted an operation before the agent stopped. A worker may retry it later. A child agent may act under a separate identity. Whether these paths exist depends on your architecture; investigate them explicitly instead of assuming they do or do not.
| Boundary | Question to resolve | Evidence to retain |
|---|---|---|
| Agent runtime | Has the process or session actually ended? | Runtime identifier, termination result and timestamp |
| Delegated worker | Can it act independently under another identity? | Parent-child link, identity and scoped containment result |
| Queue or scheduler | What was accepted, retried, cancelled or completed? | Job identifiers and queue or worker records |
| Target system | What changed, and is another change still pending? | Transaction, audit event or version history |
Do not equate an API acknowledgement with the final business outcome. Record acceptance and completion separately. For systems that support cancellation, verify the cancellation result at the accepting service. If cancellation is unavailable or uncertain, isolate the remaining path where authorized and track it as outstanding.
Amazon SQS standard-queue documentation explains that a message can be delivered again and recommends idempotent processing. That is a concrete reason to inspect retry behavior in systems using that service. It is not a claim that every queue uses the same delivery semantics.
BUILD AN INDEPENDENT TIMELINE
What evidence shows the incident's actual scope?
Join each consequential action to the initiating task, acting identity, applicable policy or approval, tool request, decision and target-system result. Keep original timestamps and time zones. If clocks disagree, record the uncertainty rather than forcing a precise sequence. Preserve references to secured evidence, not raw secrets, tokens or sensitive customer records inside a shared worksheet.
Use a stable request, job or transaction identifier when one exists. If you must correlate by identity and time, label that inference and its confidence. An agent statement that a write failed is weaker evidence than a target-system event showing whether it committed. A decision labelled Block alone also does not establish what happened at a target.
The November 6 WorkOS bulletin provides a useful example of timeline separation. WorkOS reports first access on October 25 and bulk retrieval on October 30, and says it correlated researcher artifacts with its logs and an independent forensics firm. Those dates do not establish five continuous days of extraction. The bulletin does not publish the sandbox-escape technique, and Ackuity was not involved.
For the short, source-qualified account, see the WorkOS Rogue Pixel episode. Keep incident observations separate from proposed preventive controls.
RECONCILE THE TARGET
What changed before the agent stopped?
Compare intended state with observed state for every affected resource. Include records, files, permissions, messages and scheduled operations where relevant. Classify each item as unchanged, changed, pending or unresolved. A successful rollback of one write does not resolve a separately queued notification or a delegated operation.
Use a synthetic rehearsal to make this concrete. An agent was authorized to prepare an internal report, but requested an external export and queued a notification. After containment, the responder checks the export service, report storage and notification worker separately. No completed outcome is assumed. The rehearsal passes only when the team can explain each observed result and identify any unresolved path.
Choose recovery actions with the system owner. Where possible, use supported rollback or compensating operations and preserve the before-and-after evidence. Some effects, such as disclosed data or an already delivered message, cannot simply be reversed. Do not turn a successful repair into a claim that the original exposure never occurred.
Credential invalidation is one part of this work. Use the separate agent credential revocation guide for sessions, delegated credentials and propagation checks. This runbook concentrates on the incident state that remains to be reconciled.
RESTART IS A NEW DECISION
When is it reasonable to resume the task?
Require a named owner to approve the restart scope. Resolve the cause of the unsafe action, confirm the relevant identity and destination restrictions, and document residual risk. A new credential alone does not fix an unsafe tool route, an overly broad task or an exposed target service.
Rehearse the prohibited operation and a permitted comparison using synthetic data in an authorized environment. Verify that the prohibited effect is prevented within the tested scope and that the legitimate task can still finish. Use the false-positive evaluation guide to avoid confusing broad blocking with useful protection. Do not replay destructive operations against production as a test.
Restart with a bounded task, an accountable owner and monitoring that reaches a human. Decide in advance what evidence would trigger another pause. Close the incident only when the team has reconciled the affected state, assigned any unresolved work and retained a record of the recovery decision. Closure does not require pretending that uncertainty has disappeared.
TAKE IT TO A REHEARSAL
Use the incident-response worksheet
Download the blank CSV action ledger or the JSON worksheet with six proposed rehearsal cases. No email is required. All cases start as UNRUN, and observed outcomes are blank.
- Choose a synthetic task and write its authorized scope before testing.
- Assign the incident owner and system owners; agree on evidence access.
- Record the containment checkpoint, outstanding jobs and delegated identities.
- Reconcile each target result and its uncertainty.
- Record the permitted comparison and the restart decision separately.
The six cases cover an accepted asynchronous operation, a delegated worker, a retry, partial completion, conflicting evidence and a scoped restart. They are prompts for your own rehearsal, not benchmark findings. Do not put credentials or personal data in either download.
WHERE ACKUITY FITS
What should you evaluate before the next incident?
Ackuity is the Agent Execution Control Switch AI builders add to their agents, verifying every action before it runs. Its Agent Security Context Graph assembles context for that action. An execution decision is one part of the evidence responders need; it does not replace the target system's record or a recovery process.
In a proof of concept, ask the team to connect a request, policy, decision and independently observed target outcome. Confirm the coverage of the specific deployment path and compare a prohibited action with permitted work. This article does not claim that Ackuity performed the WorkOS containment, cancelled queued jobs or completed the six rehearsals. Use the agent security evaluation checklist to define a testable scope.
OWASP's AI Agent Security Cheat Sheet is a complementary reference for least privilege, monitoring and multi-agent controls. This runbook's ledger and restart gate are Ackuity's proposed operating method, not an OWASP endorsement.
PRIMARY REFERENCES
Sources and limits
- NIST SP 800-61 Revision 3: incident-response recommendations within cybersecurity risk management, April 2025.
- WorkOS incident update: first-party reporting published November 6, 2026. Dates and attribution are WorkOS's account.
- Amazon SQS at-least-once delivery: service-specific behavior, not a universal queue guarantee.
- OWASP AI Agent Security Cheat Sheet: complementary security guidance. No certification or endorsement is implied.