Estonia’s AI agent identity proposal shifts autonomy governance

At a glance

What this is: Estonia is considering official digital identities for AI agents so automated systems can act with limited, verifiable, and auditable authority.

Why it matters: It matters because IAM, NHI, and human governance teams will need to separate person, organisation, and agent authority while preserving accountability and least privilege.

👉 Read SumSub's coverage of Estonia's AI agent digital identity proposal

Context

AI agent identity is moving from theory to governance design. Estonia's proposal treats an agent as a distinct actor that can be granted narrow rights, rather than as an extension of the person or organisation that deploys it, which is the right starting point for identity control when software can make runtime decisions.

The governance gap is not authentication alone. Once an agent can view data, prepare documents, or initiate payments, existing IAM models that assume a stable human operator or a static service account start to blur responsibility, access scope, and auditability at the same time.

For identity teams, the question is whether current control sets can describe and constrain agent behaviour without collapsing it back into the owner's account. That is an autonomy problem, an NHI problem, and a lifecycle problem at once.

Key questions

Q: How should security teams govern AI agents that act on behalf of users?

A: They should treat each agent as a distinct identity with its own scope, expiry, and owner, rather than as an extension of the user account. The critical controls are delegated rights, provenance, and revocation. If the agent can initiate actions independently, governance has to follow the agent identity through its full lifecycle, not just the human who requested it.

Q: Why do AI agents complicate least privilege in IAM?

A: Because the actor can make runtime decisions inside a granted scope, least privilege is no longer only a provisioning problem. Teams must define task boundaries, data boundaries, and transaction limits up front, then enforce expiry and revocation when the task ends. Otherwise, broad standing access reappears under a new label.

Q: What breaks when an agent identity is reused across multiple workflows?

A: Reused identities collapse separation of purpose and widen blast radius. Audit logs become harder to interpret, revocation becomes ambiguous, and one workflow can inherit trust that belonged to another. A reusable agent identity should be the exception, not the default, because it weakens both accountability and containment.

Q: Who is accountable when an authorised AI agent causes financial loss or data misuse?

A: Accountability should follow the delegation record, not the tool alone. Security, legal, and business owners need to know who authorised the agent, what it was allowed to do, and whether the agent stayed inside that scope. If those answers are missing, responsibility will be disputed even when the activity is fully logged.

Technical breakdown

Why AI agent digital identity is different from a service account

A service account usually exists to run a predefined workload with known permissions and predictable timing. An AI agent can be granted narrower authority than a person, but it may still select actions dynamically, combine tools, and decide when to act within that scope. That makes the identity problem less about simple authentication and more about whether the actor's runtime behaviour stays inside a bounded delegation model. The key architectural shift is separating the principal from the agented action so that approvals, logs, and revocation all attach to the agent identity rather than the human owner.

Practical implication: Treat agent identity as a first-class subject in IAM and lifecycle systems, not as an attribute attached to the owner's account.

Auditable authority depends on explicit delegation boundaries

The Estonian proposal points toward limited authority with clear rights, which is how agent governance has to work if the system is to remain reviewable. In practice, delegation needs to encode task scope, data scope, payment limits, and expiry conditions, then preserve a durable record of who authorised the agent and for what purpose. Without that, logs show activity but not accountable delegation, which is the difference between traceability and governance. This is where NHI controls intersect with human identity controls, because the person still authorises the action while the agent executes it.

Practical implication: Model delegation as a governed lifecycle event with scope, expiry, and owner provenance, not as a one-time permissions grant.

The control problem is not access grant alone, but revocation and reuse

When an agent can perform limited tasks on behalf of a user or business, the real test is what happens after the task ends or the relationship changes. If the agent identity persists, stale authority becomes reusable and audit trails lose meaning. If the agent identity is too generic, multiple workflows share the same trust boundary and blast radius expands. This is why agent identity management has to align with NHI lifecycle principles, including issuance, rotation of credentials or tokens where relevant, and offboarding when delegated authority expires.

Practical implication: Tie agent identities to lifecycle controls that expire, revoke, and reissue authority cleanly when tasks or relationships change.

NHI Mgmt Group analysis

AI agent identity is becoming a governance category, not just an implementation detail. Estonia's proposal shows that organisations are beginning to recognise agents as distinct actors with bounded authority rather than extensions of the person or system that launched them. That distinction matters because access reviews, audit trails, and accountability all behave differently once the executor is software that can act independently within approved limits. Practitioners should treat agent identity as a separate governance object, not as a UI layer on top of human IAM.

Least privilege for AI agents is only credible when authority is task-bound and time-bound. The proposal is useful precisely because it avoids giving an agent the same unrestricted access as the owner. That maps to an NHI governance principle: rights must be narrow enough to describe the task and short-lived enough to expire when the task ends. Practitioners should expect agent programmes to fail if they rely on broad standing entitlements dressed up as convenience.

Access review processes were designed for stable identities, not ephemeral delegated actors. This assumption fails when the actor is autonomous because the agent can acquire, use, and discard authority faster than a recertification cycle can observe. The implication is not merely that access reviews need automation, but that the review model itself must be rethought for runtime delegation and session-scoped action. Practitioners should stop assuming a certifiable state will still exist when the review happens.

Digital identity for agents will expose gaps between human accountability and machine execution. Estonia's question is not whether an agent can be identified, but who is responsible when an authorised agent causes loss or mishandles data. That forces IAM, PAM, and legal ownership to line up with the same delegation record, which is where many current programmes are weakest. Practitioners should expect accountability mapping to become a core control, not an afterthought.

Identity blast radius becomes the real design constraint once agents can spend, sign, or submit on behalf of others. A limited agent identity only works if every permission is intentionally scoped to a single purpose and can be revoked without collateral access loss. The field will move toward narrower delegation, richer provenance, and stronger offboarding semantics because broad shared authority no longer scales cleanly. Practitioners should design for containment first.

From our research:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to GitGuardian and CyberArk.
• For a broader control model, review NHI Lifecycle Management Guide for issuance, rotation, and offboarding patterns that apply when agent authority must remain bounded.

What this signals

Delegated AI identity will force IAM teams to stop treating runtime authority as an edge case. When agents can act for a person, the control plane has to track purpose, expiry, and provenance as core fields, not metadata. The practical shift is toward more explicit delegation records and less tolerance for shared credentials or opaque background automation.

Agent governance will converge with NHI lifecycle management. The same lifecycle discipline that governs service accounts now has to govern agents that can sign, pay, or submit on behalf of others. Teams should map agent issuance, review, and offboarding to the NHI Lifecycle Management Guide and align the policy model to OWASP Agentic AI Top 10 where runtime tool use is in scope.

Identity programmes should prepare for accountability drift. The hard part is not proving that an agent acted, but proving who authorised the act and whether the authority was still valid. That is where owner provenance, approval records, and revocation state will become the evidence set that auditors and incident responders ask for first.

For practitioners

• Define agent identities as separate principals Create a distinct identity object for each AI agent, with its own owner, purpose, scope, and expiry rather than reusing the human user's account.
• Bind delegated rights to task scope Limit each agent to the exact data, actions, and transaction bounds required for one approved workflow, then expire those rights when the workflow closes.
• Record provenance for every delegation event Capture who authorised the agent, what it was allowed to do, and which business context justified the grant so auditors can reconstruct responsibility later.
• Plan offboarding before deployment Define how agent credentials, tokens, and approvals will be revoked when the user relationship changes, the task ends, or the model is repurposed.

Key takeaways

• Estonia's proposal shows that AI agents are moving into the identity layer as bounded actors that need their own governance record.
• The central risk is not simply access expansion, but the loss of clear responsibility when machine execution and human approval separate.
• Identity teams should prepare for agent lifecycle controls, explicit delegation scope, and revocation semantics before autonomous authority becomes normalised.

Key terms

• AI Agent Identity: A distinct identity assigned to a software actor that can act on behalf of a person or organisation. The identity carries its own scope, ownership, and lifecycle so that permissions, logs, and revocation can be governed separately from the human user.
• Delegated Authority: Permission that allows one identity to perform actions on behalf of another under defined limits. In identity governance, delegated authority should be bounded by purpose, duration, and accountability so that the delegate cannot outlive the approval that created it.
• Identity Blast Radius: The amount of access, data, and operational impact exposed if one identity is misused or compromised. In AI agent governance, blast radius is shaped by task scope, token reuse, and how easily the delegated identity can be revoked or reused elsewhere.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by SumSub: Estonia backs digital ID system for AI agents. Read the original.