Reducing AI Agent Permission Risk in Azure with Entra Agent ID Governance
Enterprises are granting AI agents standing access nobody reviews. Here is the governance model that keeps agent permissions least-privilege and auditable.
Techrupt Team6 min read
Most organizations spent the last five years removing standing privileged access from human accounts. Privileged Identity Management, just-in-time elevation, quarterly access reviews, and a real approval trail. That work is now being undone by AI agents, which are provisioned inside a development project by a developer, granted access to production data on the first day, and then never reviewed again. The zero trust principles organizations applied to human identity have simply not been extended to non-human ones.
Microsoft Entra Agent ID gives every agent a first-class identity in the directory. That closes the inventory gap. It does not close the permission gap, because the controls are opt-in and the default configuration in Microsoft Foundry is deliberately permissive to keep developers moving. This post covers what we look for in agent identity reviews and the questions to ask before an agent is approved for production.
Why agent access is harder to govern
The business pressure to ship agents is real, and the security review has not kept up with it. In our assessment work the pattern is consistent: agents get built by application teams, permissions get granted by whoever holds the subscription, and the identity team finds out when the agent shows up in an audit. It is the same class of blind spot as the Azure security gaps business leaders routinely miss, arriving in a new form.
Three properties make agent access harder to govern than the service principal sprawl that preceded it, and each one compounds the risks of autonomous systems operating without guardrails.
Agents are created and destroyed faster than any review cycle. A quarterly access review assumes the identity still exists at review time and that a human remembers why it was granted. Neither assumption holds for agents.
Agent access is usually application-only. When an agent runs attended, using the OAuth 2.0 on-behalf-of flow, it can only reach what the signed-in user is already entitled to. That is a natural ceiling. When it runs unattended, using the client credentials flow, its access is bounded only by its own role assignments and its Microsoft Graph application permissions. There is no user to constrain it, and unattended is the mode most business automation actually needs.
Nobody owns the agent. Service principals at least had a creating engineer. Agents get built during a proof of concept, survive it, and end up with no accountable person when that engineer changes teams.
The financial exposure is not a licensing line item. It is the blast radius of one over-permissioned identity operating unattended against production data at machine speed.
A four-layer governance model
The governance model we recommend has four layers, applied in this order. The order matters, because inventory without ownership produces a list nobody acts on.
1. Inventory every agent identity in the tenant. The Microsoft Entra admin center now exposes a single view at Entra ID, then Agent ID, then All agent identities. It covers Foundry agents, Microsoft Copilot Studio agents, and agents registered through the Teams Developer Portal. Start here, because most organizations discover more agents than they expected.
2. Assign a sponsor to every agent. A sponsor is a named human user accountable for the agent’s lifecycle and access decisions. Entra transfers sponsorship to the sponsor’s manager automatically when they leave the organization, which means the accountability chain survives staff turnover. This is the single highest-value control on the list and it is the one most commonly skipped.
3. Grant resource access through access packages, not direct role assignments. Access packages support security group membership, application OAuth API permissions including Graph application permissions, and Microsoft Entra role assignments. More importantly they support an expiry date and an approval workflow. An agent can request access programmatically, or a sponsor can request it on the agent’s behalf. As the expiry approaches, the sponsor is notified and either requests an extension, which triggers a fresh approval cycle, or lets the assignment lapse.
4. Apply Conditional Access at the blueprint level. Conditional Access for agents and Identity Protection for agents evaluate agent risk before access is granted. Policies applied to an agent identity blueprint are inherited by every agent identity created from it, so the control scales with the agent population instead of trailing it.
Key Decision: Grant agent access through entitlement management with a defined expiry rather than through direct RBAC assignment. Direct assignments are permanent by default, and permanent access to production data granted during a proof of concept is exactly the debt this exercise exists to prevent.
Two Foundry details behind most misconfigurations
Both are documented, and both are easy to get wrong.
The identity you grant is not always the identity that acts. When Foundry provisions a project, it creates an agent identity blueprint with a federated credential trust relationship to the project’s managed identity. The managed identity authenticates the blueprint to Entra ID. It does not access the downstream resource. The agent identity is the principal that requires the RBAC role assignment on the target resource, and it is a separate service principal with its own object ID.
Teams that assign roles to the project managed identity see authentication failures, then widen the grant until something works. The correct assignee is the agentIdentityId from the project or agent application JSON view in the Azure portal.
# Grant the agent identity read/write on one storage account, at that scope only
az role assignment create \
--assignee "<agentIdentityId>" \
--role "Storage Blob Data Contributor" \
--scope "/subscriptions/<subscription-id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>"Publishing an agent changes which identity it uses. All unpublished agents in a Foundry project share one project agent identity. That is a deliberate convenience so developers are not reconfiguring permissions during experimentation. Publishing an agent creates a dedicated blueprint and a dedicated agent identity, and the shared project identity’s role assignments do not carry over.
The governance consequence is the part that gets missed. A security review performed before publication validates the permissions of an identity the production agent will not use. Role assignments have to be reapplied against the new agentIdentityId, and that reassignment is the correct trigger for the production access review.
Warning: Treat the shared project identity as a broad blast radius. Every in-development agent in that project authenticates as it. If an agent needs tighter controls or an independent audit trail, publish it so it receives a distinct identity, then scope its roles to the resource rather than the subscription.
From today’s state to the target state
The controls are available today. The gap in most environments is process, not product.
| Control | Common current state | Target state |
|---|---|---|
| Agent inventory | Unknown count, discovered during audit | Single tenant-wide view, reviewed monthly |
| Accountability | No named owner | Sponsor assigned, auto-transfers to manager |
| Access grant | Direct RBAC, permanent | Access package with expiry and approval |
| Scope | Subscription or resource group | Individual resource |
| Access conditions | None | Conditional Access inherited from blueprint |
| Review trigger | Quarterly, if at all | On publish, and at package expiry |
One budget note worth raising early, because it changes the sequencing. Governing agent identities with Entra ID Governance requires either Microsoft 365 E7, which includes Agent 365 and the Entra Suite, or a Microsoft Agent 365 license paired with at least Entra P1 or Microsoft 365 E3. Inventory and basic role assignment are available without that. Access packages, sponsors, and lifecycle workflows are not. Organizations planning an agent rollout should settle the licensing question before the first production agent ships, not after the audit finding.
Also note that automatic agent identity assignment for Copilot Studio agents is still in preview. Where agents are being built by business users in Power Platform rather than by engineers in Foundry, the governance posture needs to be confirmed rather than assumed.
Where to start
Start with the inventory and the sponsors. Together they turn an unknown population of agents into a list with a named owner for every entry. Access packages, Conditional Access at the blueprint level and the publish-time review follow from there, once the licensing question is settled.
If your organization is deploying AI agents on Azure and hasn’t yet defined who approves their permissions, we can assess your current agent inventory, identify over-permissioned identities and build a governance model that fits your compliance requirements. See how we take agentic AI from pilot to production, or contact us to schedule a consultation.
