Estonia is not handing out digital passports to bots. Instead, on June 17, 2026, the government quietly unveiled a plan that could fundamentally change how enterprises think about AI agent security: "AI ID codes"—a framework for giving autonomous software scoped, auditable, and revocable permissions. While the immediate target is public-sector automation, the real impact will land squarely on the desks of Windows administrators grappling with the unchecked proliferation of AI agents in Microsoft 365, Power Platform, and Azure.

The project, led by Estonia’s Information System Authority (RIA), aims to create a government-backed digital identity and authorization framework for AI agents that need to prepare documents, interact with systems, or make narrowly bounded transactions. Crucially, these IDs are not a new legal personhood category for models. They are a technical and legal scaffold for delegated authority—an agent can act for a person or company, but only within strictly defined, easily killable lanes.

What Estonia is actually building

The initiative, called Reason Reserve (Aruait in Estonian), is being pitched as an “Identity 2.0” framework for machines. Over 24 months and with a budget of €1 million, RIA will develop:

  • A central trust registry for AI agents from both public and private sectors.
  • Technical interoperability standards so agents can operate across different systems.
  • At least one end-to-end pilot where a public-sector agent interacts with an agent representing a citizen or private organization, without a human manually completing every step.

Prime Minister Kristen Michal’s office framed the effort as a practical tool, not a sci-fi indulgence. An agent might be authorized to view data, draft a declaration, prepare a payment, or work within a specific financial ceiling—but nothing more. The design is explicitly not “give the Copilot-style assistant everything the user can access and hope the logs explain what happened later.”

RIA’s plan recognizes that an agent cannot safely inherit the full identity of the employee who launched it. That observation, while seemingly obvious, is the quiet crisis already unfolding in enterprise IT.

Why this matters for your Microsoft environment

AI agents are everywhere now—and most are running with the wrong permissions. A user-facing Copilot might need to read SharePoint content, search Exchange mailboxes, query a line-of-business application, and create a ticket in ServiceNow. If it operates under the employee’s own session and permissions, the agent has a dangerously broad effective identity. A prompt-injection attack, a compromised connector, or an overly eager workflow can turn convenience into data exposure or unauthorized action.

The security model Estonia is prototyping asks four operational questions before an agent touches a Windows domain, Microsoft Graph tenant, cloud subscription, or internal application:

  1. Which human, team, or business process authorized the agent?
  2. Does the agent have only the permissions required for its defined task—not a cloned version of its owner’s access?
  3. Can every material action be attributed to the agent, its delegation chain, and its active policy?
  4. Can the organization revoke the agent’s authority immediately without disabling the employee’s own account?

This last point is the practical gap between an agent and a traditional application registration. A conventional app tends to run a predictable set of requests against known APIs. An agent can choose tools, interpret documents, create new requests, and alter its course based on what it encounters. Its authorization model must be able to limit what it is allowed to decide, not only authenticate the software binary.

That requirement becomes sharper in Windows-heavy organizations using Copilot Studio agents, Azure AI services, Power Automate flows, and custom tools exposed through Model Context Protocol servers. The convenience layer increasingly connects a large language model to email, files, collaboration data, scripts, and administrative APIs. The identity layer cannot remain an afterthought.

The audit trail problem: “The user did it” isn’t enough

Estonia’s digital-government experience gives it an advantage. The country already operates national digital identity, electronic signatures, and the X-Road data-exchange infrastructure. Its proposal extends the same administrative question into agent systems: who acted, on whose behalf, with which rights, and who remains accountable?

That sounds mundane, but it fixes a massive visibility gap. Suppose a Microsoft 365 agent reads a confidential document, summarizes it in Teams, and then creates a task in an external SaaS platform. A useful audit record must distinguish among:

  • The employee who requested or approved the task.
  • The specific agent instance that planned and executed it.
  • The model and tools used during the run.
  • The policy that allowed each access and outbound action.
  • The destination identity that received the result.

Without that separation, incident response becomes a mess of ambiguous user activity. A security team may see a legitimate employee identity accessing legitimate data through legitimate APIs, yet be unable to determine whether the employee requested an action, whether an agent inferred it, or whether hostile instructions embedded in a document redirected the workflow.

This is where agent identity intersects with prompt injection. The most dangerous agent deployments combine three conditions: access to untrusted content, access to sensitive resources, and the ability to send data or trigger actions externally. An identity system does not make prompt injection disappear. What it can do is ensure the injected workflow runs into hard permission boundaries before it reaches a mailbox, credential store, payment system, or production tenant.

How we got here: AI agents outran identity thinking

Agent adoption has exploded. Coding assistants, business process automation, and customer-facing chatbots are increasingly autonomous. Yet the default in most organizations remains “the agent gets my full access.” That shortcut worked for early chatbots that only answered questions from a knowledge base. It breaks when agents can send email, modify records, execute scripts, or access financial systems.

Estonia’s move is part of a wider shift toward agent-native infrastructure. The government’s long track record with digital services—e-Residency, X-Road, digital signatures—gave it the institutional muscle to design a trust registry. The European Union, meanwhile, is watching closely; Estonia often serves as a policy testbed for digital identity innovations.

The real urgency, though, comes from the enterprise side. Microsoft’s own platforms already contain the building blocks for agent-specific identity. Entra ID workload identities, managed identities, Conditional Access, Privileged Identity Management, Purview auditing, and Defender telemetry all exist. The missing piece is the organizational will to use them for AI agents and the absence of a clear delegation framework. Estonia’s API-driven approach could fill that gap—or at least inspire vendors to build something equivalent.

What IT teams should do right now

You don’t have to wait for a national registry. The same discipline can be applied today with existing Microsoft 365 and Azure tools.

  • Give every agent its own identity. Stop treating an AI agent as a transparent extension of the person using it. Create a separate workload identity in Entra ID for each agent.
  • Scope permissions to the smallest viable set. Use Microsoft Graph granular permissions, not broad roles. If an agent only needs to read your calendar, don’t grant mailbox access.
  • Require step-up authentication for high-impact actions. Changing permissions, exporting sensitive content, initiating payments—these should trigger an explicit user approval or Conditional Access challenge.
  • Build agent-specific audit trails. Ensure logs capture the agent’s identity, the user who authorized it, the task context, and any data destinations. Microsoft Purview can be configured to track these attributes.
  • Inventory all existing agents. That includes Power Automate flows with AI actions, Copilot Studio agents, browser automation, GitHub or Azure DevOps bots, Teams-connected assistants, and third-party SaaS agents holding OAuth grants. The agent that has no owner, no policy record, and no clear revocation path is the most likely to turn an ordinary automation failure into a security incident.
  • Test for prompt injection and data exfiltration. Assume every agent reads untrusted content. Limit its network egress and sandbox its actions. Defensive guardrails that inspect tool calls (like the ones being developed by AI security startups) can add a layer of policy enforcement.

Outlook: Estonia’s pilot as a blueprint

Estonia will spend the next two years building its trust registry and running a real-world pilot. If successful, the framework could become a model for other governments and, importantly, for enterprise identity providers like Microsoft, Okta, and Ping Identity. The EU may adopt similar standards, and regulatory pressure may eventually require agent-specific authentication and audit capabilities.

But the pilot’s success is not guaranteed. A registered identity is not evidence that an agent is trustworthy or well-configured. The hard questions remain: What precisely defines an agent—the model, the prompt, its tool list, or a single runtime session? How are software updates handled? Can an agent delegate to a sub-agent, and if so, how is that delegation bounded and recorded? And what happens when an agent performs an action across national or cloud-service boundaries?

RIA’s Reason Reserve project is an attempt to create an agent control plane, not just a database of names. Whether that becomes a European standard or remains an Estonian digital-government experiment will depend on its ability to work with existing enterprise identity platforms rather than replace them.

For Windows admins and security teams, the key takeaway is already in hand: treat agents as independent, potentially compromised actors. Give them the least privilege, monitor their actions, and make sure you can revoke their access instantly without disrupting the humans they serve. Estonia’s AI ID codes may be years away, but the problem they solve is already on your tenant.