Agentic AI Needs an Emergency Stop Button, and Most Organisations Don’t Have One

On 20 August 2026, the UK’s National Cyber Security Centre published interim guidance for organisations deploying autonomous AI agents. The trigger was blunt. Several recent incidents in which AI models and agentic systems carried out unsanctioned or unintended activity, serious enough that the NCSC judged it could not wait for its formal guidance programme to catch up. 

The advice itself is not theoretical. The NCSC recommends a four-level maturity model for sandboxing agents, a distinct identity and short-lived, task-scoped credentials for every agent, mandatory logging and monitoring of agent activity inside security operations, and a tested ability to shut an agent down the moment something goes wrong. Read together, those four requirements describe an organisation that does not yet exist inside most large UK enterprises, or most public sector bodies either. 

Security programmes are struggling to adapt 

This is not a UK-only concern, and the NCSC did not arrive here alone. Five Eyes cyber security agencies issued a joint warning in June 2026 that the shape of cyber risk is changing faster than most security programmes can adapt, largely because of AI. The concern is speed as much as scale. Mandiant’s M-Trends 2026 report found that the median time between an initial access broker gaining a foothold and handing that access to a secondary group fell from more than eight hours in 2022 to just twenty-two seconds in 2025. An agent that can act at that speed, holding standing credentials with no supervised stop mechanism, is not a productivity tool. It is an unsupervised actor carrying a badge that never expires. 

Most organisations still treat agent oversight as a settings problem: a system prompt telling the model what it should and should not do, sitting behind a vendor’s built-in safety filter. The NCSC is explicit that this is not sufficient on its own. Model-level safeguards, in its own words, can be bypassed, may not hold up in higher-risk environments, and should never be relied on in isolation. 

A widening gap 

The gap between what boards assume is in place and what is actually operational is wide. Kiteworks Data Security and Compliance Risk: 2026 Forecast Report found that just 21% of organisations have deployed an automated capability to terminate a misbehaving AI agent, meaning 79% have no such mechanism at all. Among organisations already running AI in production, the report separately found that 23% have never once tested whatever agent-termination capability they do have. An emergency stop that has never been tested under real conditions is not a control. It is an assumption, and assumptions tend to be discovered as such during an incident rather than before one. 

That distinction matters more once agentic AI is understood as an identity problem rather than a model problem. The NCSC’s guidance calls for every agent to hold its own distinct identity, separate from any human user, with short-lived, task-scoped credentials rather than standing access. That recommendation answers a pattern security teams already recognise. Agents routed through infrastructure built for people, inheriting the access and the blast radius of whatever account happened to launch them. 

Three things need to change 

Three things need to change, and none of them require waiting for the NCSC’s formal guidance, which it has said remains in development. 

Sandboxing must move from an afterthought to a graded, tested architecture. The NCSC’s four-level maturity model, running from unrestricted network access at level one to no external network access at all at level four, gives security and engineering teams a shared vocabulary for a conversation that has, until now, mostly happened informally between a project team and a vendor’s default settings. 

Logging is the second lever, and it is one that compliance and privacy functions should own rather than delegate entirely to engineering. The guidance calls for agentic activity to be treated as a form of user activity, folded into round-the-clock security operations, with chain-of-thought traces, sandbox access logs and network telemetry preserved as evidence rather than as debugging output that gets discarded. For a chief compliance officer or data protection officer, that reframing has teeth. Under UK GDPR’s accountability principle, an agent’s action is a data-processing event like any other, and it needs an audit trail that can be produced on demand, not reconstructed under pressure once a regulator or an assessor has already asked the question. The EU AI Act is heading the same way. Its logging and human oversight duties for high-risk systems were due to bite this August, before Brussels pushed the deadline for those specific obligations back to December 2027. The direction of travel has not changed. Only the date has. 

Accountability is the third, and the hardest to assign cleanly. The NCSC’s recommendation that named individuals or a named group be made responsible for agentic AI activity is easy to write into a policy document and hard to enforce when an agent’s actions cut across IT, security, legal and whichever business unit deployed it. Boards that cannot currently name who owns that accountability are not unusual. They are, for now, the majority. That will not last, because the alternative is explaining after an incident why no one had been asked the question beforehand. 

A concrete theory 

None of this is complicated to state. Give every agent its own identity. Cut its credentials down to the task in front of it. Log everything it touches, and keep that log intact enough to survive an audit. Prove, through an actual drill and not a slide describing one, that someone can pull the plug. Organisations that can answer all four of those today are rare. 

The NCSC did not publish this guidance because agentic AI is risky in theory. It published it because, somewhere in the past few months, an agent had already made the theory concrete.