NCSC's Agentic AI Security Guidance

If you've already decided an AI agent, something that can take actions on your systems rather than just answer questions, is worth exploring for your business, the next question is how to actually roll one out without creating a security problem you didn't have before.

Why an agent is a different risk to a chatbot

An AI chatbot that answers customer questions carries a content risk. An AI agent that can access data sources, remember context across a task, use tools, and take actions toward a goal without waiting for a human to approve each step carries an access risk as well. The NCSC's own guidance on agentic AI adoption is explicit about this: agents can be granted broader access to external systems, data, and tools than a non-agentic AI system would ever need, and their behaviour can be unpredictable, particularly when a goal is interpreted in a way a human wouldn't expect.

What this looks like for a real business

An IT lead at a 30-person accounting firm considering an AI agent that could access client files and file tax returns automatically is exactly the scenario the guidance is written for. The instinct might be to give the agent broad access from the start so it can genuinely save time. The NCSC's recommendation runs the other way: start with a narrow, low-risk, reversible task, such as drafting a document for human review, rather than giving the agent write access to the firm's actual tax filing system on day one.

The reasoning is practical, not theoretical. If an agent with narrow, reversible permissions makes a mistake, the fix is straightforward. If an agent with broad, unsupervised access to a live filing system makes the same kind of mistake, the consequences are much harder to undo, and by the time a human notices, the action may already be complete.

The three principles that matter most for a small business

Start small: pilot agentic AI on tasks where a mistake is low-consequence and easily reversed, not on your most critical or sensitive process first. Apply existing controls from the outset: the access controls, logging, and governance your business already applies to staff and other software should apply to an AI agent from day one, not be added later once it's already operating. Plan for failure: have an actual answer, before deployment, to "what happens if this agent gets it wrong," including how you'd detect the mistake and how quickly you could reverse it.

Why this matters even for a business not using agents yet

Agentic features are increasingly bundled into mainstream business software rather than something a business has to deliberately seek out. A scheduling tool, an email client, or an accounting platform can quietly add an "agent mode" as a feature update. The practical implication is that a business should know whether any tool it already uses has agentic capabilities switched on, rather than assuming agentic AI is only a risk once it's actively been adopted on purpose.

Why logging and reversibility matter more than the AI model itself

A recurring theme in the guidance is that the specific AI model behind an agent matters less than the structure around it. Two businesses using the same underlying model can have very different risk profiles depending on what access that agent was actually granted, whether its actions are logged in a way a human can review, and whether those actions can genuinely be undone if something goes wrong.

For a small business, this reframes the useful question. It's less "is this AI model good enough" and more "if this agent does something we didn't expect, would we notice, and could we reverse it." A business that can answer both of those clearly is in a fundamentally safer position than one that has simply picked a well-known AI provider and assumed that alone is sufficient protection.

What you can do about it

Three practical steps: check whether any software your business already uses has agentic features enabled, and understand what access those features actually have; if piloting a new AI agent, start with a genuinely low-risk, reversible task rather than a critical process; and write down, even briefly, what you'd do if the agent acted incorrectly, before it happens rather than after.

This is general security guidance, not an endorsement or rejection of any specific product. Confirm your own risk approach with the NCSC's published guidance or a qualified IT security adviser before deploying an AI agent against a critical system.

FAQ

Related reading: our AI governance by region.

Try our free AI Compliance Checker to check whether your AI tools meet your compliance obligations.

What's the difference between an AI chatbot and an AI agent?

A chatbot generates a response for a human to read and act on. An agent can take actions itself, access systems, use tools, and pursue a goal across multiple steps without waiting for approval at each one. That broader capability is what creates the additional security risk.

Should a small business avoid agentic AI altogether?

The NCSC's guidance doesn't recommend avoiding it, it recommends adopting it carefully: starting with low-risk, reversible tasks, applying existing security controls from the outset, and having a plan for what happens if the agent gets something wrong.

How do I know if a tool I already use has agentic features?

Check the vendor's recent release notes or settings for anything described as "agent," "autopilot," or "automated actions," and confirm what access that feature actually has before assuming it's just a bigger chatbot.

What access should an AI agent never be given?

The NCSC's guidance is explicit that an agent should never be granted unrestricted access to sensitive data or critical systems. Any access granted should be scoped as narrowly as the task genuinely requires.