Anton Staykov

Posted on Jul 9

Access packages are the control plane for Entra Agent ID permissions

#entraagentid #identitygovernance #microsoftentra #aiagents

It has been a couple of months since Microsoft Entra Agent ID became generally available, but the same message keeps landing in my inbox: "How do we grant permissions to an agent identity? There is no API Permissions page in Entra."

That moment is always interesting. The team thinks they found a product gap. What they actually found is a mental-model gap.

Most engineering organizations still design identity the old way: define a permission set early, grant it once, and treat that grant as stable infrastructure. That was already brittle for conventional apps. For agents, it is worse. An agent is useful because it encounters new contexts, new tools, and new data surfaces after go-live.

In A transformational AI agent does not start with the permissions it needs, I argued that serious agents should start narrow and earn scope over time. This article is the governance architecture behind that claim.

The portal is not missing a button, your architecture is missing a layer

Entra Agent ID does not erase consent. It does not replace consent. It does not invent a magical fourth mode of consent.

Consent fundamentals remain exactly what Microsoft documents for enterprise applications: user consent and admin consent are still the core model. If delegated access is allowed by policy, a user can authorize it. If risk or scope requires stronger control, admin consent is required.

That is the first important correction: the "no API permissions blade" observation should not lead to panic. It should lead to design. Agent identities are still bound to Entra authorization rules, including the Agent ID authorization model for delegated and application permissions.

The missing thing is not a tab. The missing thing is an operating path for controlled permission growth.

Consent semantics are unchanged, enterprise consent posture is still strict

Some architects respond with: "Fine, let users consent as the agent discovers new needs."

Technically, that is an option in specific policy configurations. Operationally, most enterprises do not live there.

Real-world tenants often clamp user consent tightly with explicit tenant-level consent settings, because delegated access can expose sensitive workloads very quickly when control boundaries are weak. Security teams are not being stubborn here. They are pattern matching from years of experience.

So we end up with a familiar tension:

AI platform teams need agents that adapt at runtime.
Governance teams need approvals, accountability, and least-standing-privilege.

If you force one side to "win," you get predictable failure modes. Either the agent is over-permissioned up front, or it is blocked by manual ticketing loops every time reality changes.

Access packages for agent identities are the bridge

This is where access packages for agent identities become much more than a governance checkbox.

Access packages give you a permission supply chain. The agent does not invent access. It requests from a pre-governed catalog. Policy decides if, when, and how access is granted.

That sounds abstract until you map it to day-to-day architecture decisions:

Identity engineers define packages that correspond to meaningful data capabilities.
Security and compliance teams define who can approve under which conditions.
Agent runtime requests package assignment only when task context justifies it.
Lifecycle policy removes or expires access when the need window closes.

This is exactly the governance direction reflected in Entra guidance for governing agent identities: agent access is not just about granting once, it is about ongoing controlled assignment.

The underrated power move: put consent inside workflow

Most teams still treat admin consent like a one-off privileged ceremony. Someone with rights clicks approve, everyone moves on, and the architecture diagram quietly lies about "least privilege."

Access packages let you treat that approval as a workflow stage instead of an exception path.

With entitlement management policies, you can require multi-stage approvals, use dynamic approval selection, enforce separation-of-duties with incompatible packages, and enforce expiry and lifecycle controls.

If that still feels too generic, add custom process hooks through Logic Apps integration for entitlement management. That is where you inject business-specific gates: risk score checks, change-ticket correlation, regulatory checks, or post-assignment notifications into your SOC workflow.

This is why I keep calling access packages an underestimated powerhouse. They are not "just governance UI." They are programmable policy choreography.

How this looks in a real request loop

A transformational agent pattern becomes concrete when the request loop is concrete.

Start with the assumption that the agent is under-permissioned for future unknown tasks. When it hits a boundary, it enters a governed escalation loop:

Determine the missing capability from the failed call and policy context.
Discover candidate packages from GET access packages.
Inspect assignment rules through GET assignment policies.
If policy allows, submit POST assignment request.
Let approval workflow, incompatibility checks, and lifecycle policy decide the final outcome.

If you need to inspect package role mappings more deeply, you can also query resource role scopes in an access package.

Notice the key architectural boundary: the agent can request escalation, but it cannot bypass governance. That is the whole point.

Why this matters more than one Entra feature

If we are honest, most early agent pilots still hide one uncomfortable truth: broad standing access was pre-granted so the demo would not fail in front of stakeholders.

That shortcut does not scale. It becomes technical debt with legal exposure.

The better model is plain:

capability discovery can be dynamic,
approval can be policy-bound,
access can be time-bound,
accountability can be explicit.

That combination is exactly what transformational agents need. They can evolve without becoming permanent over-privileged identities.

The decision point for architecture teams

If your operating model is "we will manually update permissions whenever the agent needs something new," you do not have an agent permission model. You have a backlog with production blast radius.

If your operating model is "new access must flow through access packages with policy-owned approvals and expiry," then you have something that can survive beyond a pilot and withstand audit pressure.

That is the shift in one sentence: agent autonomy should grow through governed workflow, not through standing privilege.

This is why the "missing API Permissions tab" conversation is useful. It forces the right question. Not "where do I click to grant more?" but "what control plane governs permission growth in my tenant?"

For Entra Agent ID in enterprise reality, the best answer today is access packages.

DEV Community