Agentic AI regulation in the EU and UK exposes governance gaps

At a glance

What this is: This analysis says EU and UK regulation already touches agentic AI, but the governance model still lags the realities of autonomous action, logging, and accountability.

Why it matters: IAM, security, and governance teams need to treat agents as governed digital actors now, because regulatory expectations are moving toward evidence, scope control, and provable oversight.

Context

Agentic AI in the regulatory context means systems that can plan, act, and use tools with some independence from direct human prompting. The governance gap is not that regulation is absent, but that most current frameworks were built around stable, reviewable systems rather than runtime behaviour that can change within a session.

Zenity's argument is that this gap is already visible in the EU and UK. The EU AI Act, NIS2, DORA, GDPR, and emerging supervisory guidance all point toward accountability, logging, control boundaries, and evidence, but organisations still have to translate those requirements into agent-specific operating models.

That makes this a governance problem for IAM, privacy, and security teams at the same time. The article is not saying agents sit outside regulation; it is saying current control assumptions do not yet fully match how agents behave in production.

Key questions

Q: How should security teams govern agentic AI as it moves into production?

A: Security teams should govern agentic AI as a class of non-human identity, not as a generic application feature. That means assigning ownership, scoping permissions tightly, logging every tool action, and revoking access on a defined lifecycle. Production rollout should require clear approval points for high-risk actions and continuous monitoring for drift.

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: What breaks when human-in-the-loop control is the only safeguard for agents?

A: Human-in-the-loop control breaks down when approval happens after the agent has already inspected sensitive data, prepared side effects, or chained multiple tool calls. In that case, the review step only validates the final action and misses the broader sequence. Teams need guardrails before tool use, not just a sign-off at the end.

Q: What should organisations document when deploying vendor-hosted agentic AI?

A: They should document who controls instructions, logs, memory disablement, deletion support, incident investigation, and the evidence returned to the customer. Those ownership questions determine whether the organisation can prove accountability, satisfy privacy obligations, and explain incidents when the runtime is partly provider-managed.

Technical breakdown

Why agentic AI does not fit cleanly into current regulatory buckets

Current AI regulation tends to classify systems by role, risk, use case, and processing context, not by whether the system is agentic. That matters because many agentic systems are built on GPAI models, connected tool chains, and vendor-hosted orchestration layers that inherit obligations from several directions at once. The result is a patchwork of overlapping duties rather than a single, agent-specific rule set. For practitioners, the technical issue is not the label attached to the system but the combination of autonomy, data access, and action scope that the system actually has.

Practical implication: Map each agent to the regulatory duties triggered by its role, data use, and execution scope before deployment.

Logging, observability, and accountability for agentic workflows

Agentic systems create a reporting problem because teams must evidence not only what the system produced, but what it was able to do, what it actually did, and how its behaviour evolved during execution. That is a stronger requirement than traditional application logging. Execution observability covers actions taken, while intent observability is about whether behaviour stayed aligned with purpose. In practice, this pushes logging out of the application layer and into the control plane, where approvals, tool calls, memory changes, and state transitions can be reconstructed after the fact.

Practical implication: Design logs so they can support incident explanation, accountability review, and regulatory challenge.

Bounded autonomy and hard controls for agent action

The article draws a clear line between vague human oversight claims and enforceable autonomy limits. Agents need first-class identity, explicit owners, approved toolsets, bounded system reach, and defined data-access scope. Hard boundaries matter because soft guardrails can be reasoned around by the system itself. That is especially important where an agent can trigger irreversible actions, such as payments, deletion, or external communications. The architecture therefore has to constrain both what the agent can reach and which actions require human approval.

Practical implication: Use hard scope limits and approval boundaries for irreversible or externally binding agent actions.

NHI Mgmt Group analysis

Regulation has already reached agentic AI, but the control model has not caught up. The EU AI Act, GDPR, NIS2, and DORA already impose duties that touch agent behaviour, yet most governance programmes still treat agents as if they were ordinary software workflows. That mismatch leaves teams trying to apply static oversight to systems that can plan and act within a session. The implication is that agent governance has to be designed as a runtime control problem, not a policy overlay.

Execution observability and intent observability are the governance primitives that matter now. If a team cannot show what the agent was allowed to do, what it actually did, and whether it drifted from intent, it will struggle to satisfy accountability expectations under emerging supervision. Logging that only records outputs is too shallow for agentic systems. Practitioners should treat evidentiary logging as a core control plane requirement, not an audit afterthought.

Hard autonomy boundaries are more defensible than human-oversight claims that cannot be operationalised. The article's practical guidance shows that regulators are unlikely to accept broad assertions of control if an agent can still invoke tools, retain memory, or trigger write actions without clear limits. That means the decisive governance question is not whether humans are “in the loop”, but whether the system can be bounded, halted, and explained. Teams should reframe oversight around enforceable action limits.

Provider-deployer responsibility is becoming a shared accountability surface, not a vendor contract clause. When the runtime is partly provider-managed, the organisation still owns the regulatory outcome but may not fully control the evidence. That tension is now central to AI governance, privacy handling, and incident response. The named concept here is the accountability gap in vendor-hosted agentic AI, where control, evidence, and deletion rights are distributed across parties. Practitioners need to treat that gap as a design constraint.

Agentic AI governance is converging with broader identity and access discipline. The article effectively argues that an agent should be governed as a digital actor with identity, ownership, tool scope, and data reach. That aligns agentic oversight with IAM, PAM, and lifecycle governance rather than treating it as a standalone AI concern. The practical conclusion is that identity teams should lead the control model for agents, because the same questions apply: who can act, under what scope, for how long, and with what evidence.

From our research library:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Agentic AI identity governance is moving from concept to evidence. Teams that already rely on static credentials and vague approval gates will find that these controls do not explain what an agent can actually do in a live session. The governance shift is toward issuance-time scope, hard action boundaries, and proof of control rather than after-the-fact review.

Execution observability is becoming the minimum viable control for regulator-facing deployments. Security and privacy teams should expect to show who could act, what the agent touched, and how it was contained if behaviour drifted. The key question is no longer whether the agent is useful, but whether its autonomy can be bounded and evidenced under audit.

For practitioners

• Treat each agent as a governed digital actor Assign a first-class identity, a named owner, a defined purpose, an approved toolset, and a bounded system reach before allowing production use.
• Build evidence-grade logging Record what the agent could do, what it actually did, and which actions were gated, so incident review and regulatory challenge are both supportable.
• Constrain autonomous actions with hard boundaries Reserve human approval for irreversible, regulated, or externally binding actions such as payments, deletions, and public communications.
• Document provider-deployer responsibilities Clarify who controls instructions, logs, memory disablement, deletion support, and incident investigation when the orchestration layer is vendor-hosted.
• Test workflows, not only models Exercise tool selection, exception handling, retries, memory behaviour, bad inputs, and failure-to-stop scenarios before broad rollout.

Key takeaways

• Agentic AI regulation is already relevant in the EU and UK, but existing frameworks still leave a practical gap between policy language and runtime agent behaviour.
• The central governance challenge is proving control over agent actions, data access, and accountability when the system can plan and act inside a session.
• Practitioners should shift from soft oversight claims to hard boundaries, evidence-grade logging, and explicit provider-deployer responsibility.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Identity Observability: Identity observability is a continuous governance approach that correlates identity activity with business context, telemetry, and policy state. Instead of checking access at a single point in time, it tracks what an identity can do, what it did, and why that action matters to the business.
• Intent observability: The ability to capture why an AI agent chose a particular action path. This includes decision context, goal state, and reasoning trace, giving compliance and security teams a stronger basis for judging appropriateness and detecting manipulation.
• Provider-Depoyer Responsibility: Provider-deployer responsibility describes the shared accountability between the vendor running part of the agentic stack and the organisation deploying it. The practical issue is who controls instructions, logs, deletion, incident response, and evidence when runtime ownership is split.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.