Your AI Agent Needs Its Own Identity, Not a Shared Service Principal

Ask the team running your AI pilot a simple question: when the agent read that SharePoint site last Tuesday, whose credential did it use?

In most organizations the honest answer is "the app registration Marc created in March." Marc has since moved teams. The secret is in a pipeline variable. The sign-in log shows a service principal named sp-ai-poc-02, and nothing in the tenant records that a non-deterministic system was on the other end of it.

That is not a production system. That is an unowned credential with a language model attached to it.

The gap: agents borrowed an identity model built for something else

Service principals were designed for services your organization builds and maintains. Microsoft's own documentation is blunt about the expectations baked into them: long-term stability, known ownership, a managed lifecycle. Software that gets deployed, versioned, and decommissioned on a quarterly rhythm.

Agents do not behave that way. An agent might exist for ninety seconds to complete one task. It might be created and destroyed thousands of times a day inside an automated workflow. A business user can spin one up in Copilot Studio between meetings. Force that population through the service principal model and you get exactly what most tenants have today: orphaned app registrations, permission assignments nobody can trace to a decision, and an audit trail that cannot distinguish a scheduled ETL job from an autonomous system making judgment calls on customer data.

The gap is not a model problem. It is an identity problem, and it is the reason a lot of promising pilots stall the moment a security review starts.

What Microsoft actually shipped

Microsoft Entra Agent ID introduces agent identities: accounts in Microsoft Entra ID built specifically to authenticate AI agents. Per Microsoft Learn, Agent ID is available to all Microsoft Entra customers. Microsoft Agent 365, the control plane layered on top for governing agents across Microsoft 365 and partner platforms, reached general availability on May 1, 2026, at USD 15 per user per month, or bundled in Microsoft 365 E7.

There are four object types worth understanding before you design anything:

Agent identity blueprint: the template. Define permissions and policy once.
Agent identity blueprint principal: the blueprint's footprint in a tenant, which is how a multitenant agent gets instantiated in a customer directory. Same pattern as a multitenant app's service principal.
Agent identity: an individual running instance, created from a blueprint. This is what appears in your sign-in logs.
Agent user: an optional paired Entra user account, one-to-one with an agent identity, for systems that only understand "a user."

The practical difference shows up the first time someone asks who touched a record. This is the shape of the change, not a verbatim log schema:

# before
actor:     sp-ai-poc-02  (service principal)
owner:     (none)
policy:    tenant-wide CA policy, agents indistinguishable from jobs
lifecycle: manual, until someone deletes it

# after
actor:     agent identity "invoice-triage-prod-07"
blueprint: bp-invoice-triage        <- policy + inheritable permissions live here
sponsor:   a named human, transfers to their manager if they leave
access:    access package, expires 2026-11-01, renewal requires approval

The parent-child relationship is the useful part. Permissions can be inherited from the blueprint, and Conditional Access can be applied at the blueprint level so every agent identity created from it inherits the policy. You govern the template, not ten thousand instances.

Several Microsoft surfaces already provision these automatically. Microsoft Foundry creates a default blueprint and identity when you create the first agent in a project, then a dedicated blueprint and identity when you publish, and supports agent identity authentication for MCP and A2A tools. Copilot Studio can auto-assign agent identities. App Service and Azure Functions apps can connect to resources as an agent.

Read that again if you run a Microsoft shop: agent identities are likely being created in your tenant right now, whether or not anyone has decided how to govern them.

The field that matters most is a human name

Everything above is plumbing. The governance mechanism that changes outcomes is the sponsor.

A sponsor is a human user accountable for decisions about an agent identity's lifecycle and access. Not a distribution list. Not "the AI team." A person. In Copilot Studio, the user who creates an agent is recorded as its sponsor automatically.

Three things follow from that, and they are the ones worth putting in your design doc:

Access is requested, approved, and expires. Agent identities get resource access through access packages: security group membership, application OAuth API permissions including Graph application permissions, and Microsoft Entra roles. The agent can request one programmatically, or its sponsor can request it on the agent's behalf. In the access package assignment policy, under Who can get access, you select For users, service principals, and agent identities in your directory, then All agents.
Expiry has a human in the loop. As an assignment nears its end date, the sponsor is notified. They can request an extension, which can trigger a fresh approval cycle, or do nothing, in which case the assignment expires and the agent loses access. Standing access becomes a decision someone has to actively renew.
Accountability survives turnover. If a sponsor leaves the organization, sponsorship transfers automatically to their manager, and Lifecycle Workflows can notify cosponsors and managers ahead of the change. This is the control that prevents the sp-ai-poc-02 problem from recurring in a new costume.

On top of that, Conditional Access for agents evaluates agent context and risk (including agent identity risk from Microsoft Entra ID Protection) before access is granted.

The licensing reality, stated plainly

Agent ID itself is available to all Entra customers. Extending Entra's security and governance features to agents is licensed:

Capability	Requirement
Conditional Access for agents	Microsoft Entra ID P1
ID Protection for agents	Microsoft Entra ID P2
ID Governance for agents	Microsoft Entra ID P1
Network controls for agents	Entra Internet Access (in Entra Suite or standalone)

Each of those also requires a Microsoft Agent 365 license, or Microsoft 365 E7, or E5 paired with Agent 365. Budget for it in the design phase. Discovering the license gap during a security review is how an eight-week build becomes a six-month one.

What this does not solve

Agent identity gives you attribution and lifecycle. It does not give you governed data.

If your agent has an identity, a sponsor, and a time-bound access package pointed at a SharePoint site with inherited permissions nobody has audited since 2019, you have made the blast radius auditable without making it smaller. The identity layer tells you who did what. It does not tell you whether the agent should have been able to see it.

That ordering matters. Scope the use case, govern the data the agent is allowed to read, then give it an identity that makes every read attributable. Doing it in the other order produces excellent logs of a problem you have not fixed.

The checklist

Before you call an agent production-ready:

It authenticates as its own agent identity, not a shared service principal.
A named human sponsor exists and is current.
Access comes from an access package with an expiry date, not a standing role assignment.
Conditional Access is applied at the blueprint level so new instances inherit it.
The data it can read has been scoped and reviewed, with the access logged.
Someone owns it after the delivery team leaves.

Notice how little of this is about the model. It rarely is.

Speed without rigor isn't velocity. It's technical and regulatory debt.

Regulators and auditors are converging on the same question from a different direction: when an automated system touches personal information, who is accountable for it, and can you show your work? "The AI did it" has never been an answer. Now there is no excuse for it being the only one available.

Start with a free scan. Under 24 hours, no commitment: we inventory the agent and workload identities already live in your tenant, who owns them, and what they can reach. Most teams are surprised by the count.

Entrazure ships one governed AI agent into production in 8 weeks — on your data, in your Azure tenant. Scoped. Built. Governed. Delivered.

Sources

✅ Publié : https://www.entrazure.com/blog/your-ai-agent-needs-its-own-identity-not-a-shared-service-principal/