NCSC agentic AI guidance: the security controls expected of UK data controllers
In short: The NCSC agentic AI guidance, published on 15 May 2026, describes the security controls expected of organisations deploying AI agents: least privilege, limited scope, temporary credentials, monitoring, threat modelling and incident plans, with named individuals accountable. For UK data controllers it helps determine what UK GDPR Article 32 requires of them, and it matters for the automated decision-making safeguards under the Data (Use and Access) Act 2025.
The NCSC agentic AI guidance asks one question of every organisation deploying AI agents on its systems: can you understand, monitor and contain what the agent does? If the answer is no, the National Cyber Security Centre’s position is that the agent is not ready for deployment. For UK data controllers the same answer matters under Article 32 UK GDPR. An agent that can read personal data, call tools and act without continuous human review changes what appropriate security means, and the ICO now has a published set of controls to test it against.
What the NCSC has published
The NCSC published Thinking carefully before adopting agentic AI on 15 May 2026, summarising Careful adoption of agentic AI services, joint guidance co-authored with international partners and hosted by the Australian Cyber Security Centre. The NCSC defines agentic AI as systems that access data sources, remember context, make decisions, use tools and take actions in pursuit of a goal, operating without continuous human intervention and able to create sub-agents of their own.
The NCSC’s starting point is that agents inherit the known weaknesses of large language models, including jailbreaking and prompt injection. It then identifies four agent-specific risks: broader access to external systems, data and tools; unpredictable behaviour where goals are interpreted in ways a human would not expect; problems that surface faster than humans can review them; and actions that are harder to explain than non-agentic outputs. The NCSC tells organisations to start small, confine agents to low-risk tasks, apply established cyber security controls from the outset and maintain meaningful human oversight throughout. It points to ETSI EN 304 223 as the standard to apply when securing AI systems, and it puts the test plainly: “If you cannot understand, monitor or contain an agent’s actions, it is not ready for deployment”.
NCSC agentic AI guidance and the Article 32 security duty
Article 32 UK GDPR requires controllers and processors to implement technical and organisational measures appropriate to the risk, “taking into account the state of the art”. The NCSC agentic AI guidance now forms part of that state of the art for agentic deployments that touch personal data. Agentic AI security has a freely available reference point, and the ICO can judge a data controller’s measures against it.
Article 32 is a sliding scale, not a fixed checklist. What counts as appropriate moves with the threat environment and with published defensive practice. AI-driven attack capability has already raised the Article 32 standard on the attack side, a point developed in our analysis of AI cyber threats and Article 32 controller duties. The NCSC publication does the same on the deployment side. A data controller that gives an agent standing credentials and broad access to systems holding personal data, with no behavioural monitoring, will struggle to show its measures were appropriate to the risk when something goes wrong. The Article 32(1)(d) duty to regularly test, assess and evaluate the effectiveness of security measures covers the same ground as the NCSC’s monitoring and threat-modelling controls. The duty binds processors as well as controllers, which matters where a vendor operates the agent platform.
Each NCSC control has a UK GDPR counterpart:
| NCSC control | UK GDPR provision | What the data controller must show |
|---|---|---|
| Apply least privilege and limit scope | Article 32(1) appropriate technical and organisational measures | An access map per agent and per task, with minimum personal data exposure |
| Avoid long-lived credentials | Article 32(1)(b) ongoing confidentiality and integrity | Credential lifecycles, with elevated access revoked once a task completes |
| Monitor behaviour | Article 32(1)(d) regular testing, assessing and evaluating | Logs that can reconstruct what the agent did and why |
| Threat-model the deployment | Article 35 DPIA for high-risk processing | A DPIA covering misuse, manipulation and unexpected behaviour |
| Understand dependencies | Article 28 processor contracts | Contract terms binding every sub-agent and tool provider in the chain |
| Plan for incidents | Article 33 and Article 34 breach duties | A response plan covering agent failure, misuse and loss of control |
Human accountability and the DUAA automated decision-making regime
The NCSC insists that humans remain accountable for four things: the decision to deploy an agent, the access it was granted, the safeguards around it and the consequences of its operation, with a named owner who can stop it. Under UK GDPR Articles 22A to 22D, inserted by section 80 of the Data (Use and Access) Act 2025 (DUAA), that accountability carries statutory consequences.
Where any step in an agentic chain takes a decision based solely on automated processing, with legal or similarly significant effects for an individual, the automated decision-making regime applies and the Article 22C safeguards attach: human intervention, the right to make representations and the right to contest the decision. The NCSC’s requirement that responsible individuals are “empowered and incentivised to intervene” is the same idea as the meaningful human involvement test in the ICO’s draft automated decision-making guidance, whose consultation closed on 29 May 2026. A reviewer who lacks the authority, the information or the incentive to overrule an agent does not provide meaningful human involvement under either test. The test runs at each agent step in the chain, not only at the orchestrator’s final output, a point set out in our analysis of the ICO’s draft Article 22 guidance. The ICO flagged the same architecture in its Tech Futures report on agentic AI of 8 January 2026.
Implications for data controllers deploying AI agents
For a data controller, the NCSC’s recommendations turn into four documents: the DPIA, the access map, the Article 28 contracts and the incident plan. The threat-model control is, in data protection terms, the risk assessment a DPIA already demands for high-risk processing, extended to cover misuse, manipulation and behaviour the deployer did not anticipate. Runtime sub-agent selection complicates that risk assessment: a DPIA written for a fixed pipeline may not describe the chain that actually ran, so the assessment and the AI services agreements have to cover every sub-agent and tool the orchestrator is permitted to call.
Implementing the NCSC controls does not finish the data protection work. A deployment that implements all eight controls still needs a lawful basis under Article 6, and where an agent step crosses the automated decision-making threshold, the Article 22B conditions and Article 22C safeguards have to be in place before the agent goes live. Sector rules run in parallel: telecoms operators carry a network-security duty under the Telecommunications (Security) Act 2021, and payment service providers carry transaction-security duties under regulation 98 of the Payment Services Regulations 2017. Both apply alongside the deployer’s data protection obligations; neither replaces them. Our AI and data governance advice page covers the work of putting that package in place before a pilot goes live.
Viewpoint
The NCSC has made the Article 32 analysis easier. Article 32 is drafted as a sliding scale, and until now arguments about what is appropriate for agentic systems proceeded by analogy. There is now a published, internationally co-signed set of controls that an ICO investigator can rely on, and that a data controller can document its deployment against.
The NCSC asks who can stop the agent. The ICO’s draft guidance asks who reviews its decisions. In our experience advising data controllers on AI deployments, the hard part is rarely the model; it is the access the agent holds and the records showing who approved it, who monitors it and who can stop it.
Security is only part of the analysis. The NCSC controls help show Article 32 compliance; they do not supply a lawful basis, and they do not put the Article 22C safeguards in place where an agent takes solely automated significant decisions. The ICO’s Tech Futures report and its draft Article 22 guidance point the same way: the first question in any investigation will be who could stop the agent, and when.
Frequently asked questions
Does the NCSC agentic AI guidance create legal obligations?
No. The NCSC blog and the joint guidance are advisory. The legal obligation sits in UK GDPR Article 32, which requires security measures appropriate to the risk “taking into account the state of the art”. The NCSC agentic AI guidance describes the security controls a data controller is expected to apply when deploying AI agents over personal data.
Do AI agents trigger Article 22 UK GDPR?
Where any step in an agentic chain takes a decision based solely on automated processing, with legal or similarly significant effects for an individual, the Articles 22A to 22D regime applies, including the Article 22C safeguards of human intervention, representations and contest. The test runs at each agent step, not only at the final output of the orchestrator.
What security measures does the NCSC recommend for agentic AI?
Eight controls: least privilege, limited scope, no long-lived credentials, secure defaults, supply chain dependency management, behavioural monitoring, threat modelling and incident planning. The NCSC pairs them with named human accountability for the deployment decision, the access granted, the safeguards and the consequences, and a defined owner who can stop the agent.
For advice on agentic AI deployments, UK GDPR security compliance or automated decision-making safeguards, contact Rob Bratby at Bratby Law.
