Agentic AI regulation in the EU and UK exposes governance gaps

At a glance

What this is: This is an analysis of how EU and UK regulation applies to agentic AI, with the key finding that existing AI and cyber frameworks cover parts of the stack but do not yet fully address agent behaviour.

Why it matters: It matters because IAM, PAM, privacy, and governance teams now need to treat agents as governed digital actors, not just model outputs, across NHI, autonomous, and human oversight programmes.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Zenity's analysis of agentic AI governance under EU and UK regulations

Context

Agentic AI creates a governance problem because the subject is no longer just a model that produces outputs, but a digital actor that can plan, call tools, and trigger downstream actions. The article argues that the EU AI Act, ISO 42001, and NIST AI RMF all touch parts of the stack, yet none of them fully describe the operational control model many teams need for agentic AI governance.

For identity and access teams, the practical issue is not whether a framework mentions agents by name. It is whether current controls can prove who owned the agent, what it could reach, what data it touched, and which actions required human approval. That is why agentic AI regulation should be read as an identity governance problem as much as a model-risk problem.

The article treats the UK and EU as converging around accountability, logging, autonomy limits, and deployer responsibility. That starting point is typical for organisations trying to move from pilot deployments to governed production use, and it is where identity controls become the compliance evidence layer.

Key questions

Q: How should organisations govern agentic AI under EU and UK regulations?

A: Treat each agent as a governed digital actor with an owner, defined purpose, approved toolset, and explicit approval boundaries. Then map those controls to accountability, logging, privacy, and incident response requirements so you can show who controlled what, what data was touched, and which actions were authorised.

Q: Why do existing AI governance frameworks struggle with agentic systems?

A: They mostly describe models, risk categories, or high-level oversight, while agentic systems also need identity, permissions, tool access, and execution controls. The gap is not that frameworks are useless, but that they do not fully specify how an autonomous workflow is constrained, logged, and attributed in practice.

Q: How do security teams know whether an agent is operating inside its intended boundary?

A: They need evidence for both intent and execution. That means recording what the agent was supposed to do, what it actually did, what tools it called, and whether it deviated from the approved workflow. If you only measure the final outcome, you miss unsafe paths that still ended well.

Q: Who should be accountable when an AI agent causes a compliance issue?

A: Accountability should sit with the organisation that deploys and governs the agent, even when parts of the runtime are vendor-managed. Teams need to know who can disable memory, halt actions, investigate incidents, and produce logs, because those are the practical levers regulators will expect to see.

Technical breakdown

Why agentic AI falls between existing AI and cyber controls

Agentic systems sit between model governance and operational security. The model may be covered by AI risk frameworks, but the agent also has permissions, tools, memory, and execution paths that behave more like a digital actor than a static application. That creates a control gap: AI policy can describe intended behaviour, while identity and access controls govern actual reach. The article's core point is that regulation is starting to follow role, risk, and use case rather than architecture labels. For practitioners, that means the relevant boundary is not whether the system is called an agent, but whether it can independently invoke tools and affect the environment.

Practical implication: Map agent permissions, tool access, and approval gates as first-class governance objects, not as implementation details.

Autonomy limits, human oversight, and execution observability

Agentic governance depends on knowing where autonomy ends and accountable human intervention begins. The article distinguishes literal human-in-the-loop from bounded autonomy, which is the more realistic regulatory direction for high-volume systems. That makes logging more than audit retention. Teams need execution observability, meaning what the agent did, and intent observability, meaning whether the path it took matched the intended task. Without both, a team cannot prove that a safe outcome was reached through a safe process. This is especially important where agents can retry, branch, or continue after ambiguous intermediate states.

Practical implication: Define approval thresholds for irreversible actions and retain logs that show both intent and execution path.

Retrieval over retention for regulated data access

The article argues that private data handling should prefer retrieval over retention. In practical terms, that means the agent should fetch governed data from source systems when needed rather than absorbing it into durable memory or vendor-side improvement pipelines. This matters because GDPR obligations do not disappear when the data is processed by an agent. It also reduces the chance that personal data becomes embedded in persistent stores that are difficult to inspect or remove. For identity teams, the architectural question is whether access is time-bound, attributable, and reversible.

Practical implication: Keep personal and sensitive data in governed source systems and avoid designs that turn agent memory into a shadow repository.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic AI regulation is becoming an identity governance problem, not only an AI policy problem. The article makes clear that current frameworks cover pieces of the stack, but the real control question is who controls the agent, what it can invoke, and what evidence exists when it acts. That shifts the burden from model description to governed execution. For practitioners, the field needs identity-native evidence for agent ownership, reach, and approval scope.

Autonomy breaks the assumption that human-paced review can contain machine-paced action. Access review was designed for stable access that persists long enough to be observed and certified. That assumption fails when an agent can acquire, use, and release authority across dynamic tool chains as part of a single workflow. The implication is that governance built around periodic review no longer matches the behaviour it is meant to govern.

Execution observability is the new compliance boundary for agents. The article's focus on what the agent was allowed to do, what it actually did, and what it is currently doing shows where evidence now matters. Logs that only record end-state success do not satisfy accountability when regulated or externally binding actions are involved. For identity programmes, observability has to be tied to authorization and action lineage, not only telemetry volume.

Retrieval architectures are more compatible with regulated agent use than durable memory designs. Persistent retention increases the chance that personal or sensitive data becomes difficult to isolate, explain, or remove. The article's GDPR discussion points to a structural preference for governed retrieval from source systems over broad memory accumulation. Practitioners should treat that as an architectural boundary, not a tuning preference.

Provider-deployer accountability will keep pushing identity teams into executive governance. The regulatory direction described in the article makes it harder to treat agent permissions as a technical implementation issue owned only by engineering. If the organisation cannot answer who can halt actions, who owns logs, and who receives evidence, it will struggle to defend its governance posture. Identity leaders should expect agent governance to become a board-level control conversation.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• In the 2024 ESG Report, 72% of organisations said they have experienced or suspect they have experienced a breach of non-human identities.
• For the governance angle that follows from that exposure pressure, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the lifecycle controls that reduce standing access risk.

What this signals

Agentic governance will converge with NHI governance faster than many programmes expect. Once an agent has a first-class identity, an owner, and a bounded toolset, the practical control stack starts to look like workload identity, privilege governance, and lifecycle management rather than model oversight alone. Teams that already manage service accounts and secrets are closer to the required operating model than teams starting from policy documents only.

With more than 1 in 5 non-human identities believed to be insufficiently secured, according to our 2024 ESG Report: Managing Non-Human Identities, the pressure on identity programmes is already structural. Agentic systems add another class of governed digital actor that must be owned, scoped, logged, and retired like any other credential-bearing identity.

Execution observability will become a buying criterion, not an optional feature. If a platform cannot show what an agent was allowed to do, what it actually did, and where approval gates existed, it will be difficult to defend in audit or incident review. That is why the market is shifting toward controls that expose runtime behaviour, not just model outputs.

For practitioners

• Define first-class agent identities Assign each agent an owner, purpose, approved toolset, and bounded data-access scope before it enters production. Treat those fields as control requirements, not documentation fields, so they can be reviewed alongside business risk and regulatory exposure.
• Separate approved actions from autonomous reach Document which actions an agent may take without human approval and which actions require a gate before execution. Keep irreversible, regulated, or externally binding actions behind explicit approval points.
• Build execution and intent observability Capture what the agent was allowed to do, what it actually did, and whether its runtime behaviour matched the intended workflow. Use those records to support incident review, audit response, and accountability questions from regulators.
• Prefer retrieval over retention for sensitive data Keep personal and regulated data in source systems and have the agent retrieve it on demand rather than absorbing it into durable memory or vendor-side improvement pipelines. That reduces long-lived exposure and makes deletion and explanation easier.
• Create kill switches for tools and write actions Make it possible to disable a single connector, a single agent, or all autonomous write actions without shutting down the full platform. That containment path should preserve evidence and support a safer degraded mode.

Key takeaways

• Agentic AI creates a governance gap because current AI frameworks do not fully capture identity, permission, and runtime control requirements.
• Regulatory pressure is moving toward accountability, logging, and bounded autonomy, which makes identity evidence central to compliance.
• Practitioners should treat agents as governed digital actors and build controls that show ownership, scope, and intervention capability.

Key terms

• Agentic AI: An agentic AI system is a digital actor that can plan, choose tools, and take actions within a runtime environment. Unlike a passive model, it has operational consequences because its behaviour is tied to permissions, data access, and approval boundaries that must be governed like identity.
• Execution Observability: Execution observability is the ability to show what an agent was authorised to do, what it actually did, and how its runtime decisions unfolded. For autonomous or agentic systems, this is not just telemetry. It is the evidence layer that supports audit, incident review, and accountability.
• Retrieval over Retention: Retrieval over retention is an architectural pattern where an agent fetches governed data from source systems when needed instead of storing it in durable memory or vendor-side pipelines. It reduces long-lived exposure, limits privacy risk, and makes deletion and explanation more tractable.
• Bounded Autonomy: Bounded autonomy means a system can act independently within defined limits, but cannot exceed those limits without human or policy control. In agentic governance, the boundary must be explicit, testable, and logged, because the real compliance question is where autonomous action stops.

Deepen your knowledge

Agentic AI governance under EU and UK regulation is covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agent identities, autonomy limits, and evidence trails, it is worth exploring.

This post draws on content published by Zenity: Build for Tomorrow, Today: Deploying Agentic AI Under EU and UK Regulations. Read the original.