The NCSC has written down what to check before you let an AI agent near your systems

On 20 August the National Cyber Security Centre published interim advice on agentic AI: software that does not simply answer a question but takes actions, calls tools and works through a task on its own. The NCSC is clear that this is not the finished article. Formal guidance is being developed with partners and will build on and ultimately supersede the blog post. It has published now because there have been several incidents involving AI models and agentic AI systems carrying out unsanctioned or unintended activity. The advice is written for the people designing and operating these systems. Read past that framing and it is also a list of questions any business should put to whoever is selling it a tool that can act on its behalf.

The line between a chatbot and an agent

A chatbot drafts the email and you press send. An agent has the mailbox. That is the whole difference, and it is why the NCSC has written about this at all. Once a system takes actions rather than suggesting them, the question stops being how good the answers are. It becomes what the thing can reach, what it will do if it reads an instruction the wrong way, and who notices when it does. The NCSC puts the point plainly: an AI agent is not human, it does not have common sense, and it may interpret instructions and goals in literal or unexpected ways.

Start with how much autonomy the job actually needs

The first recommendation is to size the controls to the autonomy. Some agents only make suggestions or carry out tightly constrained tasks. Others are trusted to take actions, reach production systems and make decisions with little or no human intervention. The greater the autonomy, the greater the potential impact if the agent malfunctions, reaches information it should not, or takes actions outside its intended scope, and the greater the need for controls. Being clear on how much freedom the task really requires, and how much risk you are willing to carry, is what tells you which controls are worth paying for and which are overkill.

Do not lean on the safety features that came with the product

Models and platforms ship with mechanisms designed to detect or prevent certain unwanted behaviour, and the NCSC's position is that these provide a baseline rather than the whole answer. They can be bypassed, and they may not manage risk adequately on their own in higher-risk settings. That matters commercially, because a version of 'the vendor handles all that' is the answer you will usually get when you ask about security. Better questions: which protections exist in this product, what do they not cover, and what does the supplier expect us to put in place ourselves.

Decide who stays in the loop

The advice sets out three models of oversight. Human in the loop, where a person approves actions before they happen. Human on the loop, where a person monitors and can intervene. Human out of the loop, where the system acts with no human review. Where unintended activity would carry significant consequences, the NCSC recommends naming an individual or group responsible for the agent's activity, keeping human oversight of what it does, using real-time monitoring alerts to catch unexpected behaviour, and watching the agent closely enough that it can be stopped. It also warns against relying on the prompt alone. How you word the instruction does shape what the agent does, but wording is not a control, and it needs pairing with technical and operational limits.

Blast radius: what it can reach is what it can break

The most portable idea in the whole document is the one the NCSC calls blast radius. Everything an agent can access or influence, directly or indirectly, sets the size of the problem when something goes wrong: what it can reach across the network, what it can run locally, what data it can see, and which credentials it holds. The recommendations that follow will look familiar to anyone who has been through a Cyber Essentials assessment. Give each agent its own identity, in a class that distinguishes it from human users. Restrict it to the permissions the task needs. Use credentials with the shortest workable lifetime, remembering that API keys, OAuth grants, SSH keys and any live authenticated session all count. Deny inbound and outbound network traffic by default and allow only what is required. The NCSC even sets out a four-level scale for network access, from unrestricted at level one, to an allowlist of approved domains, to the model's API only, to no external network access at all with the model hosted inside the sandbox.

Logs you can trust, and a plug you can pull

Two practical requirements close the advice out. The first is being able to see what the agent did: traces and transcripts from the agent itself, plus logs from the environment around it, stored where they cannot be quietly altered or deleted, and treated as part of normal security monitoring rather than a separate curiosity. The NCSC suggests running early experiments during office hours when people are about to watch, then extending to overnight or weekend running once you trust the controls. The second is emergency shutdown, which it describes as keeping the ability to pull the plug. That means more than closing the application. It means being able to cut network access to the agent's infrastructure and interrupt the traffic between the agent and the model quickly enough for it to matter.

What this looks like in a 20-person business

Very few firms this size are building AI agents. Plenty are being sold them, bundled inside a CRM, an accounts package, helpdesk software or a Microsoft 365 add-on, usually behind a single checkbox that grants access to a mailbox or a file store. Five questions cover most of what the NCSC is saying. What can this reach, and can that list be narrowed. Does it use its own account, or is it borrowing a member of staff's login. Where do we see a record of what it did. Who gets told when it does something unexpected. How do we turn it off in a hurry, and who here knows how. Clear answers to those five mean the risk is being managed. If the answer to most of them is that it is all handled at the supplier's end, that is precisely the gap the NCSC has spent a blog post describing.