An introduction to agent identities
Understand what an agent identity represents, how Microsoft platforms create it, and when the Agent 365 SDK is needed. Learn the basic decisions about access and accountability before deploying an agent.
When an AI agent reads a document or updates a business record, whose authority is it using? The answer determines what it can access, how its actions are attributed, and who is responsible for it.
Microsoft Entra Agent ID gives agents identities that organizations can recognize and manage. The architectural task is to connect each agent’s purpose to the access it needs and the people accountable for its use.
- An agent identity identifies the agent, separately from the person using it.
- A platform may create the identity for you. The Agent 365 SDK is not required for every agent.
- Decide whether each task uses a person’s access or access granted to the agent.
- Identity does not grant permission by itself, and every agent still needs human accountability.
What an agent identity represents
An agent identity is an account for an AI agent in Microsoft Entra. Technically, it is a specialized service principal: an identity for software rather than a person. It lets an organization assign access to an agent, distinguish its activity, and manage its lifecycle.
The identity is not the model, the agent’s code, or a conversation. It represents the agent when it interacts with other services.
Microsoft Entra Agent ID provides the identity and access foundation. Microsoft Agent 365 provides broader management of agents, including inventory and lifecycle oversight. They work together, but an inventory entry alone does not prove which account the agent uses.
Blueprint, identity, and optional user account
| Concept | What it means |
|---|---|
| Blueprint | A shared definition from which agent identities are created. It holds their common authentication settings. |
| Agent identity | The account representing an agent, with its own access assignments and sponsor. One blueprint can support many identities. |
| Agent user | An optional linked user account for services that require one, such as an agent’s own mailbox. It is not needed for every agent. |
You may also encounter blueprint principal, which is the blueprint’s representation in your tenant. Platforms and provisioning tools manage this directory object as part of setup.
The important boundary is that identities from the same blueprint share an authentication foundation. Group only agents that can safely share it. A separate agent identity allows distinct permissions, but does not remove that shared dependency.
Agent user experiences in Agent 365 are currently limited to the Frontier preview program. See the identity model for availability and account requirements.
How agents get their identities
Start with the platform. Some platforms create identities as part of creating an agent; custom development leaves that responsibility with your team.
| Platform | What to expect |
|---|---|
| Copilot Studio | Automatically creates an Entra Agent ID for each new agent under the shared Copilot Studio blueprint. |
| Microsoft Foundry | In the newer agent model, automatically creates a unique blueprint and identity when you create an agent, by default. |
| Agent Builder in Microsoft 365 Copilot | Creates declarative agents with built-in Agent 365 integration. That guidance does not specify the exact Entra identity creation process, so do not assume it matches Copilot Studio. |
| Custom-built agents | Use the Agent 365 SDK when your code needs Agent 365 identity integration. The Agent 365 CLI helps provision the blueprint and supporting identity resources; your team can also use Entra tools or APIs directly. |
Existing agents need a separate check. Older Copilot Studio agents may use app registrations, and older Foundry agents may share a project identity until published. Do not assume every agent in an existing estate has its own Agent ID.
For platform details, see Copilot Studio, Foundry, Agent Builder, and custom identity creation.
When to use the Agent 365 SDK
Use the Agent 365 SDK when your agent needs Agent 365 capabilities in its code that the platform does not already provide, such as authentication, activity reporting, governed tools, or Microsoft 365 notifications.
Agent Builder, Copilot Studio, and supported Foundry scenarios have built-in integration. You do not add the SDK simply because an agent needs an identity or an inventory entry. Administrative setup may still be necessary.
The Agent 365 CLI helps automate setup; the SDK adds capabilities to the running agent. Neither should be confused with the Microsoft 365 Agents SDK, which supports building and hosting agents. See integration options and the SDK overview when choosing a development approach.
Decide whose access the agent uses
Choose the access pattern for the task, not simply because the agent is described as conversational or autonomous.
| Access pattern | Meaning | Example |
|---|---|---|
| For a person | Uses delegated access, limited by the person’s rights and the permissions approved for the agent. | Reads the requesting employee’s calendar. |
| As the agent | Uses access granted to its agent identity, without relying on a person’s access. | Processes business records on a schedule. |
| Through its own user account | Uses its linked agent user for services that require a user account. | Reads its own mailbox. |
One agent can use different patterns for different tasks. A person starting a conversation does not mean every subsequent action uses that person’s access.
Keep a person accountable
An agent needs both technical responsibility and business accountability:
- An owner manages its technical configuration and operation.
- A sponsor is accountable for its purpose, continued need, and lifecycle decisions.
Entra requires a sponsor for each agent identity and blueprint. Assign a technical owner as an operational practice, and plan how responsibility changes when people move or leave. Review whether the agent still needs its access and who can retire it. See owners and sponsors for the administrative model.
What identity does not solve
Identity establishes who is acting. Permissions limit access. Neither determines whether every permitted action is appropriate. For example, granting permission to send email does not decide whether a particular message should be sent. Treat approval for consequential actions as a separate design decision.
Entra provides access policies, identity risk detection, and governance controls. These must cover the accounts the agent actually uses, including any linked agent user. Do not assume existing human-user policies protect every agent. See agent management and protection for configuration and current limitations.
Before deployment, be able to name the agent’s identity, explain whose access each task uses, and identify the people responsible for it. Those are the foundations; detailed policy and operational design follow from them.