The National Cyber Security Centre, the part of GCHQ that publishes guidance for the rest of us, put out two short pieces in May. The first was on securing agentic AI, written with the Five Eyes partners. The second was on zero trust network access, which the security industry calls ZTNA and which is largely what NCSC means when it says "stop using the corporate VPN as your security perimeter". Read together, the two share an idea. The user's location, and the network they are sitting on, stopped being useful evidence of who they are or what they should be allowed to do. Build the access decision out of something else.
This filing summarises both in plain English and pulls out the bits that matter for an SME.
The agentic AI guidance
Agentic AI, in the NCSC's framing, is the kind that does not just answer a question but takes an action on your behalf. Booking a meeting. Sending an email. Filing an invoice. Running a query against a database and acting on the result. The risk, in NCSC's words, is that "actions occur faster than humans can review them". The guidance is eight short practices, aligned with the European telecoms standard ETSI EN 304 223, that the NCSC and its Australian, Canadian, US, and New Zealand counterparts agreed on.
Boiled down, the eight are:
- Least privilege, minimum duration. The agent has access only to what it needs, only for as long as it needs it. If it needs to send an email, it does not also have permission to delete one.
- Scope-limit the agent's actions and its working window. It runs for the task and stops. Not all day. Not in the background.
- Temporary credentials, not long-lived ones. Tokens that expire, not API keys that sit in a config file for two years.
- Secure defaults in how the application is built. The default settings have to be the safe ones, not the convenient ones.
- Understand third-party dependencies and their supply chains. What the agent is built on, who maintains those parts, what else they reach.
- Monitor for unusual behaviour, continuously. Not "we'll check the logs next week". Now.
- Threat-model the misuse cases before deployment. Write down what could go wrong, who could trigger it, and how you would notice.
- Have an incident-response plan for when the agent fails or is abused. A plan for the new failure modes, not the old ones.
The NCSC's closing line is the bit to put on the wall. "If you cannot understand, monitor or contain an agent's actions, it is not ready for deployment."
For an SME, the practical reading is short. If you are letting an AI tool take actions in a customer-facing system, the question to answer in writing is what it can reach, what it can change, and what stops it. The eight practices are good headings for a one-page document the board can read.
The ZTNA guidance
The zero trust guidance covers the architectural side. The headline finding, in NCSC's words, is that "ZTNA tools are deployed in environments that still treat network location as a primary signal of trust". The kit gets bought. The legacy assumption stays. The result is that the firm has a new tool and the same problem.
The recommendations break into three useful chunks.
Decide the foundations first. The guidance is firm that "many ZTNA deployments fail, not because of missing technology features, but because legacy trust assumptions are carried forward". The work to do before the tool is selected: catalogue the applications, identify the users, decide what each user actually needs to do in each application, and write that down. Without this, the tool ends up enforcing the existing broad rules with extra steps.
Choose an architecture that fits. NCSC provides a reference model for accessing both private applications and SaaS platforms. The point of the reference model is to make the trade-offs visible. For most SMEs, the SaaS-heavy case is the relevant one. Almost everything the team uses, from Microsoft 365 to the CRM, is reached through the internet rather than over a VPN. The architecture should reflect that.
Make decisions on signals, not on location. "ZTNA decisions should always be shaped by an organisation's users, systems, threats, and operational constraints." Concrete signals include the user's identity, whether they have completed multi-factor authentication, whether the device meets a basic security baseline, and what they are trying to reach. The user being "on the office network" is no longer a signal worth much, because most users are not on the office network most of the time, and an attacker on the office network gets the same trust the user does.
For an SME the practical reading: if the IT story today is "we have a VPN, and people use it to get in from home", the question is whether that VPN is doing security work or just providing a tunnel. Most VPNs end up doing the latter while being assumed to do the former.
The shared thread
Both pieces of guidance assume the same thing about modern work. The user is not where the network expects them to be. The agent is not a user. The data is not in one place. None of the comfortable shortcuts work any longer.
The actionable form of this for an SME owner is short.
Stop treating the network as the boundary. The boundary is the identity and the device. If the identity is multi-factor authenticated and the device is broadly known and patched, the user can be anywhere. If either is not, no network location should rescue the access decision.
Stop treating an AI tool as a user. It is software that can act. The right model is the one you would use for a junior staff member with no supervision: tight permissions, narrow scope, supervised review of what it did, and the ability to switch it off if it goes wrong.
Write the permissions down before buying the tool. Both pieces of guidance say this in different words. The work to specify what should be allowed has to come before the work of buying the thing that will enforce it. Reversing the order produces a tool that enforces yesterday's bad rules with more steps.
Neither piece is long. Both are linked below. They are also the kind of document an owner-manager can read in twenty minutes and use as the basis for a real conversation with their IT provider.
How Steelwise can help
Translating these into a one-page agentic-AI policy, a ZTNA gap analysis against your current setup, or a short brief for an IT provider tender is the kind of work we do with clients. Get in touch.