Estonia intends to issue official digital identities, "AI ID codes", to AI agents. The office of Prime Minister Kristen Michal says the goal is to let AI "act on behalf of people, companies or organisations within clearly defined limits and in a manner that is both verifiable and auditable." If it ships, Estonia becomes the first country to give AI agents a state-recognised identity. That is a genuinely useful move, and it is also the easy part. The hard part is everything the ID is supposed to carry.

I build with agents that hold real credentials, so my reaction is less "is this dystopian" and more "what does the ID actually have to bind." An identifier on its own is a number. What makes it matter is what you attach to it: authority, a delegation chain, and accountability. Get those wrong and you have shipped a very official-looking primary key.

What Estonia actually announced

The plan is to assign each agent an identifier whose purpose is twofold: identification, and limiting the scope of what the agent is allowed to do. The framing from Michal's office is the right one: "it must be clear who is acting on whose behalf with what rights, and who is ultimately responsible." Philipp Pointner, chief of digital identity at Jumio, called it a precedent for "how we must audit what agents can do on behalf of an individual," and stressed that identity systems now have to distinguish between human identity and agent authority.

That distinction is the whole ballgame. A human identity answers "who are you." An agent ID has to answer a harder question: "who let you, to do what, and for how long."

Why this is not just bureaucracy

If you have wired an LLM up to tools, you already know the current state of the art is borrowed credentials. The agent runs as a service account, or worse, with a human's OAuth token and a long-lived API key copied into an environment variable. Human-centric IAM was built around a person who logs in occasionally, clicks a consent screen, and acts at human speed. An agent logs in never, was handed its access by someone else, and acts thousands of times a minute.

So when an agent does something wrong, the logs say a service account did it, or that a human did it, because that is whose token was on the request. The action is real and the accountability is fiction. Estonia's instinct, give the agent its own identity so its actions are attributable to it and traceable back to whoever authorised it, is exactly the gap that needs closing. The instinct is right. The implementation is where it gets expensive.

The three things an agent ID has to carry

1. Scoped authority, not just a name

An ID that proves "this is agent X" and nothing else is a nametag. The value is in the permissions bound to it: which systems, which operations, which data, under what conditions, with what spending or rate limits. This is the part the press release waves at with "clearly defined limits" and the part that takes years to get right, because scope that is too broad recreates the original problem and scope that is too narrow makes the agent useless. We have primitives for this already, OAuth scopes, workload identity, capability tokens, but a national ID layer has to interoperate with them, not sit on top as a fourth competing source of truth.

2. A delegation chain you can actually follow

"Who is acting on whose behalf" is not one hop. A person authorises an agent, the agent calls a tool, the tool spawns a sub-agent, the sub-agent hits a third-party API. Each step narrows or should narrow the authority. If the ID does not capture the chain, you get the classic confused-deputy problem at machine speed: a component with legitimate access is tricked into using it for someone else's purpose, and the audit log shows a clean, authorised call. An agent ID is only as good as its ability to record and constrain that chain, not just the final actor.

3. Accountability that lands on a human

Here is the part the technology cannot solve. You can give an agent an ID, a wallet, and a scope, but when it drains an account or signs a bad contract, liability does not stop at the agent. It flows back to a person or an organisation. The ID is the mechanism that makes that traceback possible, which is good, but it does not decide who is liable, the principal who delegated, the developer who built the agent, or the vendor who shipped the model. Estonia is doing the responsible thing by forcing that question into the open early. Nobody has a clean answer yet.

Identity is necessary, not sufficient

A recent BCG line, quoted in the coverage, gets at the deeper issue: "Values are not rules. They are beliefs and principles formed through thousands of human decisions, shaped by context, exception, and precedent." An ID code can encode rules. It cannot encode judgment. An agent with a perfect, fully scoped, fully audited identity can still take an action that is technically permitted and obviously wrong. Identity gives you attribution and revocation. It does not give you good behaviour. Those are different problems, and conflating them is how you end up trusting an agent more than its design warrants because it has a nice badge.

What this means if you build with agents

You do not need to wait for a government registry to apply the thinking. The Estonia plan is just the national-scale version of choices you should already be making:

  • Give every agent its own identity. Not a shared service account, not a human's token. One principal per agent, so its actions are attributable to it alone.
  • Scope to the task, then expire it. Short-lived, narrowly scoped credentials beat long-lived keys every time. An agent that only needs to read should never hold a token that can write.
  • Log the delegation chain, not just the call. Record who authorised the agent and under what scope, so "who is acting on whose behalf" is a query, not a forensic dig.
  • Make revocation instant. The first thing you want when an agent misbehaves is an off switch that works in seconds, not a key rotation that takes a day.
  • Keep a human accountable on purpose. Decide, before deployment, who owns the agent's actions. Do not let the org chart discover it during an incident.

Estonia is right that agents operating at machine speed need built-in accountability, and right that an identity is where that starts. Just keep the order of difficulty straight. Issuing the ID is the announcement. Binding authority, tracing delegation, and deciding who answers for the agent is the work, and it is the same work whether you are a small team wiring up a tool-using model or a country issuing codes to the whole agent economy.

Read this next

For the infrastructure and platform side of running agents safely, the cloud field notes live at ercan.cloud. For consulting on AI, identity, and platform work, or just to say hello, start at ercanermis.com.