Stopping an AI agent safely

When closing the chat is not enough

Hypothetical scenario: a service company uses an agent to update customer records and schedule follow-up messages through a connected CRM. A manipulated support ticket leads it to change records outside its assigned queue.

An employee spots the problem and closes the chat window. In this scenario, a background workflow continues processing pending updates. The visible interaction has ended, but the unauthorized activity has not.

This is a security incident because the agent is acting beyond its authorized scope. An inaccurate summary, by itself, would raise a different question about quality. The response should follow the nature and consequences of the event.

The Canadian Centre for Cyber Security recommends developing and testing procedures to detect, contain and recover from agent compromise.^[1] For a smaller organization, a practical starting point is one agent, one consequential workflow and the people who can operate its connections.

What do we mean by “stopped”?

An AI agent combines a model with software that calls tools and manages work. The chat window is one interface to that software. Closing the window may leave a server-side task running.

A queue is a waiting list of accepted jobs. A retry is another attempt after an operation fails or times out. A scheduled trigger starts work at an agreed time. These may belong to the connected application, with separate controls from the agent.

For this playbook, containment means stopping the harmful capability, not necessarily shutting down every business function. A service might keep answering general questions while its ability to edit customer records is suspended. Whether that separation is possible must be verified in the actual product.

1. Give someone clear authority to intervene

Name the person who can suspend the affected capability, a backup and the vendor contact when your team cannot operate a control directly. Confirm that these people have the necessary access before an incident begins.

Define the triggers in business terms. Examples include an unexpected external transfer, changes outside an approved record set, or evidence that an agent credential has been compromised. State which actions a responder can take immediately and which decisions require escalation.

NIST’s Generative AI Profile addresses responsibilities and criteria for deactivating or disengaging systems, alongside communication and remediation procedures.^[2] Apply that thinking to the specific workflow rather than leaving “human oversight” as a general promise.

Agree on a workable fallback. Can staff handle new requests manually while the agent’s write access is suspended? Which essential services depend on the same connection? Answering those questions helps responders contain the problem without introducing avoidable disruption elsewhere.

For the CRM example, the service manager declares the affected workflow suspended and moves urgent requests to a manual queue. The technical responder operates the agent and connection controls. The CRM administrator checks pending jobs and completed changes. The business owner decides when service can resume. One person may cover several roles, but each action still needs an identified owner and backup.

2. Map what each stop control affects

Different controls act at different points in a workflow. Ask the technical owner or vendor to document the following, including anything your team cannot stop directly.

Do not assume that an access change takes effect identically across applications. Microsoft’s emergency user-access guidance, for example, explains that application-issued session tokens require the application’s own revocation mechanisms.^[3] That is a product-specific example of why the mechanism matters, not a universal procedure for agent identities.

Ask the relevant owner to demonstrate the controls for the actual authentication method and deployment. Record any delay or limitation. Removing future access does not undo a completed transaction, and stopping an agent does not necessarily cancel a request another system already accepted.

3. Run a controlled containment exercise

Use synthetic customer records, a non-production environment and a harmless update task. Define the permitted records and expected outcome before the run. Include the business owner, the technical responder and the vendor if a critical control depends on them.

1. Establish the baseline. Record the agent, workflow version, acting identity, connected services and test records. Identify how to observe writes and queued work in the receiving system.
2. Start the workflow. Allow a small, known set of permitted actions. Introduce a simulated incident trigger through the agreed test procedure.
3. Invoke containment. Record who acted, which controls they used and when. Check new runs, active execution, relevant access and already-accepted work.
4. Verify the outcome. Identify the last successful action and any subsequent activity. Reconcile the test records and pending jobs. Document unresolved dependencies.

Set an observation period that accounts for the workflow’s schedules, queues and retry behaviour. A quiet log is only useful when you understand what it captures. If evidence is missing, record the uncertainty instead of declaring containment successful.

For the hypothetical CRM example, the exercise might show that the stop control prevents new runs while a previously submitted batch continues. That finding should lead to a documented way to halt or isolate the batch, or to a decision to restrict the capability until adequate containment is available.

A dashboard displaying “disabled” does not settle these questions. The exercise needs evidence from the systems where changes actually occur.

A worked example: the pause worked, but the changes continued

Hypothetical exercise: the agent submits ten synthetic customer-record updates in one batch. A batch is a group of requests accepted for processing. The CRM processes them separately from the agent. The timestamps below illustrate the sequence; they are not a recommended response-time target.

The finding is precise: the agent pause stopped new requests, but did not cancel work the CRM had accepted. The additional batch control was needed. Revoking the agent’s credential alone would not necessarily stop those accepted jobs either.

The reviewer links the agent run ID, batch B17, all ten job IDs and the five changed records. They verify that no retry process can release the held jobs, and that the next scheduled run is blocked. If clocks differ between systems, record the difference and use shared job IDs to establish the sequence.

During a real incident, apply the pre-authorized containment actions promptly and preserve available evidence alongside them. Do not wait for a complete explanation before stopping an active unauthorized write. Also avoid erasing queues or logs just to make the dashboard appear clear; quarantine preserves the ability to investigate where the product supports it.

What evidence would show containment worked?

Before the exercise, the business owner should define the acceptable consequence and the maximum tolerable delay in stopping it. A payment workflow and an internal draft-writing workflow may need different targets. Choose an observation period that includes relevant schedules and retry delays; record any vendor behaviour that remains unknown.

• New work is blocked: a controlled attempt to start the suspended workflow fails, including its scheduled route.
• Consequential actions are blocked: a harmless test write under the affected identity is rejected at the enforcement point. Confirm that its test record remains unchanged.
• Accepted work is accounted for: every known job has a verified completed, cancelled or quarantined status. Held jobs cannot automatically resume.
• Effects are reconciled: receiving-system records identify the last completed change and any activity after intervention. An independent check of the affected data agrees.

In the worked example, accounting for all ten jobs is stronger evidence than seeing “agent disabled.” If the supplier cannot expose pending jobs or provide a cancellation confirmation, record containment as unverified for that dependency. Keep the relevant restriction in place and escalate through the incident process.

A successful exercise supports the tested workflow and configuration. Repeat relevant checks after changes to connectors, identities, scheduling or queue handling. It does not establish that every possible execution path can be stopped.

Preserve evidence and approve recovery

As containment proceeds, retain the triggering input, relevant tool calls, affected-record identifiers, permission decisions and application events. Protect these records and avoid unnecessary copies of customer information. Evidence collection should support response without delaying urgent containment.

NCSC’s secure AI deployment guidance recommends incident-response preparation, trained responders and usable audit records.^[4] Build the agent procedure into the organization’s existing incident process, including its escalation and communication arrangements.

Before restoring the affected capability, the responsible owner should be able to establish:

• What caused the unauthorized behaviour and which control failed.
• Which records, messages or other actions were affected, including work completed after intervention.
• How corrective action was tested, including the relevant containment scenario.
• What access will be restored, who approves restart and how the resumed workflow will be monitored.

Reconcile affected records before correcting them. A blanket rollback can overwrite legitimate changes made by other people or systems. Separate reversible changes from consequences that cannot simply be undone, such as information already disclosed.

Changing the prompt alone does not demonstrate that an access or execution problem has been resolved. Start with the smallest appropriate scope when resuming work and retain any restrictions needed while open findings are addressed.

A concrete restart decision

For the worked example, the owner might authorize read-only customer lookups while record updates remain disabled. The five completed changes are compared with approved values and corrected individually; J06–J10 remain quarantined and are not replayed automatically. The technical owner must demonstrate record-level authorization and repeat the containment test before requesting restoration of write access.

The restart record should name the approver, permitted capability, outstanding restriction and person monitoring the initial runs. If the underlying cause remains uncertain, make that uncertainty explicit and define how the temporary restriction prevents the known harm. Follow the existing incident process for any required customer, privacy or legal assessment.

A practical exercise record

Use these seven fields in your existing incident or testing record. Keep detailed evidence in its controlled location and link to it.

Keep this record alongside the workflow’s ownership and dependency information. Revisit it when tools, permissions, scheduling or vendor behaviour change.

For the action-by-action evidence review, use the companion trajectory assurance guide and editable checklist.

If your agent began making unauthorized changes today, who could contain it, and what evidence would show that the changes had stopped?