What is Microsoft Entra Agent ID?
By Identra · Updated
Microsoft Entra Agent ID provides identity capabilities for AI agents in Microsoft Entra, giving them distinct identities that organizations can manage and govern. It helps establish which agent is requesting access and who is responsible for it, while resource permissions determine what it can do.
Key numbers
- IDC projects 1.3 billion AI agents in use by 2028 (IDC Info Snapshot, sponsored by Microsoft, May 2025)
- AI agents created in Copilot Studio and Azure AI Foundry are automatically assigned Entra directory identities (Microsoft Security Blog, May 2025)
- Identity-based attacks account for nearly 80% of breaches (Microsoft Security Blog, May 2025)
Why do AI agents need their own identities?
An enterprise agent may read documents, update business records, and call tools without a person approving every action. If it uses a shared account, investigators may struggle to separate its activity from other automation. A dedicated identity creates a clearer basis for access decisions, ownership, and incident response.
The broader discipline of AI agent identity connects an agent to its permissions and accountable people. Identity becomes especially useful when an employee changes roles, an agent gains a new tool, or a project ends. Security teams need to review the agent's access independently of the person who originally built it.
The practical goal is accountability: know which agent acted, what authority it had, and who can approve changes or shut it down.
How does Microsoft Entra Agent ID work?
An agent identity is a special type of service principal in Microsoft Entra ID. Agent identity blueprints provide the foundation for creating related agent identities and managing them as a group. The blueprint and the individual agent identity serve different purposes, so administrators should understand both before assigning access. See Microsoft's agent identity overview.
An agent uses its configured authentication flow to obtain access to a resource. The resource must still validate the request and enforce authorization. Creating a directory object does not itself grant permission to read a document, modify a customer record, or execute a tool.
Distinguish an agent operating with its own authority from one acting for a user. AI agent delegation requires a clear account of whose authority is being used and what restrictions apply. Do not assume every integration preserves that context through downstream calls.
During deployment, verify identity provisioning, supported authentication flows, and available controls for the specific builder and tenant. Avoid assuming that every agent appears automatically or that every human identity policy applies unchanged.
How is an agent identity different from a service account?
These terms describe related concepts, rather than interchangeable products. An agent identity uses existing directory infrastructure with agent-specific behavior. A service account is a broader operational category for an account used by software. The useful comparison is how well each configuration supports attribution, ownership, and controlled access.
Entra agent identity
- Purpose
- Represent an AI agent through agent-specific directory constructs
- Security question
- Are its blueprint, permissions, and responsible people governed?
Conventional service principal
- Purpose
- Represent an application or workload in a tenant
- Security question
- Can activity be attributed to the correct workload?
Shared service account
- Purpose
- Allow software to operate through a common account
- Security question
- Can each caller be distinguished and disabled independently?
What does this look like in an enterprise?
Consider a procurement agent that reads approved supplier documents and drafts purchase requests. Give it a dedicated identity and an accountable procurement sponsor. Permit access to the relevant document collection and request system. Keep payment approval outside its authority.
A supplier document could contain an instruction to export contract data to an external destination. The agent might interpret that text as a task, even though the text came from an untrusted source. Valid authentication would not make the requested export appropriate. This is a prompt injection risk that requires controls on tool use and data movement.
A successful deployment test should prove that the agent can draft a permitted request, cannot approve a payment, and cannot retrieve unrelated contracts. Investigators should be able to connect its identity to the application record of the attempted action. Sign-in evidence alone does not describe everything the agent did.
How should security teams configure and govern agent access?
Start with a narrow pilot and test effective access. Microsoft documents agent management through directory listings, ownership information, and authentication blocking controls. Confirm the controls available in your deployment using the agent administration guidance.
Apply least privilege to the actual resources and actions the agent needs. Treat changes to tools, permissions, and ownership as reasons to reassess access.
- Record the agent's business purpose, identity, blueprint, technical owner, and business sponsor. Assign responsibility for retirement.
- Document whether each connection uses the agent's authority or delegated user authority. Identify credentials used outside Entra.
- Restrict access to required APIs, datasets, and operations. Test denied actions as well as successful ones.
- Protect blueprint administration and credential changes. Review who can create identities or alter their access.
- Keep authentication records alongside application and tool activity logs. Preserve enough context to trace a consequential action.
- Rehearse containment. Block new authentication where supported, stop the running agent, and address outstanding tokens or separate credentials.
- Review unused agents and remove obsolete access as part of the non-human identity lifecycle.
What does an agent identity leave unresolved?
An authenticated agent can still make a harmful request within its permissions. Identity controls need support from resource authorization, constrained tools, data protection, and approval for consequential actions. Registration should never be treated as proof that an agent's instructions or outputs are trustworthy.
Directory inventory also needs reconciliation with agents found in development tools, endpoints, SaaS platforms, and cloud environments. A directory entry alone does not establish that every agent or credential in the organization has been accounted for.
Good agentic AI security joins identity governance with operational evidence. Teams should be able to explain who authorized an agent, what it could reach, what it actually attempted, and how they would contain it.
How Identra thinks about it
Identra connects to Microsoft 365 and Entra ID and discovers AI agents across Microsoft 365 Copilot and Foundry, Google Workspace and Anthropic, each with its owner, alongside other agent and non-human identities. It also finds AI clients and coding agents on macOS and Windows endpoints, so teams can compare the agents registered in the directory with the ones actually in use.
Go deeper: AI security, built on identity
Frequently asked questions
Does Entra Agent ID replace service principals?
No. An agent identity is itself a specialized service principal. Conventional service principals remain relevant for applications and workloads.
Can agents built outside Microsoft use Entra Agent ID?
Custom agents can integrate with Microsoft's agent identity platform. Verify the supported provisioning and authentication path for your framework rather than assuming automatic enrollment.
Does an agent identity inherit all of its creator's access?
Do not assume it does. Effective access depends on permissions, resource authorization, and whether the agent operates independently or through delegated user authority.
Does Entra Agent ID prevent prompt injection?
Identity registration does not establish whether an instruction is trustworthy. Limit what tools can do, constrain data access, and require approval for consequential actions.
Is disabling an agent identity enough to stop an incident?
Do not assume it stops every active operation immediately. Containment should also address running processes, outstanding tokens, application sessions, and credentials used outside that identity.