An AI agent's stop button has to reach the systems it can still control

NCSC and NIST 2026 work points to an operational question: can the organisation halt an agent, reconcile uncertain actions and recover?

A cancelled task can leave a surprising amount of work alive. A request may already be waiting in another service, a background worker may still hold credentials, and a second agent may be acting on an earlier instruction. For an organisation adopting autonomous AI, stopping the chat is only one part of stopping the operation.

The practical question is whether a named operator can interrupt the system's ability to act, establish what has already happened, and decide how to recover. That question belongs in the design before an agent receives access to consequential tools. It also provides a useful way to evaluate a proposal that promises more autonomy than the organisation has previously allowed.

The 2026 guidance reaches beyond the prompt

In its [20 August 2026 interim advice on agentic AI](https://www.ncsc.gov.uk/blogs/managing-the-cyber-risk-of-agentic-ai), the UK's National Cyber Security Centre recommends technical and operational safeguards alongside instructions. Its emergency-shutdown discussion explicitly reaches beyond stopping an agent process to restricting network access and interrupting communication with inference infrastructure.

This is interim practical advice, with formal guidance still being developed according to the page checked on 15 October. It is not a certificate that a particular sandbox or product will contain every behaviour. Its useful contribution is a broader control boundary: inspect everything the agent can influence, rather than only the application window through which a person started it.

Separate the task from the machinery

Consider a fictional equipment-repair cooperative in Accra. Its proposed assistant reads invented service requests, suggests appointments and prepares draft replies. The example is a design exercise, not a reported deployment. The cooperative initially describes all three activities as one task: organise tomorrow's repairs.

The technician reviewing the proposal separates them. Reading a request needs access to a bounded queue. Suggesting an appointment needs relevant availability. Sending a reply changes another person's information environment and should have its own approval. If those steps share one unrestricted execution path, a mistaken interpretation at the beginning can travel further than the cooperative intended.

The team draws the operations before discussing model quality. Each consequential step has an accountable owner, a permitted resource set and a point at which a stop request must be checked. The model can propose a step; the application decides whether that step is currently allowed.

Documents do not issue new permissions

[OWASP's LLM01:2025 discussion](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) describes direct and indirect prompt injection and recommends measures including least privilege, human approval for high-risk actions and separation of external content. The point for the cooperative is straightforward: a sentence inside a service request is material to interpret, not a new instruction from the system owner.

In the exercise, a synthetic customer note asks the assistant to contact an unrelated address. The intended outcome is a safe refusal or a review state, with no communication dispatched. There is no need to publish a clever malicious payload to test the basic boundary. A harmless request for an explicitly forbidden operation can reveal whether the application enforces its own rules.

Approval needs an object

A reviewer cannot meaningfully approve a vague promise to finish the job. Present the proposed action in an understandable form: which appointment, which recipient, which message and which version of the underlying request. Approval should apply to that proposal. If the proposal changes, the earlier decision should not silently cover the replacement.

This is an editorial design recommendation, not an implementation supplied by the cited agencies. It helps separate a human decision from model-generated narration. The cooperative can test it using two invented appointment revisions: approve one, replace the request, and confirm that the old approval cannot dispatch the new version.

The same distinction matters when an operator presses stop. A worker that has not dispatched anything should remain stopped. An operation that may already have reached another service needs reconciliation, rather than an automatic repeat designed to make the screen look complete.

Build a stop path outside the agent

The cooperative's proposed stop path has several layers. The application stops accepting new actions for the run. Workers check that state before a consequential dispatch. The service connection can be withdrawn independently of the model. The operator has a separate way to restrict the environment if the normal application is unavailable.

Those controls need to match the actual architecture. Closing a browser cannot be treated as proof that a remote worker stopped. Revoking a credential cannot undo an appointment already changed elsewhere. Conversely, an uncertain response does not establish that a change happened. The recovery display should distinguish known completion, known non-dispatch and an outcome still being checked.

A rehearsal should deliberately include an action waiting in a queue when stop is requested. Another should include a connection that fails after dispatch. The goal is to observe the boundary, not to demonstrate that the agent can explain the desired behaviour in prose.

Retain evidence without building a secret archive

Useful operational evidence includes a run identifier, the reviewed action, the decision, dispatch state and the external acknowledgement where one exists. Decide who may read that evidence and how long it is needed. Avoid copying private customer requests or reusable credentials into broadly accessible logs merely because detailed telemetry is available.

When the team reviews a stopped run, it should be able to connect a claimed action to an actual record. A fluent final summary is not that record. Missing evidence should remain a visible gap while an authorised operator checks the affected service. Recovery is a separate task with its own scope; it must not become permission for an agent to search unrelated accounts.

Standards work does not remove local decisions

The [NIST AI Agent Standards Initiative](https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative), created on 17 February 2026 and updated on 14 August, describes work on voluntary guidelines, interoperable protocols, identity infrastructure and security evaluations. That is relevant institutional work, not evidence that a universal agent-control standard has already solved a particular deployment.

For the cooperative, the decision remains local and testable. Does the application keep an untrusted note from changing scope? Can a reviewer see the exact proposed action? Does stop prevent the next dispatch? Can the team determine which earlier changes require recovery? A candidate that cannot answer those questions may still be useful for drafting, with a smaller operational role.

The benefit of a well-designed agent is a task completed within an understood boundary. More autonomy is valuable only where the organisation can support the resulting responsibility. A dependable interruption and recovery process gives operators a way to make that judgement from evidence.

This is defensive educational reporting, not a security certification or endorsement. The Accra cooperative is fictional, and no agent, connector or stop mechanism was executed for this article. Sources were checked on 15 October 2026.

Evidence diagram and readable guide


Original explanatory diagram: a separate stop control can interrupt dispatch; completed changes still require reconciliation.

[Open the complete evidence diagram](/assets/cyber-workflow-agent-stop-controls-20261015.svg)

Read the diagram

**Stop reaches the action boundary**

Solid arrows show the proposed task path. A dashed stop-control link can interrupt dispatch; it does not undo a completed change.

- **Permitted repair request.** Treat retrieved notes as task data, not new authority.

- **Bounded proposal.** Identify recipient, change and source revision.

- **Exact human approval.** Approve the concrete proposal before consequence.

- **Guarded dispatch.** Check current permission and stop state at the action boundary.

- **Stop and isolate.** Interrupt new work and relevant service connections.

- **Reconcile and recover.** Distinguish known completion, non-dispatch and unknown outcome.

The dashed control points into dispatch. Solid arrows carry the proposed task and recovery paths; stopping does not undo a completed change.

How the connections work

- Permitted repair request to Bounded proposal: flow; solid directed link. Proposed flow relationship; no measured causal effect.

- Bounded proposal to Exact human approval: flow; solid directed link. Proposed flow relationship; no measured causal effect.

- Exact human approval to Guarded dispatch: flow; solid directed link. Proposed flow relationship; no measured causal effect.

- Guarded dispatch to Reconcile and recover: evidence; solid directed link. Proposed evidence relationship; no measured causal effect.

- Stop and isolate to Guarded dispatch: interrupt; dashed directed link. Proposed interrupt relationship; no measured causal effect.

- Stop and isolate to Reconcile and recover: recovery; solid directed link. Proposed recovery relationship; no measured causal effect.

Keep the paths separate

Guarded dispatch and its separate stop control operate alongside one another; the enclosure does not add a task step.