Agentic AI Control Planes Need Data Protection Design Before Tool Access

AI Trust & Governance

18 August 2026 | By Ashley Marshall

Agentic AI is moving from interesting demos to systems that can touch real tools, records and workflows. The control plane now matters more than the model choice.

Agentic AI changes the risk model because it can act

The practical difference between a chatbot and an agent is not the branding. It is access. A chatbot can give a poor answer, leak a sensitive phrase into a response, or make a recommendation that needs human review. An agent can read a customer record, call an API, update a ticket, create a payment request, email a supplier or trigger a workflow. That makes the design question much sharper for UK leaders: what is this system allowed to touch, who approved that access, and how quickly can the business see and stop a bad action?

The National Cyber Security Centre's May 2026 guidance on adopting agentic AI is clear that these tools can plan, make decisions and take actions on an organisation's behalf. It recommends starting small, using agents only for low-risk tasks and applying established cyber security controls from the outset. That is not a warning against adoption. It is a warning against treating agentic AI as a normal SaaS rollout where users are added first and governance catches up later.

What this means in practice is that the first production artefact should not be a prompt library. It should be a control plane. That control plane needs an inventory of agents, approved tools, permitted data sets, authentication method, action limits, escalation rules, logging requirements and human owners. Without that, the organisation is relying on good intent and vendor defaults. With it, leaders can approve a bounded capability, see whether it behaves as expected, and expand only after evidence has accumulated.

Adoption is widening, but depth is still shallow

The UK adoption numbers make this moment awkward. The Office for National Statistics reported in July 2026 that self-reported AI use among UK businesses with 10 or more employees has risen from around 12% in late 2023 to around 35% in June 2026. That is a meaningful jump, but the same ONS release also found adoption is still relatively shallow: the average number of AI technologies used per adopting business has moved only modestly from about 1.4 to 1.6. In other words, many firms are past the curiosity stage, but not yet deep into operational integration.

That shallow adoption can create a false sense of safety. A business may have used generative AI for drafts, research, spreadsheet help or customer summaries without a major incident. Leaders then infer that the organisation is ready for agents. The problem is that the risk boundary moves as soon as the system is connected to tools. The same employee who was previously pasting a prompt into a chat window may now be approving a workflow that can search a CRM, summarise customer history and draft an outbound response. The technology has moved from advice into execution.

This is why a phased control plane is more useful than a blanket yes or no policy. A firm might allow an internal agent to classify support tickets, but block customer-visible replies. It might permit read-only CRM access, but prevent edits. It might allow supplier research, but prohibit purchase order creation. The counterargument is that such constraints slow productivity. They do, at first. But they also create the evidence needed to unlock wider automation later without asking the board to accept invisible operational risk.

Data protection depends on architecture, not policy wording

The Information Commissioner's Office has framed agentic AI as an architecture issue as much as a legal one. Its Tech Futures report on agentic AI says choices such as the data and tools a system can access, and the governance and control measures around it, materially affect how data protection law applies and how people exercise their rights. That matters because agentic systems are not just processing a static dataset. They may infer context from multiple sources, combine records, decide the next step and pass information to another tool.

For UK organisations, this makes the usual data protection questions more operational. What is the lawful basis for each category of personal data the agent can access? Is special category data excluded, masked or accidentally available through a connected system? Are controller and processor responsibilities clear where a vendor hosts the model, another provider supplies the agent framework and internal systems provide the data? If a customer asks what happened to their data, can the business reconstruct the agent's actions in language a human can understand?

A written AI policy helps, but it cannot compensate for open-ended access. The stronger approach is privacy by design at the control layer. Give agents task-specific scopes. Use retrieval filters that exclude unnecessary personal data. Separate test and production credentials. Keep logs of prompts, tool calls, retrieved documents, decisions and human approvals. Define retention periods for those logs. Most importantly, make stopping the agent an operational control rather than an emergency workaround known only to the technical team.

Standards are becoming procurement evidence

The UK's Digital Standards Strategy for 2026 to 2030 gives another signal for business buyers. GOV.UK describes digital standards as shared rules that provide guidance and confidence for businesses, investors and consumers, and says they can complement regulation by setting internationally agreed best practice. The strategy also notes that AI, cyber security, advanced connectivity, quantum, semiconductors and the internet are priority areas for UK action. For agentic AI, this shifts the procurement conversation from feature lists to evidence.

A buyer should not only ask whether a vendor has agents. They should ask whether the system can produce a usable evidence pack: security architecture, access model, data flow map, audit logging approach, incident response process, model and tool dependency list, and alignment with relevant standards or codes of practice. GOV.UK's strategy specifically references the ETSI EN 304 223 standard on cyber security for AI, shaped with UK government and NCSC input, and describes it as establishing baseline security requirements across the AI lifecycle. That is the kind of external reference procurement teams can use.

What this means in practice is that supplier questionnaires need to change. A generic question such as "do you use AI securely?" is no longer enough. Ask how agent identities are provisioned and revoked. Ask whether tool permissions are least privilege by default. Ask whether logs can be exported. Ask how the provider handles prompt injection, unsafe tool calls and compromised connectors. Ask which human roles can pause or terminate agent activity. These answers will separate mature platforms from impressive demos.

The control plane should be owned by the business

One common misconception is that agentic AI governance is mainly a technical administration problem. It is not. IT and security teams should help design the controls, but the owner of each agent must sit close to the business process it affects. A finance agent that checks invoices needs a finance owner. A sales operations agent that updates CRM stages needs a sales operations owner. A customer service agent that drafts responses needs a service owner. Those owners understand the consequences of a wrong action in a way a central platform team usually cannot.

The NCSC makes the accountability point directly: humans remain accountable for the decision to deploy an agent, the access it was granted, the safeguards around it and the consequences of its operation. That should translate into named roles before deployment. Who approves the agent's goal? Who approves each tool? Who reviews exception logs? Who signs off changes to prompts, models or connectors? Who has authority to pause the system during an incident? If those answers are vague, the organisation is not ready for production tool access.

The best operating model is deliberately ordinary. Put agents into the same governance rhythm as other operational systems: access reviews, change control, incident drills, supplier review, data protection assessment and performance monitoring. The difference is that agents need more granular visibility because their behaviour can vary by instruction, context and tool response. Treat the control plane as a management surface for business risk, not a dashboard for technical curiosity.

Start with boring controls before ambitious autonomy

The sensible path is not to block agentic AI until every uncertainty disappears. That would leave UK businesses learning too slowly while staff quietly experiment elsewhere. The better path is to start with boring controls and low-risk workflows. Pick tasks with clear inputs, reversible outputs and limited data sensitivity. Use read-only access first. Require human approval before external actions. Measure false positives, failed tool calls, escalation rate, time saved, user correction rate and incident near misses. Expand the agent's authority only when the evidence supports it.

There is a tempting counterargument: if the whole point of agentic AI is autonomy, why constrain it so tightly? The answer is that autonomy without evidence is not a capability, it is a bet. A bounded agent that reliably performs a narrow task is more valuable than a broad agent that needs constant supervision and creates uncertainty. The control plane is what lets a business turn narrow wins into wider deployment. It shows which constraints are still needed, which can be relaxed and which should become permanent policy.

For most UK firms, the next practical step is a 30-day agentic AI access review. List every agent, assistant, automation builder and AI-enabled SaaS feature that can access business data or perform actions. Classify each by data sensitivity, action authority, owner, logging, kill switch and supplier evidence. Anything that cannot be classified should stay out of production. That sounds cautious, but it is how organisations move from AI enthusiasm to operational confidence.

Frequently Asked Questions

What is an agentic AI control plane?

It is the management layer that defines which agents exist, what tools and data they can access, what actions they can take, how behaviour is logged, who owns them and how they can be paused or stopped.

Is this only relevant to large enterprises?

No. Smaller firms often have fewer formal controls, which can make tool-connected agents riskier. A lightweight register, read-only access and named owners are enough to start.

Can we rely on vendor permissions instead?

Vendor permissions help, but the business still needs its own view of purpose, data sensitivity, accountability, incident response and whether the vendor controls match the workflow risk.

What should be blocked first?

Block agents from payment actions, customer-visible messages, production record changes and broad personal data access until logging, approvals and rollback controls are proven.

How does this relate to UK GDPR?

UK GDPR questions depend on what personal data the agent can access, why it is processed, who controls it, how transparent the process is and whether people can exercise their rights.

Do we need a DPIA for every agent?

Not always, but any agent processing personal data at scale, making decisions about people, using sensitive data or connecting multiple systems should trigger a data protection impact assessment review.

What evidence should we ask AI vendors for?

Ask for data flow diagrams, access controls, audit log export, incident procedures, prompt injection mitigations, dependency lists, security testing evidence and any relevant standards alignment.

What is the safest first agentic AI use case?

Choose a narrow internal workflow with read-only access, low data sensitivity, reversible outputs and a human approval step before any external action.