Machine Identities: the accounts that no one counts

As of May 1, AI agents now have their own identities with Microsoft Entra Agent ID – complete with the same access policies, risk detection, and logging capabilities previously reserved for humans and workloads. This is the right response to a real problem. But it also creates a new class of accounts within directories that grow faster than IAM teams can track them. Machine identities are now a permanent item on every security review agenda.

Related:Copilot Cowork acts independently – the SOC doesn’t see it  /  Self-replication: AI agents rise from 6 to 81 percent

What is Microsoft Entra Agent ID? Entra Agent ID is an identity and security framework that extends Microsoft Entra capabilities to AI agents. Agents receive their own identities, enabling authentication, authorization, and management. They gain the same identity-driven protection mechanisms as users and workloads: adaptive access policies, real-time risk detection, lifecycle management, and logging. Entra Agent ID has been generally available since May 1, 2026, and is part of Agent 365, priced at $15 per user per month or included in the Microsoft 365 E7 bundle.

From App Registration Stopgap to Real Identity

Until 2025, AI agents in the Microsoft ecosystem mostly relied on app registrations. From an identity perspective, an agent was an application – not an independent actor. This worked as long as agents remained peripheral. But once a company runs dozens of them in production, the model breaks down. An app registration reveals little about what the agent actually does, who is responsible for it, or what permissions it has accumulated over time.

Entra Agent ID replaces this makeshift approach with a dedicated identity model. Instead of a single app registration, it introduces a three-tiered hierarchy comprising four object types. At first glance, this appears more complex; on closer inspection, it offers greater control, as permissions, responsibilities, and lifecycle can now be cleanly assigned per agent.

Source: Microsoft Learn on Microsoft Entra Agent ID, as of May 2026.

Using the blueprint, an agent can generate one or more agent identities, optionally each with its own Agent User identity. This is precisely where security teams need to pay close attention. A single template can spawn multiple identities – each of them a distinct account in the directory.

The New Class of Accounts No One Is Counting

Non-human identities – identities without a person behind them – are nothing new. Service accounts, workload identities, and API keys have accompanied security teams for years. What’s new is the pace. A service account is deliberately created, usually via a formal request. An agent identity, by contrast, comes into existence as soon as someone builds and activates an agent.

This shifts the scale challenge. Where departments once managed just a handful of service accounts, within months of agent deployment, dozens of agent identities may populate the directory – each with its own set of permissions. If the blueprint generates multiple identities per agent and each can optionally have an Agent User, the numbers multiply further.

Field experience is clear: any organization that doesn’t maintain an up-to-date inventory of agent identities will lose oversight within a single quarter. This inventory isn’t optional – it’s the essential foundation for being able to identify, during an incident, which non-human accounts exist and which one is currently behaving suspiciously.

Where the Agent Account Becomes a Security Risk

The most sensitive of the four object types is the agent user. A user-like identity for an agent is practical because it allows the agent to operate within systems designed for human users. Yet it’s risky for the exact same reason. An account that behaves like a user can also accumulate user-like permissions.

The classic privilege escalation pattern applies directly. An agent gains access to a system for an initial task. For the next task, a second access is added, then a third. Old permissions are never revoked because the agent is still running. After a year, the agent identity has accumulated a combination of rights no one consciously granted. If this agent is compromised – say, through manipulated input – the attacker gains full access to that entire permission set.

The implication is clear: agent identities with broad access must be treated the same as privileged user accounts. They require regular permission reviews, adherence to the principle of least privilege, and ideally, time-limited access grants instead of permanent ones. Entra Agent ID provides the tools for this, as agents can be assigned the same access policies as humans. But these tools only work if teams actively apply them to agent accounts.

Credential Lifecycle for Non-Human Identities

A human account follows a clear lifecycle: it’s created upon onboarding, adjusted during role changes, and disabled upon departure. Departure is the most critical moment, as it closes the account. With agent identities, this moment is often missing – because agents don’t resign.

This is precisely the silent gap. An agent is built for a project; when the project ends, the agent keeps running or at least remains in the directory. Its identity, credentials, and permissions stay active. From an attacker’s perspective, a forgotten but still-privileged agent identity is an ideal target: functional, authorized, and unmonitored.

Therefore, the lifecycle for agent identities needs a defined endpoint. Every agent identity should have an expiration date or mandatory review requirement. An identity whose associated agent has shown no activity for months becomes a candidate for deactivation. Entra Agent ID logs activity for every agent identity, so the data for such decisions is already available – it just needs to be analyzed.

What Security Teams Should Plan Now

Entra Agent ID is an improvement. It brings agents into an established system that has managed identities effectively for years. The mistake would be assuming this improvement works automatically. Four steps must be planned before the number of agents reaches double digits.

First, inventory. Maintain an up-to-date directory of all agent identities, including the associated agent, owner, and scope of permissions. Without this inventory, every further action is blind.

Second, privilege classification. Treat agent identities with broad access like privileged accounts, with regular permission reviews and minimal privilege assignment.

Third, lifecycle management. Assign every agent identity an expiration date or review obligation. Deactivate inactive identities – don’t leave them running for convenience.

Fourth, detection. The SOC needs rules to detect anomalous behavior from agent identities, such as unusual privilege escalation or activity outside expected patterns. Entra Agent ID provides the necessary log data; analyzing it is a separate task.

The sober assessment: machine identities aren’t cause for panic, but they do demand discipline. Microsoft has built the right framework for AI agents to exist as manageable identities. Whether this results in a clean, well-maintained directory or a wild proliferation of non-human accounts will be decided by the security team – not the product.

Frequently Asked Questions

Every question is locked. A tap unlocks the answer.

What is Microsoft Entra Agent ID?

Entra Agent ID is an identity and security framework that extends Microsoft Entra capabilities to AI agents. Agents receive their own identities with adaptive access policies, risk detection, lifecycle management, and logging. It has been generally available since May 1, 2026, and is part of Agent 365.

What are the four object types in the identity model?

The model consists of the Agent Identity Blueprint as a template, the Blueprint Principal as a security anchor, the Agent Identity as the identity of the running agent, and the optional Agent User, a user-like identity. Using the Blueprint, one or more agent identities can be created.

Why are machine identities a security risk?

Not because they are inherently insecure, but because they grow quickly and unnoticed. Every productive agent generates at least one identity. Without inventory, privilege classification, and lifecycle management, a stock of non-human accounts emerges that no standard routine captures, and which becomes a blind spot in the event of an incident.

What’s particularly sensitive about the Agent User?

The Agent User is a user-like identity for an agent. Because it behaves like a user account, it can also accumulate rights like a user account. Without regular rights checks, a combination of rights emerges that no one has consciously assigned. A compromised Agent User then opens up this entire access.

What should security teams do first?

Set up a current inventory of all agent identities, treat identities with extensive access like privileged accounts, assign an expiration date or review obligation to each agent identity, and supplement detection rules for anomalous agent behavior in the SOC. The log data for this is provided by Entra Agent ID.

Editor’s Reading Tips

• NIS2 Audit: Where the Vendor List Falls Apart in Two Hours
• eBPF Monitoring in Kubernetes: Detecting Invisible Runtime Processes
• Detection Engineering without Vendor Lock: Wazuh Stack 2026

Editor’s Picks

Editor’s PickNIS2 Audit: How the Vendor List Crumbles in Two HoursEditor’s PickeBPF K8s Monitoring: Detecting Invisible Runtime ThreatsEditor’s PickDetection Engineering Without Vendor Lock: Wazuh Stack 2026

More from the MBF Media Network

cloudmagazinCopilot Studio Becomes the Agent Control CenterMyBusinessFutureMicrosoft’s AI bundle for $99: Is the jump worth it?Digital ChiefsAgent 365 orders the AI agents, liability remains open