AI agent identity and access control: how European enterprises should govern non-human identities

Estonian Prime Minister Kristen Michal recently approved a proposal from the country’s Eesti.ai advisory council to issue AI agents their own personal identification codes, digital identities separate from the humans, companies, or institutions they act for. His reasoning was blunt: “To do this, it must be clear who is acting, on whose behalf, with what rights, and who is responsible.” The proposal is not yet law, but the signal it sends is hard to miss. Non-human identity governance is moving from an engineering concern into a political and regulatory one, and European IT teams running agentic workloads cannot afford to wait for legislators to define the framework for them.

The Estonia announcement matters because it names a problem that most organisations are already living with. An AI agent that books a flight, files a tax return, or edits a document today typically has to borrow its owner’s entire digital identity to do it. That is not a quirk of early adoption; it is a structural gap in how cloud infrastructure was designed before agentic workloads existed at scale.

The scale of that gap is measurable. According to Entro Labs’ NHI and Secrets Risk Report for H1 2025, non-human identities now outnumber human identities in the average enterprise by 144 to 1, up from 92 to 1 a year earlier, a 56 percent increase in twelve months. Forty-seven percent of those non-human identities are more than a year old with no credential rotation. Sixty-two percent of AWS non-human identities showed no activity in the past 90 days, yet nearly 9 percent had access to services they never actually used. One in twenty AWS machine identities carries full administrative privileges. Two-thirds of enterprises have suffered a breach via a compromised non-human identity.

These are not theoretical risks. They are the predictable outcome of provisioning credentials the way teams provision compute: fast, permissive, and rarely reviewed. Agentic AI makes the problem structurally worse because agents are designed to act autonomously across multiple systems, which means a single over-privileged agent credential is not one exposure, it is a traversal path.

Seventy percent of organisations grant AI systems more access than they would give a human employee performing the exact same job. Only 44 percent have implemented any policies to manage their AI agents, despite 92 percent agreeing that governing them is critical to enterprise security.

What the regulatory stack already requires

NIS2 (Directive 2022/2555) came into effect on 17 October 2024 and is not waiting for Estonia’s proposal to mature. Article 21(2)(i) and (j) mandate access control policies, asset management, and the use of multi-factor or continuous authentication. The directive frames these requirements explicitly around a zero-trust model, which assumes that all users, non-human identities, third-party providers, and devices interacting with systems are potentially compromised. Least-privilege access is not a recommendation under NIS2; it is the stated underpinning of the required risk management measures.

The penalties are proportionate to how seriously the EU intends this to be taken. Essential entities, covering energy, transport, healthcare, and finance among others, face fines of up to 10 million euros or 2 percent of annual global turnover. Important entities face up to 7 million euros or 1.4 percent of turnover. Executives can face personal liability for negligence, forced publication of violations, and in some member states criminal sanctions. An estimated two-thirds of organisations operating in the EU remain non-compliant as of mid-2025, which means most teams reading this are running agentic workloads inside a regulatory gap that has already closed on paper.

NIS2 does not name AI agents explicitly, but its zero-trust framing is technology-neutral by design. Any credential that can act on a system is an identity that falls under access control policy obligations. If your agent can call an API, write to a database, or initiate a transaction, it is in scope.

A practical framework for AI agent identity management

The Estonia proposal is useful not as a regulatory instrument but as a design pattern. It describes exactly what a well-governed non-human identity looks like: a credential that encodes what the agent is allowed to view, what it can create or edit, and whether and to what limit it can initiate financial transactions. That is just scoped IAM, applied consistently to machine identities with the same rigour teams already apply to human ones.

Inventory before you govern

You cannot rotate, scope, or revoke credentials you have not catalogued. Start with a full inventory of non-human identities across your cloud environment: service accounts, API keys, OAuth tokens, workload certificates, and agent-specific credentials. Flag anything older than 90 days with no recent activity, anything with administrative scope, and anything whose owning team cannot be identified. That last category is frequently the largest.

Apply least privilege at provisioning time

The governance gap in most organisations is not that teams refuse to apply least privilege; it is that the default at provisioning time is permissive and tightening happens only after an incident. Reverse that default. Provision agent credentials with the minimum scope required for the defined task, document the justification, and require an explicit approval step to expand scope. An agent that summarises documents does not need write access to the database it reads from. An agent that monitors logs does not need the ability to modify infrastructure.

Rotate and expire on a schedule

Static, long-lived credentials are the single largest contributor to non-human identity risk. Forty-seven percent of NHIs carry credentials more than a year old with no rotation. Set maximum credential lifetimes at provisioning time, not as a remediation task. For agentic workloads on cloud infrastructure, short-lived tokens issued via workload identity federation are preferable to static API keys wherever the platform supports it.

Audit trails that name the agent, not the owner

This is the core insight behind Estonia’s proposal, and it applies directly to enterprise infrastructure today. If your audit log records that a human account performed an action because an agent borrowed that account’s credentials, your audit trail is useless for incident investigation and non-compliant with NIS2’s access control requirements. Agent credentials must be distinct, named, and traceable to a specific workload, owner, and purpose. When an agent acts, the log should show the agent acted, not the human whose token it inherited.

Build revocation into the deployment pipeline

Credential revocation is rarely tested until it is urgent. Build it into your standard deployment process: every agent credential should have a documented revocation procedure, a named owner responsible for executing it, and a tested path to disable it within minutes, not hours. NIS2’s 24-hour early warning and 72-hour incident notification timelines assume you can act quickly on a compromised identity. If you cannot revoke an agent credential in under an hour, you are not meeting the spirit of those requirements.

Running this on European infrastructure

We run agentic workloads for customers across our Munich (MUC1) and Madrid (MAD1) sites, both of which operate under ISO 27001 certification and full EU legal jurisdiction. When a customer’s AI agent calls our managed APIs, that call is logged against a named machine identity, not a shared service account. The IAM layer we expose through our Cloud platform is designed to support workload-specific credentials with defined scopes and short lifetimes, because that is what our own internal workloads require. We use NATS JetStream as our internal event-streaming backbone, and every service that publishes or consumes from it authenticates with a scoped credential tied to the specific workload, not a team-wide token.

Estonia’s proposal will take time to become law, and its enforcement scope remains undefined. But the problem it names is already inside your infrastructure. The teams that build clean non-human identity governance now, before NIS2 enforcement tightens and before agentic AI multiplies the credential surface further, will not be scrambling when the next directive arrives. The teams that wait will be doing triage instead of architecture.