The missing layer in the UK’s AI security plan: Agents

In this SJUK exclusive, Sunil Agrawal, CISO at Glean discusses why agents remain the missing layer in the UK’s AI security strategy.

The UK is taking a welcome leadership position on secure AI infrastructure.

The joint DSIT–NCSC call for information on secure AI infrastructure focuses on protecting model weights, high‑performance compute and the hardware stack that underpins frontier AI development.

That work is essential. But on its own, it will not stop the next generation of AI‑driven incidents.

By concentrating primarily on chips, clusters and model weights, current policy risks overlook where AI systems actually create business value and real‑world harm: The agent layer.

The layer where AI accesses data and take action on behalf of people and institutions.

This is where AI leaves the realm of research and starts to actually do things.

Anthropic showed that when agents can code, bad actors can trick them into believing they’re doing legitimate work, turning a chain of seemingly harmless steps into a serious security threat.

OpenClaw, a highly unpredictable agent network with broad permissions and access, illustrated the same danger – it could take real, uncontrolled actions without guardrails and was vulnerable to malware and data exfiltration.

If we look at the problem through numbers, Gartner predicts that by the end of 2026, 40% of enterprise applications will feature task-specific AI agents, up from less than 5% today, and that’s just the enterprise side, not the consumer flood that’s coming too.

For the UK to remain a trusted location for AI development and deployment, the agent layer must be protected as it becomes the primary way most people consume AI.

This layer is far more exposed to misuse compared to that of data centres and networks operated by a small number of highly trained professionals.

The emerging gap: Autonomous agents, unsecured

We’re about to see a surge in agents entering the market, meaning CIOs and CISOs are largely underprepared for what’s coming.

Recent research from BigID’s ‘AI Risk & Readiness in the Enterprise: 2025 Report’ highlighted the scale of the problem with the research finding:

• Nearly 69% of organisations cite AI‑powered data leaks as their top security concern
• Almost 47% have no AI‑specific security controls in place
• 6% report having an advanced AI security strategy

This is the capability–governance gap: AI agents are moving from experiments to production faster than security controls are being adapted to govern them.

If we extrapolate this trend into late 2026, it is easy to imagine a typical UK enterprise where:

• AI agents triage incidents for a security operations centre
• Draft responses to customers and citizens
• Reconcile financial transactions
• Orchestrate changes across cloud, on‑premise and OT environments

Yet those same organisations have no runtime monitoring for agent behaviour, no guardrails on what data agents can access and no ability to reconstruct what an agent actually did during a suspicious session.

This is not a theoretical concern.

These gaps are exactly what enable unintentional data overwrites or corruption when guardrails are weak, malicious or unsafe actions executed through code without properly scoped tools, trade-secret exfiltration via prompt injection and unbounded exploration where agents operate outside their intended action space.

Enterprises now have to design for these risks and strike the right balance, too much control slows progress, while too little creates serious security exposure.

What they need are clear frameworks to assess and design agent security, along with a practical checklist for evaluating AI vendors.

The UK government should adopt and adapt the same controls, creating a shared foundation that strengthens both enterprise and public-sector AI systems.

Creating practical frameworks

To help advise on the UK Secure Strategy and give enterprises a practical framework for protecting agents, we’re introducing AWARE.

It offers concrete guidance on how to understand the problem space and how to build viable, well-designed solutions.

When securing agents, you can’t focus only on the actions they access.

Agents are fundamentally different from traditional software as they reason, plan and behave more like humans.

They cannot be given open-ended control; they need clear scopes and boundaries to operate safely.

At the same time, not everything about agents is new.

We can reuse proven practices from software security including observability, risk scoring and other operational controls.

The good news is that we now have something previous eras of software never had – the ability to use agents themselves to help secure other agents.

That gives us far more tools, beyond traditional controls, to make agent-based systems both safe and effective.

AWARE framework

With that context in mind, I wanted to explain the AWARE framework and how it can be applied in the public sector for protecting the UK using illustrative examples:

A – Actor intent

• Agents must be treated as first‑class identities with clear ownership, roles and scopes, just like human users
• Example: A benefits appeals agent could be provisioned under the caseworker’s identity and limited to reading the appellant’s case file, consulting guidance and legislation, and drafting decisions in a staging area. It cannot access or act on other systems such as His Majesty’s Revenue and Customs (HMRC) tax records, National Health Service (NHS) patient data or immigration systems

W – Work context

• Traditional labels like “confidential” are no longer enough. Sensitivity must be determined in real-time, based on who is asking, what they are doing and where the result is going
• Example: An internal analytics agent at HMRC could read de-identified, approved datasets for modelling and dashboards. If a legacy spreadsheet with unmasked NI numbers and bank details is accidentally shared to an all-staff SharePoint site, its context-aware protection will flag it as highly sensitive and block the analyst from using it

A- Autonomous guardrails

• Agents hallucinate, drift and can be manipulated via prompt injection or tool‑abuse attacks. Organisations need runtime protection that inspects prompts, plans and actions, then blocking or quarantining behaviour that falls outside an agent’s declared purpose or violates policy
• Example: A National Health Service clinical decision-support agent could surface a patient’s history, medications, allergies and recent results, cross-reference National Institute for Health and Care Excellence guidelines and local care pathways, and suggest questions or risk factors for the clinician to document. Runtime guardrails ensure it can never write to the EHR; all orders, diagnoses and care-plan changes must be confirmed by a clinician

R – Real‑time risk scoring and blocking

• Not every agent invocation carries the same risk. Accessing public documentation is not the same as bulk exporting payroll data. Systems should continuously score the risk of an agent’s behaviour and automatically step up controls, from extra verification to hard blocks, when thresholds are exceeded
• Example: An agent in HM Treasury might run read-only queries on aggregated budget data and draft briefing notes, while a risk engine keeps the score low for routine analysis but raises it when the user requests sensitive pulls like line-item defence contracts or chained high-risk datasets. Once it crosses a threshold, the platform pauses the run and either requires second-person approval or hard-blocks the action and logs an incident

E – Ecosystem and observability

• Finally, security teams must be able to reconstruct what happened when something goes wrong. That means stitching together agent activity across chat, documents, tickets and APIs into a coherent trail that can support investigations, red‑teaming and regulatory reporting

A call to action for the UK

The DSIT–NCSC call for information explicitly seeks “defence‑in‑depth protection… with resilience to novel and adaptive threats” and invites ideas on how solutions can be evaluated, compared and assured.

To meet that ambition, I believe the UK should:

• Elevate the agent layer to first‑class status within the secure AI infrastructure programme, alongside chips, clusters and model weights
• Fund research, pilots and evaluation frameworks focused on agent behaviour, runtime controls and cross‑system observability in real environments.
• Collaborate with industry and standards bodies to codify frameworks like AWARE framework into practical guidance for regulators, auditors and critical‑infrastructure operators

The UK has already signalled its intent to be a trusted home for frontier AI development and deployment but the next step is to ensure that trust extends all the way up the stack to the agents that actually touch processes, people and critical services.

If we get this right, the UK will have AI systems that can be trusted to act autonomously in the national interest.