Ask your AI supplier how long ‘stop’ takes

The screen has stopped. Has the work?

Picture a rehearsal using dummy client records. An assistant has read a provider document, queued a follow-up email and requested a CRM update. The operations manager presses stop. The chat goes quiet. The test is whether the email and update still happen.

That question has fresh urgency. In its September threat report, published on 10 September, Anthropic describes an attacker extracting production API keys from an AI vendor’s automated evaluation environment. The company says the stolen customer keys were then used in further intrusion attempts. It also says Anthropic’s own systems were not compromised.

This is the vendor’s account of an incident, not evidence that UK advice firms suffered the same attack. Our operating conclusion is narrower: an AI response plan should identify every credential and pending action involved in the workflow. A quiet interface is insufficient evidence that access has ended.

Three things to stop

For a provider-data assistant, separate three controls: stopping new instructions, cancelling work already handed to other systems, and removing the ability to act. Ask the supplier to show which component performs each job.

The first might be a pause in the assistant. The second could sit in an email queue or integration service. The third belongs wherever access is enforced: the provider connection, the CRM, the document store or an identity service. Those are questions about your actual design, not claims that every supplier uses this architecture.

The NCSC’s August guidance on agentic AI recommends emergency shutdown controls that cover the wider system, including network access and communications with model infrastructure. It also recommends separate agent identities, restricted credentials and permissions appropriate to the task.

For an advice-firm buyer, that suggests a useful procurement request: one diagram showing the identities used by the workflow, the systems each can reach, who can disable them, and which unrelated services would be affected. A shared credential deserves particular scrutiny. Disabling it may interrupt legitimate work too.

Put a clock beside the control

Revocation has its own timing. Microsoft’s Entra documentation explains that effective loss of user access can lag behind an administrator’s revocation action. Applications can issue their own session tokens, which Entra cannot directly revoke. It also describes continuous access evaluation for applications that support it.

That documentation concerns Entra user access. It does not establish how your AI supplier’s service credentials, provider portal or CRM behave. The practical lesson is to ask for the timing and scope of each connection’s shutdown, rather than treating an account-disable action as a universal answer.

In an authorised test environment, record when stop was requested, when each downstream service refused the next attempted action, and whether any queued action completed in between. Use dummy records and test destinations. Do not run the rehearsal against live client instructions.

Have the supplier distinguish work that was never started, work cancelled successfully, and work already committed. An email already delivered cannot be made unsent by disabling the assistant. A completed record change needs an identified correction process and a record of what happened.

Stopping creates a service queue

The strongest objection is practical: cutting every connection at the first anomaly could disrupt the very client service the automation was meant to improve. That is a reason to design narrower isolation and a recovery process, rather than leave shutdown behaviour untested.

Try a second version of the rehearsal. Stop only the suspect provider connection. Can staff still see which requests are outstanding, which data was received, and which records now need checking? Who takes ownership of the unfinished cases? This is a proposed acceptance test, not a measured result.

Before restarting, reconcile the external system’s result with the assistant’s record. If the CRM accepted an update before the connection failed, blindly repeating the job could create duplicate or conflicting work. Ask the supplier how it detects completed actions before retrying them.

Set the acceptable stopping interval for each action before the demonstration, based on what that action could expose or change. Record exceptions, owners and the conditions for restarting. Keep the evidence with the workflow’s operating instructions.

The next supplier meeting should end with two named responsibilities: who can contain the automation, and who picks up the client work it leaves behind.