DEV Community: Anton Staykov

Authorization options for your AI agents with Entra Agent ID

Anton Staykov — Thu, 27 Aug 2026 09:43:00 +0000

Authorization in Entra has changed, and most of that change is not visible in the product UI. The boundaries have always been there; they are just no longer optional side-quests. When you architect an Entra Agent ID, you are not choosing one authorization mechanism. You are composing five of them, each with its own trust surface. Understanding that composition is the difference between a loosely guarded identity and one that respects the principle of least privilege.

Consent is authorization, not authentication. But consent is only the start. After you have granted the app permission to call Microsoft Graph, the hard work is to ensure it calls Graph with the minimum scope it actually needs, at the exact moment it needs it, and only on behalf of the principals you intended. That is what this article addresses.

User assignment as your outermost gate

User assignment is the first boundary you should establish. It is blunt, but it is not optional. When you require user or group assignment to an enterprise application, you are saying: "Only the principals I explicitly list in this Entra app object can even attempt to authenticate to this workload."

For user-facing applications, this is straightforward. You assign Alice and Bob to the app, and only Alice and Bob can sign in.

For an AI agent, user assignment works similarly. You do not assign the agent's identity to an app. Instead, you assign the users who are allowed to delegate to or authenticate to the agent. In other words that assignment controls which users can invoke the agent or have the agent act on their behalf.

Here is the critical part: user assignment gates access at two levels. First, it controls which users can authenticate to the agent itself. Second, and less obvious, it also gates downstream resource access. If a user is not explicitly assigned to a downstream API or resource, the agent cannot access that resource on behalf of that user—even if the agent's identity is assigned to that API. User assignment is not negotiable at any layer of the call chain.

If you do not require assignment, Entra will still respect the OAuth 2.0 consent framework. However, it will allow any user in your tenant (or any user in a federated tenant, if you have configured cross-tenant access) to attempt authentication. The app sees the request, asks for consent, the user grants it (or the admin pre-consents), and the app gets a token. User assignment closes that loophole. It says: "No request reaches this workload unless the requester is already in my approved list—and no downstream resource request on behalf of that user will succeed if the user is not approved there either."

For AI agents deployed at scale across teams or business units, user assignment is your guard rail. Without it, you are depending on the app and downstream APIs to reject requests from unknown principals. The better defense is to never admit an unapproved principal to the conversation in the first place, and to enforce that control consistently across all resources the agent might access.

Important: User assignment requirement works for both Agent Identity Blueprints and individual agent identities. However, there is currently no Entra Admin Center UX that exposes user assignment functionality — only the Microsoft Graph API. For practical user assignment at scale, consider using Access Packages to facilitate and manage user assignments for AI agents. Another limitation worth mentioning is that at time of writing of this article, only Agent Identity Blueprints support custom roles definitions.

Conditional access as authorization policy

Conditional access is a policy engine that controls token acquisition. Unlike app roles or group claims, which are attributes embedded in a token, conditional access is evaluated before the token is issued. If a policy is violated, the agent does not get a token.

Here are concrete examples of conditional access for AI agents:

Custom Security Attribute filters: "If the app is tagged with Agents.Approved:True then allow access." The agent cannot acquire a token unless it is tagged as approved.
Risk-based controls: "If Entra's identity protection detects a risky sign-in pattern, require additional verification or deny access." In on-behalf-of type of acces, the user's authentication context and user's offline calculated risks are evaluated (unusual location, impossible travel, leaked credentials, etc.), and access is blocked if that evaluation crosses threshold. In autonomous agent access the agent's risk is evaluated and access is blocked if agent's risk crosses defined threshold.
Device compliance: "The device must be compliant with Intune policies." If the user is invoking the AI Agents from a device that is not enrolled or is marked non-compliant, the request is blocked.

Conditional access distinguishes two data access patterns that are critical for AI agents:

Autonomous access: The agent acts on its own behalf (application flow). Conditional access evaluates the agent's context (where it is running, what device it is on, what time it is).
On-behalf-of (OBO) user access: The agent acts on behalf of a user. Conditional access evaluates the user's context (where the user is, their device, their authentication method), not the agent's context.

Critical limitation: At the time of writing, Conditional Access accounts for the User (subject) and Target (resource), but not the AI Agent (actor) - when the agents accesses data on-behalf-of the user. This means CA policies cannot directly distinguish between two different agents making requests in the same context - the same user is invoking two different agents, and both happen to require a token to access Work IQ, the conditional access sees these requests identically.

See Conditional Access for Agents in Microsoft Entra and Recommended policies for autonomous agents for detailed policy patterns.

The sharp edge is timing. Conditional access gates token acquisition. If your agent acquires a long-lived token and then starts running outside the approved perimeter, the existing token still works. Conditional access is a gate at the door, not a checkpoint at every step. If you need continuous context verification, you need a different mechanism.

App roles as delegated authorization claims

App roles are a mechanism for the application, or the AI agent, to define its own authorization model. You define a set of roles in your app registration (or Agent Identity Blueprint). You assign users, groups, or service principals to those roles. When the principal authenticates, Entra puts the role membership in the roles claim of the ID token (or the access token, depending on how you configure the app).

For a human-facing app, this is straightforward. Your app checks: "Is the user in the Manager role? If yes, show the budget page. If no, hide it." Entra does the assignment; your app does the enforcement.

For an AI agent, the model is the same. You can assign humen to a role defined by the Agent Blueprint. In this case, your AI Agent can take authorization decisions for what funcitonality should be avialable to the user. Or, in case of the autonomous agent, you assign the agent's identity to a role defined by downstream API. Then, when your agent acquires a token on behalf of itself (application flow), that token contains the roles assigned to the service principal. Your APIs can inspect the token and make authorization decisions.

Here is an example. You have an agent that needs to read data from one API and another agent that needs to read and write. You define two app roles in the API app registration: DataReader and DataWriter. You assign the read-only agent's service principal to the DataReader role. You assign the read-write agent to the DataWriter role. When each agent calls your API, your API code checks the roles claim. If the token does not include DataWriter, the write operation fails.

Current UX limitations: The Entra Admin Center does not directly expose a UI for defining roles on Agent Identity Blueprints. Roles can be defined and managed via the app manifest. Role assignment to users and groups can be done via the Microsoft Graph API or, more scalably, via Access Packages.

Important distinction: While the "require user assignment" property exists for Agent Identities, there is no real application scenario where interactive authentication to an Agent happens outside of the Agent Identity Blueprint. The Agent Identity Blueprint is the object that defines the authentication and authorization contract for interactive authentications. The way to add role assignments for an Agent Identity Blueprint is via Access Packages (Add Applications). Requiring explicit role assignment for individual agent identities makes sense in an autonomous agent-to-agent interactions where you want strict controls over the autonomous invokation of AI Agents.

App-only roles: App-only roles are defined on the Blueprint and can be assigned to other agents or clients. When assigned to other workloads, these roles appear in the access token with the Blueprint as the audience (aud claim). This allows fine-grained authorization delegation between agents.

The important detail is that your protected API must be configured to emit roles in the access token. This requires a specific configuration step. Many teams forget it. The app roles exist, the assignment exists, but the token arrives empty because the app registration does not emit roles into tokens meant for APIs.

Also note: app roles are defined per app registration, not globally. If you have two APIs, each needs its own set of roles. There is no central app role store.

Group membership claims as attribute-based gates

Group membership claims are different from app roles. When you emit group claims, Entra places the groups that the principal belongs to directly into the token.

Here is the distinction. App roles are defined by the application and assigned by Entra admins within the scope of that app registration. Group claims are based on the broader Entra directory. The principal is a member of the group regardless of the app. The app just asks: "What groups is this principal a member of?" Entra answers by listing them in the token.

This is useful for attribute-based access control (ABAC). Imagine your organization has groups like Sales-Americas, Sales-EMEA, Engineering, and Finance. You assign users and workload identities to these groups. Your API receives a token, extracts the groups claim, and makes decisions based on group membership. "If the token contains the Sales-Americas group, grant access to the Americas sales data. Otherwise, deny."

The value of group-based authorization is that it decouples application-specific roles from organizational structure. If you need to add a new group or restructure existing groups, you do not need to change app role definitions. You adjust group membership. The group claim mechanism is still sending the data; your API just interprets it differently.

There is a configuration step here too. You must tell Entra to emit group claims into tokens for a specific app. By default, groups are not included. Once enabled, Entra sends the group IDs (and optionally display names, but prefer IDs for immutability).

Important: Overage limits and scope configuration. When you enable group claims, you must configure scope carefully. Entra has fixed limits on how many group claims can fit in a token:

OIDC (OpenID Connect): 200 groups maximum
SAML: 150 groups maximum

If a principal belongs to more groups than the limit, Entra sends an "overage claim" instead of individual group IDs. Your API then needs to call Microsoft Graph to fetch the full list. This adds latency and complexity. To avoid overage, emit only "assigned groups" (groups explicitly assigned to the application / blueprint). Be explicit about which groups matter for authorization decisions, and assign only those groups to the target app or agent identity blueprint. This keeps tokens small, predictable, and avoids the overage claim penalty.

See Configure group claims and app roles in tokens for detailed guidance on group claim scope and immutable identifiers.

Access packages as the unified control plane

Access packages are where the other mechanisms converge. An access package is not just governance UI. It is programmable policy choreography. When you assign a principal to an access package, you can configure what happens automatically: group membership additions, app role assignments, Azure role assignments, and so on. All of it coordinated, all of it time-bounded, all of it auditable.

For an AI agent, access packages are a control plane. You define an access package called "Agent-Production-Access". When you assign an agent's service principal to that package, Entra automatically adds the service principal to the groups that the agent needs, assigns the correct app roles to the agent, and even delegated permissions grants (consent) for downstream APIs and MCP Servers. When the access expires, all of it unwinds. The groups are removed. The app roles are stripped, the consent is undone. The agent loses access.

This is different from manually assigning groups and roles one by one or going through admin cosnent workflow. With access packages, you are declaring a coherent policy: "This is what production access means for this type of workload. If the workload is approved, give it everything in this package. If it is denied or if the time expires, take everything away." The access package is a unit of authorization. It is atomic in the sense that you do not pick and choose which parts of it to apply. It is an all-or-nothing proposition.

For enterprises running multiple AI agents, access packages scale the authorization story. You create one access package per authorization context (production, staging, read-only partners, etc.). You assign agents to packages based on their needs. Governance reviews the packages on a schedule and approves or denies. The machinery runs itself.

There is also integration with approval workflows. An access package can require approval before assignment. You can route approvals to a specific manager or group. You can set expiration dates and schedule re-approval. For AI agents running in production, this is the audit trail that compliance teams expect. "Show me who approved this agent to have access to production data and when that approval expires."

Best practices on group emit scope and immutable identifiers

When you enable group claims, you need to decide: should Entra emit all groups the principal is a member of, or only assigned groups?

The answer is clear: use only groups assigned to the application. In a typical enterprise environment, grown over the yers, single user can be member of several thousands of groups. You cannot have a token with six thousand groups in it. And it makes no sense to go over six thousand groups to make authorization decision. Choosing "assigned groups" is tighter and mandatory for production. You explicitly assign the groups relevant for this app to that app. Other groups the principal happens to belong to stay out of the token. This keeps tokens predictable, avoids overage claims, and simplifies authorization logic.

Immutable identifiers are a separate but equally important consideration. Entra can emit group display names or group IDs in the token. Display names are human-readable but fragile. If a group is renamed, the token still carries the old display name until the token expires. Your API might silently fail to recognize the group and deny access. Or worse - someone may create a group with name that they will grant them access to the app. Group IDs are immutable. A group ID never changes, even if the display name changes. For production authorization logic, prefer group IDs. Your API logic becomes:

if token.groups contains "80d61f4e-4c9e-4f8f-9e1f-2e8f3d5c6b7a":
  grant access
else:
  deny

Not:

if token.groups contains "Sales-Americas":
  grant access
else:
  deny

The first version survives a group rename. The second does not. For large organizations managing many agents and APIs, using immutable group IDs and assigned-only scope is the only way to keep authorization logic maintainable and reliable at scale.

Composing the authorization stack

These mechanisms do not compete. They stack. Here is a realistic composition:

Requiring explicit assignment gates whether the principal can even attempt authentication.
Conditional access policies check location, device, and other context.
The token arrives with app roles and group claims embedded.
Your API inspects the token, checks app roles and groups, and makes fine-grained decisions.
All of this is orchestrated through an access package that defines the coherent policy for a given context (production, partner, read-only, etc.).

Each layer has a different trust surface. User assignment is coarse. Conditional access is context-based. App roles and groups are attribute-based. Access packages are policy-coordinated. Together, they form a defense in depth.

When you are designing authorization for an AI agent, ask yourself:

Should this agent be able to authenticate at all right now? (User assignment)
Under what conditions (location, device, time) should token acquisition be allowed? (Conditional access)
If the token is issued, what roles and group memberships should it carry? (App roles and group claims)
How is the agent's access provisioned, reviewed, and revoked? (Access packages and lifecycle management)

If you can answer each question with a specific, enforceable policy, you have authorization architecture. If you are relying on the API layer alone to deny requests, you are carrying unnecessary risk.

References

Flexibility with admin consent in Entra: how to scale consent flows for AI agents

Anton Staykov — Tue, 25 Aug 2026 11:43:00 +0000

Most organizations treat tenant-wide admin consent in Microsoft Entra as a binary decision. Either a central identity team approves every request, or somebody receives a broad administrative role so the queue can move faster.

That is a false choice.

Microsoft Entra supports a more precise control model: define which consent requests are acceptable in an app consent policy, bind that policy to a custom directory role, and delegate only the authority to approve requests inside that envelope. The role action that makes this possible is microsoft.directory/servicePrincipals/managePermissionGrantsForAll.{id}, where {id} identifies the policy that constrains the consent authority.

That is not a smaller version of Global Administrator. It is a different architectural idea: delegate the decision without delegating the directory.

AI agents make this distinction urgent. As organizations create more agent identities and authorize them against Microsoft Graph and other APIs, consent stops being an occasional setup task. It becomes a recurring control-plane operation. Scaling that operation with broad roles is the identity equivalent of solving traffic congestion by issuing everyone a master key.

The usual admin consent model does not scale

Tenant-wide admin consent is deliberately sensitive. A grant can authorize an application to access organizational data or perform privileged operations across the tenant, so Microsoft recommends reviewing the requested permissions carefully before granting it (grant tenant-wide admin consent).

The operational response is usually centralization. Every request lands with a small identity or security team. That team validates the application, checks the requested permissions, finds the business owner, and either approves or rejects the request.

Centralization gives you consistency, but it also creates a queue. The queue grows with every SaaS integration, internal application, automation workload, and AI agent. Eventually the organization reaches for a built-in role such as Application Administrator or Cloud Application Administrator to distribute the work.

That relieves the queue by expanding authority. It does not make the consent decision more precise.

Microsoft Entra already has a control surface for that precision. It is just underused.

An app consent policy is a permission envelope

An app consent policy describes the conditions under which a consent event is allowed. A policy contains one or more include condition sets and can contain exclude condition sets. A request must match at least one include condition set and must not match any exclude condition set for the policy to pass.

That evaluation model matters. You are not handing a delegate a list of instructions and hoping they follow it. You are placing a policy boundary in the authorization path.

The condition sets can describe characteristics such as the permission type, the resource application, specific permissions, client applications, and publisher status (permission grant condition set resource). This lets an organization express consent envelopes such as:

delegated Mail.Read and Files.Read permissions for Microsoft Graph,
selected application permissions exposed by one internal finance API,
permissions requested only by explicitly identified client applications,
delegated permissions from verified publishers, with sensitive resources excluded.

The important word is selected. The policy does not need to authorize every permission exposed by an API. It can describe the exact delegated scopes and application roles the organization has decided are appropriate for this delegation model (manage app consent policies).

Today, Microsoft exposes this policy model through Microsoft Graph. The relevant resources are permissionGrantPolicy and permissionGrantConditionSet, exposed under /policies/permissionGrantPolicies (manage app consent policies with Microsoft Graph).

The custom role binds authority to the envelope

The policy defines what may be approved. The custom role defines who may approve it.

Microsoft documents a specific custom-role permission for tenant-wide admin consent:

microsoft.directory/servicePrincipals/managePermissionGrantsForAll.{id}

The {id} suffix is not decoration. It binds the role permission to an app consent policy. The role assignee can grant tenant-wide consent for delegated permissions and application permissions only when the consent request satisfies that policy (app consent permissions for custom roles).

That gives architects a much better delegation primitive than "make this person a Cloud Application Administrator." The delegate receives a defined consent capability, not general application administration authority.

For example, a data platform team could receive authority to grant a fixed set of delegated scopes against an internal analytics API. A Microsoft 365 integration team could receive a different role tied to a policy for a small set of approved Graph permissions. Neither team needs a role whose authority extends across unrelated application-management operations.

Custom roles and app consent permissions require Microsoft Entra ID P1. The Entra admin center does not currently support adding these app-consent permissions to a custom role definition, so this configuration is available through Microsoft Graph rather than the Entra admin center UX (license and tooling requirements). That is implementation friction, but it does not weaken the control model.

Policy authorship and consent execution are different jobs

The strongest version of this architecture separates two responsibilities.

The central identity or security team authors the permission envelope. It decides which resource applications, delegated scopes, application roles, client properties, and exclusions belong in the policy. That team also controls the custom role definition and its assignments through the documented Microsoft Entra role-management interfaces (create a custom role).

The delegated administrator evaluates individual requests and grants consent only when Entra determines that the request fits the referenced policy.

Those are not the same privilege. Microsoft exposes separate custom-role permissions for creating, reading, updating, and deleting permission grant policies, distinct from managePermissionGrantsForAll.{id} (managing app consent policies through custom roles). A consent delegate should not automatically receive policy-authoring permissions.

That separation is the control.

If the same operator can widen the allowlist and approve the newly allowed request, the policy becomes a speed bump. If one team defines the envelope and another operates inside it, the policy becomes an enforceable delegation boundary.

Watch for alternate paths around the policy

There is one architectural trap worth stating plainly: app consent policies are not the only authorization mechanism that can allow a principal to grant permissions.

Microsoft documents that policies are evaluated independently and that a principal needs only one authorization path that permits a consent event. Ownership of a resource service principal and broad Microsoft Graph application permissions can provide other ways to create grants in some scenarios (multiple policies or authorization mechanisms).

That means the restricted role is only as restricted as the delegate's effective authority.

Do not combine the policy-bound consent role with broad application-management permissions and then describe the result as least privilege. Review the delegate's other directory roles, Microsoft Graph permissions, ownership assignments, and group-derived access. The consent policy should be the intended authorization path, not one path among several wider ones.

This is also why role naming matters. "Finance API Consent Approver" communicates a bounded function. "Application Admin Lite" invites future privilege creep. Names do not enforce security, but they tell future operators whether a role is a contract or a convenience.

A domain-based consent operating model

The practical enterprise model is not one policy for every application and not one policy for the entire tenant. Both extremes create maintenance problems.

Define envelopes around stable trust boundaries. A boundary might be a business domain, an API platform, a class of low-impact delegated permissions, or a controlled set of client applications. The condition-set model supports matching on multiple properties, so the policy can reflect more than a permission name alone (permission grant condition set properties).

Then assign the corresponding custom role to administrators who understand that domain. They can evaluate business purpose and operational context without receiving unrelated directory authority.

This changes the central identity team's job. It stops being the human endpoint for every consent request and becomes the designer of consent boundaries. The team owns policy quality, role lifecycle, exception handling, and periodic review. Domain administrators operate within the encoded boundary.

The result is not decentralized consent without governance. It is federated consent with a centrally defined authorization ceiling.

AI agents turn a useful feature into an architectural requirement

Microsoft Entra Agent ID supports delegated and application permission models for agents. Delegated authorization is represented by an oAuth2PermissionGrant, while application authorization is represented by an appRoleAssignment; Microsoft also documents direct creation of these objects and consent-based flows for granting agents access (grant agents access to Microsoft 365 resources).

That means agent adoption feeds the same consent control plane already used for applications, but at a different operational scale. A blueprint may produce many agent identities, and different agents may need different access as they move from experimentation into production (Agent ID key concepts).

The wrong response is to multiply broadly privileged administrators at the same rate.

The better response is to decide which permission combinations are routine, defensible, and delegable, then encode those combinations in consent policies. High-risk or unusual requests stay with the central authority. Known patterns move through policy-bound delegates.

This complements the argument in Why consent is the trust contract for Entra Agent ID. Consent still answers who authorized an agent, for which resource, and with what permissions. Granular delegation answers the next operational question: who is trusted to make that authorization decision without receiving power over the rest of the tenant?

There is an important current boundary. Microsoft states that custom Microsoft Entra roles cannot be assigned to agent identities (Microsoft Entra role assignments for agent identities). This pattern therefore does not make an AI agent the holder of the restricted consent role. It makes the consent process around AI agents more scalable for supported human role assignees.

The question this architecture creates

Once consent policy becomes an enforceable envelope, a more interesting question appears.

What if an AI agent could assess a consent request, inspect the requested permissions and business context, compare the request with organizational policy, and recommend approval or rejection? What if, one day, the platform supported that agent making the decision inside a boundary it could not rewrite?

That is not the capability described here. Current Agent IDs cannot hold custom Entra roles, and a probabilistic reasoning system should not be mistaken for an authorization boundary (Agent ID authorization restrictions). But granular consent delegation gives that future discussion a serious starting point. The policy remains deterministic. The permission ceiling remains centrally owned. The assessment could become intelligent.

The immediate opportunity is less speculative and more valuable: stop treating admin consent as authority that can only be centralized or broadly delegated. Microsoft Entra already lets you define the exact consent envelope and hand out only the key that fits that lock.

As AI agents increase the volume and variety of consent decisions, that flexibility stops being an obscure role-management feature. It becomes part of the architecture.

References

Dynamic client registration and CIMD are not a trust framework

Anton Staykov — Mon, 17 Aug 2026 10:37:00 +0000

The MCP specification ships with a strong opinion about how AI clients should onboard with authorization servers: dynamically, at runtime, without pre-coordination (MCP authorization spec). The AI community has largely nodded along. Enterprise security teams have largely not been consulted.

That mismatch is the subject of this article.

DCR and CIMD are genuinely useful protocol mechanisms. They are not a trust framework. And in an era where supply chain attacks are the dominant enterprise threat vector, confusing the two is a governance failure waiting for a specific client name to trigger it.

What DCR was designed to remove

RFC 7591 - OAuth 2.0 Dynamic Client Registration Protocol solves a real problem. The traditional OAuth onboarding sequence requires a developer to pre-register their client application with the authorization server, receive a client_id and client_secret, configure redirect URIs, and coordinate with whoever manages the identity provider before a single token can flow. For SaaS products, open developer ecosystems, and multi-tenant platforms, this ceremony is expensive. Teams wait days for provisioning. Integration partners hit identity-team backlogs. CI pipelines stall on human approvals.

DCR automates the ceremony. The client POSTs a JSON body describing itself to the authorization server's registration_endpoint. The server returns a client_id and client_secret immediately. No human approval. No pre-coordination. Developer velocity restored.

That is a genuine improvement in the right context. Public MCP servers, open developer tooling, and hobbyist integrations benefit from it directly. The friction reduction is real, and dismissing it is wrong.

The problem is not the protocol. The problem is the assumption that registration equals authorization, and that authorization equals trust.

What CIMD adds to the picture

Client Information Meta Data (CIMD) refers to the structured metadata fields a client submits in the DCR request, and through RFC 7592 (Dynamic Client Registration Management), the management endpoint that lets a registered client later read back and update its own registration record.

The metadata fields are richer than they appear at first. A client can declare its client_name, client_uri, redirect_uris, grant_types, scope, logo_uri, and most interestingly a software_statement (RFC 7591 §2.3). A software statement is a signed JWT issued by a third party the authorization server trusts, asserting facts about the client software: who built it, what version it is, what it is intended to do. It is the closest thing RFC 7591 has to attestation.

CIMD improves signal quality. It gives authorization servers structured, machine-readable metadata to work with. It makes client inventory possible in principle: if you log registrations, you at least know the name each client claimed. Software statements, when an authorization server validates them against a trusted issuer, move the model from "self-asserted identity" to "third-party asserted identity."

The critical word is when. Software statement validation is optional in RFC 7591. Most MCP server implementations do not enforce it. A client that omits the software_statement field registers exactly as successfully as one that includes it. The registration endpoint cannot distinguish a vetted corporate tool from a novel command-line script someone assembled over a weekend and pointed at your server.

CIMD raises the quality of information available at registration time. It does not answer whether your organization approved this client to exist here.

The enterprise security gap

Security teams in regulated industries (financial services, healthcare, critical infrastructure, government) operate on a fundamentally different assumption about software trust than DCR's default model. They run approved-software programs. Patch management is gated on testing and change-board approval. In the most security-mature environments I have worked in across thousands of enterprise security conversations, even Windows Updates are staged, validated, and controlled before rollout to the fleet.

This is not bureaucratic paranoia. It is the appropriate operational posture given how supply chain attacks actually work.

SolarWinds demonstrated that a trusted vendor's signed software update is a viable attack vehicle. CVE-2024-3094 (XZ Utils) showed that a two-year social engineering campaign can insert a backdoor into a compression library that ships inside essentially every Linux distribution. The lesson from both is not "trust nothing." The lesson is that how you establish and revoke software trust matters as much as whether a signature is present, and that self-asserted identity for software is precisely the attack surface adversaries aim for.

Against that backdrop, consider what unrestricted DCR on an enterprise MCP server looks like. Any AI client (any command-line tool, any agentic orchestrator, any LLM-driven system) that discovers the server's registration_endpoint can register itself, receive credentials, and start calling your server's tools. The server knows the client's claimed client_name. It does not know whether your security team reviewed the client's code, whether the vendor passed your procurement process, whether the version running is the one that was reviewed, or whether the registration request is originating from inside your network perimeter or from an endpoint that was compromised last week.

The SOC analyst's question is not theoretical: "Show me every MCP client registered on this server, who approved each one, under which policy, and when that approval was granted." Unrestricted DCR makes that question unanswerable, or worse, the answer is "anyone who sent a POST to the right endpoint."

Small organizations face the same question. The compliance regime may be less formal, but the threat is not.

Entra's deliberate answer: explicit registration as a trust decision

This is where the AI community tends to frame a gap. It is not a gap. It is architecture.

Microsoft Entra ID has no RFC 7591 registration_endpoint. There is no URL on login.microsoftonline.com that accepts a DCR POST and returns client_id credentials at runtime. Every application that can receive Entra-issued tokens must be explicitly registered, through the Azure portal, the Microsoft Graph API, the Azure CLI, or ARM templates, by a principal holding at minimum the Application Developer role (register an application in Microsoft Entra ID).

That deliberate registration is not the end of the trust chain. It is the beginning of it. A registered application that has not been explicitly consented still receives no tokens. Consent in Entra is the authorization gate: the act that says "this application is authorized to call this API, with these permissions, under this policy." A well-named AI client with a convincing client_name and a polished client_uri gets nothing from Entra without a human trust decision in the chain. (For the full governance architecture behind this claim, see the article Why consent is the trust contract for Entra Agent ID.)

The MCP authorization specification is careful here: it states that clients SHOULD attempt DCR when the authorization server's RFC 8414 metadata includes a registration_endpoint. "Should," not "must." A well-behaved MCP client encountering an authorization server that publishes no registration_endpoint (which is what every Entra tenant presents) falls back to static registration. That fallback is the intended behavior. The friction is intentional, and its source is a governance posture, not a missing feature.

The honest tradeoff: Entra's model maximizes governance precision and eliminates runtime surprise about who can request tokens. It creates real friction for MCP clients that expect to self-register on first contact. That friction is a feature for regulated enterprise deployments. It is a genuine obstacle for open, developer-facing MCP servers where the audience is trusted developers and the stakes per registration are low. Both statements are true simultaneously.

APIM AI Gateway: the bridge, and where the gap remains

When you place Azure API Management's AI Gateway in front of your MCP server, you gain a set of controls that together approach what a governance-controlled DCR layer would look like, without implementing one. Understanding exactly what APIM provides, and what it does not, is what allows you to design the right architecture rather than assume a gap has been closed when it has not.

The first piece is discovery integration. APIM can expose the .well-known/oauth-protected-resource endpoint defined in RFC 9728, which tells DCR-capable MCP clients where to find the authorization server protecting this resource (secure access to MCP servers). When APIM points to Entra as the authorization server, the MCP client reaches Entra, discovers no registration_endpoint in Entra's RFC 8414 metadata, and falls back to static registration. The discovery flow runs correctly. The governance gate holds. APIM participates in the DCR protocol dance without becoming a DCR endpoint.

The second piece is runtime client enforcement via the validate-azure-ad-token policy. This policy accepts a <client-application-ids> block, an explicit allowlist of Entra application IDs whose tokens are valid at this gateway:

<validate-azure-ad-token tenant-id="your-entra-tenant-id"
    header-name="Authorization"
    failed-validation-httpcode="401"
    failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
    <client-application-ids>
        <application-id>approved-mcp-client-app-id</application-id>
    </client-application-ids>
</validate-azure-ad-token>

A client that was registered in Entra and consented (both explicit human decisions), but whose application ID is absent from this list, still cannot pass the gateway. That is two distinct human approval steps between "an AI client exists" and "that AI client can invoke your MCP server tools." This is the runtime equivalent of an enterprise approved-software list, enforced at the gateway rather than in application code.

For scenarios where Entra registration still introduces too much friction (third-party client integrations, short-lived automation, partner tooling), APIM's subscription key model is the highest-control alternative. Every MCP client consumer receives a key provisioned explicitly by an APIM administrator. No dynamic discovery. No self-registration. Full explicit provisioning per consumer, with gateway-level revocation that does not wait for a consent withdrawal to propagate through the identity layer.

The observability dimension is underweighted in most governance architecture conversations. APIM routes all MCP tool invocations through a single plane with Application Insights integration and the llm-emit-token-metric policy for per-consumer token tracking. The SOC analyst's question, "show me every client calling this server, what it consumed, and when", becomes answerable from a single observability plane. That audit trail is precisely what unrestricted DCR alone never provides.

The honest gap deserves explicit naming. Neither APIM nor Entra today offers a governance-controlled RFC 7591 registration endpoint: a /register that issues credentials only to clients that have passed a policy gate: an Entra consent check, an access package approval, or a security review workflow. APIM and Entra together approximate this behavior through a different mechanism: explicit Entra app registration as the consent prerequisite, gateway policy as the runtime enforcement layer. The interoperability friction with DCR-native MCP clients is real. The architectural slot for a "governed DCR endpoint" is currently unoccupied in the Microsoft stack.

That gap is worth naming because it is where the tooling will likely evolve. An architecture where APIM exposes an RFC 7591-compliant /register endpoint that, on receiving a DCR request, triggers an Entra app registration, initiates an admin consent workflow, and optionally assigns an access package, before returning credentials to the registering client, would close it elegantly. That architecture does not exist today as a native product feature. What exists is the layered governance model described above.

A governance stack, not a binary choice

The practical architecture decision is not "DCR or no DCR." It is: what governance controls stand between a client expressing interest and a client receiving credentials?

For open, developer-facing MCP servers where the audience is trusted developers, the data sensitivity is low, and the expected client population is diverse and changing, DCR with software statement validation and a lean consent model is appropriate. Lean does not mean absent: even here, logging registrations, validating software statements when present, and auditing active clients periodically are the minimum defensible posture.

For enterprise MCP servers that expose organizational data, internal APIs, financial workflows, or records subject to regulatory requirements, the bar is different. Every client should be named. Every registration should be a deliberate trust decision. Every token scope should be consented explicitly under a policy that your security and governance teams own.

APIM plus Entra delivers that model today. Entra's explicit registration and consent layer ensures no client receives tokens without a human decision in the chain. APIM's AI Gateway enforcement layer ensures no token-bearing client bypasses your runtime policy. The observability layer ensures that "who approved this, with which permissions, and when" remains answerable across the full client lifecycle.

CIMD metadata enriches the picture on the way in: software statements, declared grant types, client URIs. Use them where your authorization server or gateway policy can act on them. Do not treat "richer metadata at registration time" as a substitute for governance state. Those are different properties, and conflating them is the precise mistake that makes a SOC analyst's life difficult six months after a pilot launches.

DCR is useful. CIMD is useful. Neither is a trust framework. The security teams that built enterprise software approval programs did not do it for the friction. They did it because supply chain attacks are real, and the moment you stop asking "who approved this software to exist here" is the moment a well-named binary with a convincing client_name receives credentials to your organizational data.

APIM AI Gateway and Entra's explicit registration model is the closest the Microsoft stack comes today to answering that question at MCP server scale. The remaining gap is a named target. The governance floor is already in place.

References

Why consent is the trust contract for Entra Agent ID

Anton Staykov — Wed, 12 Aug 2026 11:07:00 +0000

If your AI agent can read customer mailboxes, create directory objects, or call internal APIs, your real architecture question is not "can it authenticate?" The hard question is "who authorized this, under which policy, for how long, and with which guardrails?" In Microsoft Entra, that question is answered through permissions and consent. That is why consent is not a user-experience detail. It is the trust contract.

This matters even more for agent identities. Microsoft Entra Agent ID deliberately treats agents as a special operational class, with explicit authorization controls and blocked high-risk privileges rather than unconstrained app-like power (authorization model, Graph overview for Agent ID). If your mental model is still "grant broad access once and move on," your governance will fail faster than your pilot succeeds.

In [[A-transformational-AI-agent-does-not-start-with-the-permissions-it-needs]], I argued that strong agent platforms start narrow and earn scope in context. This article is the governance layer under that claim: why consent is the control surface, how to operate it at enterprise scale, and how access packages turn theory into an auditable runtime model.

Consent is authorization, not authentication

Consent in Entra is the act that authorizes an application identity to access a protected resource with specific permissions (user and admin consent overview, permissions and consent overview). Authentication answers "who are you?" Consent answers "what are you allowed to do against this API or resource?"

That distinction sounds obvious until production pressure arrives. Teams often secure sign-in, configure Conditional Access, and then assume the authorization problem is solved. It is not. A signed-in actor without the right consent grant is still unauthorized, and a correctly consented actor can still be over-privileged if governance posture is weak (permissions and consent overview, configure user consent).

For mixed technical leadership, this is the key reframing: consent is where legal risk, security posture, and delivery velocity intersect. It is the formal boundary between "agent capability requested" and "agent capability approved."

User consent and admin consent are different risk gates

Entra supports delegated permissions where an app or agent acts on behalf of a signed-in user, and application permissions where it acts autonomously without a user context (permissions and consent overview, grant agents access). Those two modes map to different consent paths and different blast radii.

User consent is viable when non-admin users are allowed to consent to the app and permission set by tenant policy (user and admin consent overview). Admin consent is required for application permissions and for delegated permissions that are admin-restricted or otherwise outside permitted user-consent boundaries (user and admin consent overview, grant agents access).

That is not bureaucracy. That is architecture. User consent is typically scoped to the user context. Admin consent can authorize tenant-wide impact. Treating those as interchangeable is how over-privileged agents are born.

Consent policy is a leadership decision encoded in platform behavior

Most organizations do not leave consent wide open, and they should not. Entra gives administrators tenant-wide choices: disable user consent entirely, allow only verified publishers plus selected low-impact permissions, or allow broader user consent where risk tolerance supports it (configure user consent, user and admin consent overview).

If user consent is limited, Entra can route blocked requests through the admin consent workflow so business demand is visible and reviewable instead of hidden in shadow tooling (user and admin consent overview, configure admin consent workflow). This is where governance stops being a "no" function and becomes a control function.

For leadership teams, the operational takeaway is clear: consent policy is not a tactical identity setting. It is a policy expression of enterprise risk appetite. Decide it explicitly, document it, and align agent deployment patterns to it.

Consent phishing proves whether your model is real

Consent phishing is the attack pattern where users are tricked into granting OAuth permissions to malicious applications, often through convincing app names and realistic prompts (protect against consent phishing). This is not theoretical noise. It is exactly what happens when the organization treats consent as a user-interface click instead of a control plane.

Microsoft guidance is explicit: harden user consent settings, favor verified publishers, audit app permissions, investigate suspicious grants, and integrate detection and remediation workflows (protect against consent phishing). If those controls are absent, your "agent security strategy" is just language.

A mature model assumes two truths at once: legitimate agents need controlled permission growth, and adversaries will try to exploit the same consent mechanics. Governance has to handle both.

Delegated vs application permissions for agents, with protocol constructs that matter

For agent identities, delegated mode is used when the agent acts in a user context. Application mode is used when the agent acts autonomously (authorization in Agent ID, grant agents access). That split directly affects token semantics.

In delegated scenarios, effective scopes are carried in the scp claim. In app-only scenarios, effective app permissions are carried in the roles claim (token claims for agents, grant agents access). You do not need packet-level protocol traces to govern correctly, but you do need leadership alignment that these constructs define runtime authority.

The advanced nuance for Agent ID is permission inheritance at blueprint level. This is not default behavior. Entra documents that inheritance only happens when you explicitly configure inheritable permissions on the blueprint and the corresponding permissions are actually granted on the blueprint principal (inheritable permissions concept, configure inheritable permissions).

That should drive a stricter approval posture: treat blueprint consent as baseline capability setup, not as a full production access request. Keep blueprint consent narrow, and push broader or time-bound operational access through governed assignment workflows such as access packages (access packages for agent identities).

Agent ID already blocks high-risk permission paths, by design

A healthy governance discussion should also acknowledge built-in platform guardrails. Agent IDs can use delegated and application permission models, but Entra explicitly blocks a range of high-risk Graph permissions for agents and restricts role assignment options compared to unconstrained identity types (authorization in Agent ID, Agent ID Graph overview blocked permissions).

This design choice reinforces the principle of least privilege for autonomous systems. It does not remove governance responsibility, but it reduces failure modes where someone "temporarily" grants sweeping directory control and forgets to remove it.

In plain terms: the platform is already telling you the right operating model. Narrow by default. Escalate deliberately. Keep high-risk paths off the table unless there is an explicit and supported control route.

Access packages are the practical admin-consent engine for agent scale

Consent alone is necessary, but not sufficient, when you run fleets of agents. You need a repeatable, policy-owned mechanism for requesting, approving, granting, expiring, and reviewing access. For Entra Agent ID, access packages provide that mechanism (access packages for agent identities, governing agent identities).

This is why I keep connecting this to [[Access-Packages-Are-the-Control-Plane-for-Entra-Agent-ID-Permissions]]. Access packages let you operationalize consent and authorization as workflow, not as ad hoc privilege assignment. They can include directory roles, OAuth delegated and application permissions, and group memberships in one governed package (access packages for agent identities).

Crucially, policy can require one, two, or three approval stages, with explicit approver definitions and decision timeouts (approval policy settings, access package create stages). That means you can model governance depth based on data sensitivity, not gut feel.

Dynamic approvals, SoD checks, and custom logic make governance adaptive

Static approver lists are often too rigid for enterprise reality. Entra entitlement management supports dynamic approval determination through custom extensions and Logic Apps integration, so approvers can be derived through business logic at request time (dynamic approval, Logic Apps integration).

Separation-of-duties controls let you mark access packages or groups as incompatible, preventing users or identities with one assignment from requesting conflicting assignments (SoD checks). This is the difference between "we approved safely once" and "we remain safe over time."

If you need one sentence for the board slide, use this: access packages are not just an approval screen. They are a programmable authorization lifecycle with governance state.

A practical operating model for mixed technical leadership

If you lead a platform team, security team, or product portfolio touching agent identities, this model is battle-tested and aligned to Microsoft guidance:

Start with narrow required access on blueprints and explicit inheritable-permission design (inheritance is opt-in, not automatic), so admins can review baseline intent clearly and avoid turning blueprint consent into broad standing access (inheritable permissions concept, configure inheritable permissions).
Set tenant consent policy intentionally (usually verified-publisher plus low-risk where possible), and force higher-risk asks through admin review paths (configure user consent, user and admin consent overview).
Route runtime growth through access packages instead of direct permanent grants, including approver stages, SoD, and expiry settings (access packages for agent identities, approval policy, SoD checks).
Treat sponsor and owner accountability as first-class controls, because governance is not complete if no human is accountable for extension and renewal decisions (governing agent identities).
Assume consent abuse attempts and instrument for response, including consent-phishing hardening and suspicious-grant investigation workflows (protect against consent phishing).

This operating model gives engineering enough autonomy to ship and iterate, while preserving the control evidence leadership needs for audit and risk committees.

The core decision

You can run agents on standing privilege and hope nothing goes wrong. Many teams do exactly that during pilots. It looks fast right until the first real governance review.

Or you can run agents on governed consent, with policy-owned approval paths, explicit token authority constructs, and time-bound assignment lifecycle. That model scales beyond demos because it aligns with how Entra is designed to authorize applications and agents (permissions and consent overview, authorization in Agent ID, access packages for agent identities).

That is the underrated shift in enterprise agent architecture right now: the winning platform is not the one with the most tools. It is the one where consent remains the trust contract, even as agent capability grows.

References

From JWT-SVID to Entra Agent ID: a working SPIFFE PoC

Anton Staykov — Thu, 06 Aug 2026 11:19:00 +0000

The architecture diagram was the easy part.

In Your SPIFFE workload can authenticate as an Entra Agent ID, but mind the trust gap, I argued that SPIFFE and Microsoft Entra Agent ID belong on opposite sides of a narrow trust contract. SPIRE proves which workload is running. Entra decides which governed agent identity that workload may use. A federated identity credential connects those statements through an exact issuer, subject, and audience match, which is how Microsoft Entra workload identity federation validates an external JWT.

That article described the architecture and its trust gap. This one runs it.

The agentid-spiffe proof of concept deploys a complete agent loop with SPIRE, public OIDC discovery, Microsoft Entra Agent ID, and a downstream Microsoft MCP Server for enterprise call. The interesting result is not the chat interface or the model. It is the moment a JWT-SVID issued to one attested process becomes the client assertion for an Agent Identity Blueprint, without a client secret or certificate copied into the workload.

This is a conceptual walkthrough with selected configuration and code. It is deliberately not a SPIRE deployment guide. Follow the repository README to run the sample. Here, we are going to trace the identity as it changes hands.

Five SPIFFE concepts in one minute

A trust domain is the administrative and cryptographic boundary within which SPIFFE identities are issued. Its name forms the authority portion of every SPIFFE ID. The PoC uses poc.local, so its workload identity begins with spiffe://poc.local/. SPIFFE defines that URI as the stable name of a workload, independent of an IP address, host name, or cloud provider account (SPIFFE concepts).

The SPIRE Server is the authority for that trust domain. It stores registration entries, evaluates attestation results, and signs the identity documents issued inside the domain. The SPIRE Agent runs near workloads, attests to the server as a node, exposes the local Workload API, and performs workload attestation before returning identity documents to a process (SPIRE concepts).

Workload attestation is the decision that connects runtime evidence to a registered SPIFFE ID. In this sample, the SPIRE Server registers a Unix selector for a process running as UID 0. When the FastAPI process calls the local Workload API, the SPIRE Agent evaluates that evidence and returns the identity registered for the matching selector. SPIRE documents selectors as the attested properties used to match a workload to a registration entry (registering workloads).

The returned identity can take two common forms. An X.509-SVID is a certificate suited to mutual TLS. A JWT-SVID is a signed bearer token whose sub is the workload's SPIFFE ID and whose aud names the intended recipient (JWT-SVID specification). This PoC needs the JWT form because Microsoft Entra accepts an external JWT as the client assertion in its federated client credential flow.

That is all the SPIFFE theory required for this walkthrough. The rest is the handoff.

The components in play

The PoC places several processes in one Azure Container App image so the identity path is easy to inspect. That packaging is a lab convenience, not an architectural recommendation (repository architecture).

Inside the container, five components matter:

The SPIRE Server owns the poc.local trust domain and signs JWT-SVIDs.
The SPIRE Agent exposes a Unix socket implementing the Workload API.
The SPIRE OIDC Discovery Provider publishes the JWT signing keys.
FastAPI retrieves the JWT-SVID and performs the Entra token exchanges.
The browser SPA supplies an incoming user token when the sample runs in user-context mode.

Outside the container, Microsoft Entra holds the agent identity blueprint, its blueprint principal, the child agent identity, the federated identity credential, and the delegated grants. The final Agent ID token is passed to the Microsoft MCP Server for enterprise. The model call proves that the token is usable, but it is downstream of the identity mechanism we care about.

SPIFFE workload plane                     Microsoft Entra control plane

+---------------------------+            +-----------------------------+
| FastAPI agent workload    |            | Agent Identity Blueprint    |
+---------+-----------------+            +-------------------+---------+
          |                                                  |
          | runtime evidence                                 |
          v                                                  |
+---------+-----------+                                      | Federated Identity
| SPIRE Agent         |                                      | Credential
| Workload API        |                                      |
+-------+-------------+                                      |
        | attestation                                        |
        v                                                    |
+-------+-----------------+      signing keys       +--------+--------+
| SPIRE Server            |------------------------>| OIDC metadata   |
| issues JWT-SVID         |                         | and public JWKS |
+-----------+-------------+                         +-------+---------+
            |                                               ^
            | short-lived JWT-SVID                          |
            v                                               | validates
+-----------+-------------+  JWT-SVID + fmi_path            |
| FastAPI agent workload  |-------------------------------->|
+-------+-----------------+                                 |
        ^                                                   |
        | T1 exchange token                                 |
        +---------------------------------------------------+
        |
        | T1 as child assertion
        v
+-------------+-------------+                +-----------------------------+
| Child agent identity      |--------------->| Downstream MCP resource     |
| requests resource token   |    Agent ID    | validates Entra token       |
+---------------------------+    token       +-----------------------------+

The diagram contains two identity planes. The SPIFFE plane ends when the workload receives its JWT-SVID. The Entra plane begins when that JWT is presented as the blueprint's client assertion.

How the process becomes a SPIFFE workload

The container entrypoint starts the SPIRE Server, creates a join token for the co-located agent, and registers one workload entry (entrypoint source):

spire-server entry create \
  -parentID spiffe://poc.local/agent/node1 \
  -spiffeID spiffe://poc.local/agent/identity-1 \
  -selector unix:uid:0

Read that registration from right to left. A process matching unix:uid:0, attested through the registered parent agent, receives spiffe://poc.local/agent/identity-1 as its workload identity. The SPIFFE ID is not generated from the process name or container name. It is the explicit result of registration policy and attested selectors, which is the model SPIRE uses to issue identities through its Workload API (SPIRE workload registration).

The selector is intentionally broad because every process in the image runs in the same lab boundary. A production deployment would use workload and node attestors that express the real platform boundary. That decision is outside this PoC. We only need a reliably attested process from which to request the JWT-SVID.

The server configuration then defines the JWT issuer and signing profile (SPIRE server configuration in the PoC):

server {
    trust_domain = "poc.local"
    jwt_issuer = "__OIDC_ISSUER_URL__"
    jwt_key_type = "rsa-2048"
    default_jwt_svid_ttl = "10m"
}

trust_domain controls the SPIFFE ID namespace. jwt_issuer becomes the JWT-SVID iss claim. jwt_key_type makes SPIRE sign the assertion with RSA so that the token uses RS256. These values are related, but only the issuer crosses directly into the Entra configuration.

And this is where the most important interoperability detail appears.

The issuer is a public protocol surface, not a string

It is tempting to treat the federated identity credential's issuer as an identifier. Configure the same URL in SPIRE and Entra, make the strings match, and move on.

That is not enough.

Microsoft Entra documents two requirements that make the issuer an operational endpoint. First, RS256 is the supported signing algorithm for workload identity federation assertions. Other algorithms might work, but Microsoft does not test them. A robust implementation therefore needs an RS256-signed JWT, which is why this PoC explicitly configures jwt_key_type = "rsa-2048" (supported signing algorithms and issuers).

Second, the issuer must be a publicly reachable HTTPS URL that follows OIDC discovery. Microsoft Entra uses the configured issuer to retrieve the metadata and signing keys needed to validate the external token (configure trust with another identity provider). For the issuer used by this PoC, the primary discovery URL is formed by appending /.well-known/openid-configuration:

Issuer
https://<container-app-host>/spiffe-oidc

Discovery document
https://<container-app-host>/spiffe-oidc/.well-known/openid-configuration

The discovery document points Entra to the public key set:

{
  "issuer": "https://<container-app-host>/spiffe-oidc",
  "jwks_uri": "https://<container-app-host>/spiffe-oidc/keys",
  "subject_types_supported": ["public"]
}

Entra follows jwks_uri, finds the public key whose kid matches the JWT-SVID header, and uses that key to verify the RS256 signature. The private signing key remains inside SPIRE. OIDC discovery publishes only the public half required by verifiers, following the standard discovery and JWKS model (OpenID Connect Discovery 1.0).

This is why an exact iss match can still fail. The URL might be spelled correctly while the discovery document is missing, inaccessible, malformed, or pointing at a JWKS that does not contain the active signing key. In that state, Entra knows where the assertion claims to come from but cannot cryptographically prove that the issuer signed it.

The sample runs SPIRE's OIDC Discovery Provider locally, then proxies its metadata and key set through the Container App's public HTTPS origin (OIDC proxy implementation). The proxy rewrites issuer and jwks_uri to their public values, removes an empty authorization endpoint, populates subject_types_supported, and adds "use": "sig" to each published key for compatibility. It exposes both the OpenID Connect discovery path shown above and the RFC 8414 path form for an issuer containing a path:

https://<container-app-host>/.well-known/openid-configuration/spiffe-oidc

Both documents describe the same issuer and point to the same JWKS. That extra route avoids relying on ambiguous discovery behavior when the issuer itself contains /spiffe-oidc.

The OIDC endpoint is not incidental web plumbing. It is part of the credential chain. If it disappears or publishes the wrong key, the JWT-SVID stops being a credential Entra can validate.

The federated identity credential binds one workload to the blueprint

Once the public issuer works, the post-deployment configuration creates a federated identity credential on the agent identity blueprint application. It does not create the credential on the child agent identity (FIC configuration source).

The effective object is small:

{
  "name": "spire-jwt-svid-blueprint",
  "issuer": "https://<container-app-host>/spiffe-oidc",
  "subject": "spiffe://poc.local/agent/identity-1",
  "audiences": [
    "api://AzureADTokenExchange"
  ]
}

Here is a decoded JWT-SVID captured during one of the PoC runs. The signature is omitted, but the header and payload are unchanged:

{
  "alg": "RS256",
  "kid": "KNd3DSGQAvCP1U2rHUd3rBzf9oX1y7BG",
  "typ": "JWT"
}.{
  "aud": [
    "api://AzureADTokenExchange"
  ],
  "exp": 1785157382,
  "iat": 1785156782,
  "iss": "https://spiffe.proudhill-d482409c.westeurope.azurecontainerapps.io/spiffe-oidc",
  "sub": "spiffe://poc.local/agent/identity-1"
}.[Signature]

The header says that SPIRE signed the assertion with RS256 and identifies the public verification key through kid. The payload names Entra's token exchange as the only audience, carries a ten-minute validity window, exposes the public OIDC issuer, and uses the registered SPIFFE ID as its subject. Entra retrieves the issuer's JWKS, selects KNd3DSGQAvCP1U2rHUd3rBzf9oX1y7BG, verifies the omitted signature, and then evaluates the three FIC claim matches (workload identity federation mechanics).

Those three trust properties map directly to the incoming JWT-SVID:

JWT-SVID iss  == FIC issuer
JWT-SVID sub  == FIC subject
JWT-SVID aud  == FIC audiences[0]

Microsoft Entra compares those values exactly and case-sensitively when evaluating a standard federated identity credential (federated identity credential matching). The FIC therefore says something precise: a token from this public issuer, for this one SPIFFE workload, minted specifically for Azure AD token exchange, may authenticate this blueprint.

It does not grant the workload Microsoft Graph permissions. It does not authorize the model to use an MCP tool. It only replaces the blueprint's stored client secret or certificate with a short-lived external assertion. Authorization remains attached to the child agent identity and the downstream resource, consistent with the Agent ID identity and authorization model.

The application requests the JWT-SVID only when MSAL needs it

The FastAPI application opens the local SPIRE Workload API through the SPIRE Agent's Unix socket. Its assertion provider asks for one JWT-SVID with api://AzureADTokenExchange as the audience (backend source):

class SpiffeJwtProvider:
    def __call__(self, ctx=None) -> str:
        svid = self._ensure_source().fetch_svid(
            audience={self._audience}
        )
        return svid.token

That audience matters. The JWT-SVID specification recommends a single audience because a JWT-SVID is a bearer token and every listed audience becomes a potential recipient. This token exists for one purpose: presentation to Entra's workload identity federation endpoint.

The provider is passed to MSAL as a callable client assertion rather than as a static token:

blueprint_app = msal.ConfidentialClientApplication(
    BLUEPRINT_CLIENT_ID,
    client_credential={"client_assertion": _jwt_svid_provider},
    authority=AUTHORITY,
)

MSAL can invoke a callable assertion provider when it needs a fresh credential, which fits a short-lived SVID better than capturing one token at process startup (MSAL Python confidential client application). SPIRE remains responsible for issuing the workload credential. MSAL remains responsible for Entra token acquisition and caching.

`fmi_path` turns blueprint authentication into one agent identity

The first Entra request authenticates the blueprint with the JWT-SVID and asks for an exchange token scoped to one child agent identity:

result = blueprint_app.acquire_token_for_client(
    ["api://AzureADTokenExchange/.default"],
    fmi_path=agent_app_id,
)

The fmi_path value is the child agent identity's client ID. Microsoft documents that parameter as the instruction telling Entra which agent identity the blueprint is acting on behalf of (request a token for the agent identity blueprint). The result is T1, an exchange token bound to the blueprint-to-child path.

The child agent identity has no independent client secret, certificate, or FIC. The application creates a second MSAL confidential client for the child and supplies T1 through another assertion callback:

def assertion_cb(ctx=None) -> str:
    result = blueprint_app.acquire_token_for_client(
        ["api://AzureADTokenExchange/.default"],
        fmi_path=agent_app_id,
    )
    return result["access_token"]

agent_app = msal.ConfidentialClientApplication(
    agent_app_id,
    client_credential={"client_assertion": assertion_cb},
    authority=AUTHORITY,
)

From there, the flow can branch. In app-only mode, the child requests a resource token using its application permissions. In the PoC's user-context mode, it combines T1 with the incoming user's access token in an on-behalf-of exchange. Microsoft documents that the second request switches client_id from the blueprint to the child agent identity and presents both the blueprint exchange token and user assertion (Agent ID OBO protocol).

The JWT-SVID has already done its job before that branch. It authenticated the blueprint. T1 then authenticated the child agent identity. The final access token is scoped to the downstream resource and represents either the autonomous agent or the agent acting in the user's context, depending on the selected flow (authenticate and acquire tokens for autonomous agents).

That separation is the reason this is more than generic workload federation. The external workload does not become an ordinary app registration. It enters a blueprint-controlled path and emerges as a governed child agent identity.

What the PoC proves

The sample proves four useful things.

First, a JWT-SVID can serve as the real client assertion for an Entra Agent ID blueprint. Microsoft lists SPIFFE and SPIRE as a supported workload identity federation scenario, and Agent ID supports direct workload identity exchange for third-party agent platforms (supported workload identity federation scenarios, third-party Agent ID integration patterns).

Second, the SPIFFE ID maps cleanly into the FIC subject. The workload identity spiffe://poc.local/agent/identity-1 remains visible at the trust boundary instead of being translated into an unrelated shared secret.

Third, the public issuer surface is as important as the token. Federation succeeds only when the JWT iss, FIC issuer, discovery document issuer, discovery URL, JWKS location, active kid, and RS256 signature all describe the same cryptographic authority. Microsoft Entra retrieves the external keys through that OIDC issuer contract before accepting the assertion (workload identity federation mechanics).

Fourth, the identity that calls the downstream API is still the child agent identity. SPIRE authenticates the workload to the blueprint. It does not bypass Agent ID's parent-child token flow, consent, or downstream authorization model (agent identities).

What the PoC deliberately does not prove

The repository is unusually clear about its shortcuts, and that clarity matters.

SPIRE state is ephemeral. Every Container App start deletes the server and agent data, regenerating the CA material, JWT signing key, and JWT kid. Microsoft Entra can retain previously retrieved issuer metadata and keys, so exchanges can fail after a restart until its view refreshes (repository warning). This is the loudest reason not to mistake the sample for a production SPIRE topology.

The agent uses a join token and insecure_bootstrap = true, while the server and agent are co-located with the workload. Those choices remove infrastructure that would distract from the exchange, but they are explicitly marked as PoC-only in the agent configuration.

The backend also logs the full JWT-SVID to simplify troubleshooting while the FIC is being wired up (logging code). Do not carry that behavior into production. A JWT-SVID is a bearer credential susceptible to replay during its validity window, so it must not enter application logs, traces, prompts, or tool output (JWT-SVID replay considerations).

None of those shortcuts invalidate the demonstrated identity exchange. They define its boundary. The sample proves that a correctly issued JWT-SVID, signed with RS256 and backed by public OIDC discovery, can authenticate an Agent ID blueprint. It does not prove that one ephemeral container is how an organization should operate SPIRE.

The trust contract is now executable

The previous article ended with two control planes and one narrow trust contract. The PoC turns that sentence into running code.

SPIRE attests the FastAPI process and issues spiffe://poc.local/agent/identity-1 a short-lived JWT-SVID. The OIDC discovery endpoint makes the active RSA public key available at a predictable public URL. The federated identity credential authorizes one exact issuer, SPIFFE ID, and audience to authenticate the blueprint. fmi_path narrows the resulting T1 token to one child agent identity. That child obtains the final resource token under its own authorization boundary.

No shared client secret crosses the container boundary. No X.509 certificate is copied into the agent. No custom token validator is added to Entra. The bridge uses the SPIFFE JWT identity format, standard OIDC discovery, Entra workload identity federation, and Agent ID's documented blueprint exchange (workload identity federation, Agent ID token acquisition).

The issuer configuration is the hinge. It must be exact, public, standards-shaped, and cryptographically aligned with the JWT in flight. Get that right, and the SPIFFE workload can enter Entra as a governed agent identity without ever owning a long-lived Entra credential.

That is the result this PoC was built to isolate.

References

Your SPIFFE workload can authenticate as an Entra Agent ID, but mind the trust gap

Anton Staykov — Tue, 04 Aug 2026 09:13:00 +0000

SPIFFE with Microsoft Entra Agent ID sounds almost too tidy.

Let SPIRE attest an AI agent running in Kubernetes, on-premises, or in another cloud. Give that workload a short-lived SPIFFE identity. Present the resulting token to Microsoft Entra. Receive an access token for a governed Entra Agent ID. No client secret, no certificate copied into a container, no cloud-specific identity shim.

The architecture is viable. Microsoft explicitly lists SPIFFE and SPIRE among its supported workload identity federation scenarios, and Entra Agent ID supports third-party agents through direct workload identity federation.

But the clean diagram hides a trust gap.

SPIFFE proves which workload is running. Microsoft Entra decides which agent identity that workload may act as. A federated identity credential connects those two statements. If that mapping, its issuer surface, or its audience design is wrong, a short-lived token merely helps the wrong workload become the wrong agent faster.

That is the pattern worth understanding. Not "SPIFFE replaces Entra" and not "Entra understands SPIFFE natively." The real design has two identity control planes joined by one exact, case-sensitive trust contract.

SPIFFE workload plane                     Microsoft Entra control plane

+---------------------------+            +-----------------------------+
| AI agent workload         |            | Agent identity blueprint    |
|                           |            |                             |
| spiffe://example.com/     |            | FIC matches:                |
| agent/invoice-reconciler  |            |   iss + sub + aud           |
+-------------+-------------+            +--------------+--------------+
              |                                         |
              | 1. Attestation                          |
              v                                         |
+-------------+-------------+                           |
| SPIRE Server + Agent      |                           |
|                           |                           |
| Issues short-lived        |                           |
| JWT-SVID                  |                           |
+-------------+-------------+                           |
              |                                         |
              | 2. JWT-SVID + fmi_path                  |
              +---------------------------------------->|
                                                        |
                                          3. Returns T1 |
                                                        v
                                         +--------------+--------------+
                                         | Child agent identity        |
                                         |                             |
                                         | T1 exchanged for a          |
                                         | resource-scoped token       |
                                         +--------------+--------------+
                                                        |
              4. Entra access token                     |
              <-----------------------------------------+

The SPIFFE workload authenticates the blueprint.
The child agent identity is the principal authorized on downstream APIs.

SPIFFE and Entra answer different questions

SPIFFE defines a platform-neutral identity framework for software workloads. Its central identifier is the SPIFFE ID, a URI such as spiffe://example.com/agent/invoice-reconciler. A SPIFFE implementation such as SPIRE attests a workload using runtime evidence, then makes short-lived identity documents available through the SPIFFE Workload API.

Microsoft Entra Agent ID starts one layer higher. An agent identity is a specialized service principal used to request tokens, receive tokens, and act either autonomously or in a user's context. The agent identity does not hold its own credential. Its agent identity blueprint holds credentials and acquires tokens on behalf of child agent identities.

That division is useful:

SPIRE answers: is this the workload that my runtime policy registered?
Entra answers: which enterprise agent identity may this authenticated workload use, and what may that identity access?

The distinction matters because workload authentication is not downstream authorization. A valid SPIFFE identity does not grant Microsoft Graph permissions, an Azure role, or consent to an API scope. It only supplies evidence that Entra can accept as a credential for the blueprint. The resulting agent identity remains the principal that needs authorization on the target resource, a separation Microsoft also makes explicit for agent identity token acquisition.

Think of SPIRE as the passport office and Entra as the border authority. One establishes that the document belongs to a particular workload. The other decides which governed identity crosses the border and what that identity may do after entry.

Only one of the two SVID forms fits the exchange

SPIFFE defines two common forms of SPIFFE Verifiable Identity Document, and they are not interchangeable.

An X.509-SVID is an X.509 certificate in which the workload's SPIFFE ID appears as the single URI Subject Alternative Name. It is a strong fit for workload-to-workload mutual TLS. The workload proves possession of the corresponding private key while both sides validate certificate chains against SPIFFE trust bundles.

A JWT-SVID is a signed bearer JWT. Its sub claim must be the workload's SPIFFE ID, and it must contain both aud and exp. That shape fits Microsoft Entra workload identity federation because Entra's client credentials flow accepts a JWT from an external identity provider as the client_assertion (federated client credential flow).

This is the first catch: an X.509-SVID is not a federated identity assertion for this flow.

You cannot hand Entra an X.509-SVID and expect it to extract the URI SAN, validate the SPIFFE certificate chain, and perform the workload identity exchange. Microsoft documents the external credential as a JWT assertion with an issuer, subject, and audience that match a configured federated identity credential (workload identity federation mechanics).

Keep X.509-SVIDs for mTLS inside the workload plane. Mint a dedicated JWT-SVID for the Entra token exchange. Trying to make one credential format do both jobs weakens the design rather than simplifying it.

The bridge is an exact three-claim contract

A federated identity credential, or FIC, tells Entra which external JWT may authenticate a workload identity. Three values form the contract:

issuer must match the incoming JWT's iss claim.
subject must match the incoming JWT's sub claim.
audiences must contain the audience Entra expects in the incoming JWT, normally api://AzureADTokenExchange.

Microsoft performs this match exactly and case-sensitively. Wildcards are not supported in standard FIC property values, and an application or agent identity blueprint can have at most 20 FICs (FIC considerations).

For one production agent workload, the incoming JWT-SVID could look like this:

{
  "iss": "https://oidc.example.com",
  "sub": "spiffe://example.com/agent/invoice-reconciler",
  "aud": ["api://AzureADTokenExchange"],
  "exp": 1784304000
}

The corresponding FIC on the agent identity blueprint's application object is:

{
  "name": "spiffe-production-invoice-agent",
  "issuer": "https://oidc.example.com",
  "subject": "spiffe://example.com/agent/invoice-reconciler",
  "audiences": [
    "api://AzureADTokenExchange"
  ]
}

Incoming JWT-SVID                         Federated identity credential

iss: https://oidc.example.com       ===> issuer: https://oidc.example.com

sub: spiffe://example.com/          ===> subject: spiffe://example.com/
  agent/invoice-reconciler                    agent/invoice-reconciler

aud: api://AzureADTokenExchange     ===> audiences:
                 api://AzureADTokenExchange

      EXACT, CASE-SENSITIVE MATCH

This mapping authenticates the blueprint. It does not grant downstream
permissions or carry a user's delegated authorization context.

The subject is where SPIFFE fits naturally. The JWT-SVID specification requires sub to equal the workload's SPIFFE ID, so the FIC binds one precise SPIFFE workload identity to one blueprint credential path.

The audience is where architecture becomes policy. SPIFFE allows site-specific audiences and recommends scoping them to the intended recipient (JWT-SVID audience requirements). For this token, the intended recipient is Entra's token exchange. The workload should therefore request a JWT-SVID with the single audience api://AzureADTokenExchange, matching the FIC.

Do not reuse a JWT-SVID minted for an internal API. Do not add Entra as a second audience to a token already used elsewhere. A recipient of a multi-audience bearer token can replay that token to another listed audience, which is why the SPIFFE specification strongly recommends single-audience JWT-SVIDs.

The token flow, without the hand-waving

The autonomous flow has seven steps:

SPIRE attests the agent workload according to its registration and runtime selectors.
The workload requests a JWT-SVID from the local Workload API with api://AzureADTokenExchange as its sole audience.
SPIRE issues a short-lived JWT-SVID whose sub is the workload's SPIFFE ID.
The workload sends that JWT to the Microsoft identity platform token endpoint as client_assertion, requests api://AzureADTokenExchange/.default, and supplies the child agent identity's client ID in fmi_path.
Entra discovers the external issuer's signing keys, validates the JWT, compares iss, sub, and aud against the FIC on the blueprint, and returns the blueprint exchange token T1.
The workload sends T1 as the client_assertion in a second request whose client_id is the child agent identity and whose scope names the downstream resource.
Entra validates the blueprint-to-child relationship and issues a resource-scoped access token in which the agent identity, not the SPIFFE workload, is the enterprise principal.

The first request uses the JWT-SVID to authenticate the blueprint. The fmi_path parameter selects the child agent identity for which the blueprint is requesting an exchange token, exactly as documented in the autonomous agent authentication flow:

POST https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id={agent-identity-blueprint-client-id}
&scope=api%3A%2F%2FAzureADTokenExchange%2F.default
&fmi_path={agent-identity-client-id}
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion={jwt-svid}
&grant_type=client_credentials

That request returns T1, not the Microsoft Graph token. The second request switches client_id from the blueprint to the child agent identity and uses T1 as its assertion (request an agent identity token):

POST https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id={agent-identity-client-id}
&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion={agent-blueprint-token-T1}
&grant_type=client_credentials

The blueprint authenticates with the external assertion, but the child agent identity becomes the principal in the final resource token. That distinction is not administrative trivia. If the downstream API authorizes the blueprint rather than the agent identity, the architecture has collapsed the attribution and least-privilege boundary it adopted Agent ID to create.

A SPIFFE bundle endpoint is not OIDC discovery

This is the catch most diagrams omit.

SPIFFE defines how trust bundles carry X.509 authorities and JWT signing keys. Its federation specification defines bundle endpoints through which one SPIFFE trust domain can retrieve another domain's current bundle. JWT-SVID signing keys appear in a SPIFFE bundle as JWK entries whose use value is jwt-svid (JWT-SVID key publication).

Microsoft Entra expects something different. The configured FIC issuer must be a URL compatible with OIDC discovery, and Entra uses that issuer URL to retrieve the keys required to validate the external token (external issuer configuration).

A SPIFFE bundle endpoint and an OIDC discovery endpoint both publish trust material over HTTPS, but they are not the same protocol surface. Similar nouns do not create interoperability.

The production architecture therefore needs an issuer service that:

exposes /.well-known/openid-configuration for the configured HTTPS issuer;
exposes a JWKS endpoint referenced by that discovery document;
publishes the active SPIRE JWT signing keys in an Entra-compatible JWKS;
keeps the JWT-SVID iss claim exactly aligned with the configured issuer URL;
rotates published keys without creating a window in which valid JWT-SVIDs cannot be verified.

That service is part of your identity control plane. Treating it as a static JSON file on an incidental web server is the identity equivalent of putting a production certificate chain in a shared folder and calling it PKI.

Microsoft also documents that the identity platform stores only the first 100 signing keys downloaded from an external OIDC endpoint (workload identity federation mechanics). That limit should be easy to respect, but it makes stale-key accumulation an operational concern rather than harmless clutter.

Short-lived bearer tokens can still be replayed

JWT-SVIDs reduce credential lifetime. They do not eliminate bearer-token behavior.

The SPIFFE specification is direct: JWT-SVIDs are susceptible to replay. A short exp narrows the window. A jti can support replay detection, but JWT-SVID validators are not required to track jti uniqueness. Confidential transport remains mandatory because possession of the token is sufficient to present it during its valid lifetime (JWT-SVID transport security).

For this exchange, that produces a clear baseline:

request the JWT-SVID only when an Entra token is needed;
use one audience, api://AzureADTokenExchange;
keep JWT-SVID lifetime as short as the exchange path tolerates;
never log the assertion or place it in agent prompts, tool output, or distributed traces;
send it directly to Entra over TLS;
cache the resulting resource token according to its lifetime, not the source assertion.

Short-lived credentials change the incident from "rotate a secret that may have escaped months ago" to "contain a replay window measured in minutes." That is a major improvement. It is not immunity.

Rotation now crosses an organizational boundary

SPIRE owns workload attestation and JWT signing-key rotation. The team operating the OIDC facade owns discovery availability and JWKS publication. Microsoft Entra owns external-token validation and FIC matching. The Agent ID team owns blueprint and child identity boundaries.

That is four operational responsibilities, even if one platform team implements all of them.

Microsoft currently documents RS256 as the supported signing algorithm for workload identity federation token exchange, while noting that other algorithms may work but are not tested (supported signing algorithms). An architect should therefore require the SPIRE JWT signing profile exposed to Entra to use RS256 rather than treating JOSE algorithm choice as an implementation detail.

FIC changes also take time to propagate. Microsoft warns that token requests made shortly after a FIC change can fail with AADSTS70021 until regional caches update, and recommends retry logic (FIC propagation). Key rollover and FIC rollout need staged tests, overlap, monitoring, and a rollback path. "The tokens are short-lived" does not make control-plane changes atomic.

The 20-credential limit is an architecture signal

Standard FICs bind exact issuer and subject values, and each application or blueprint is limited to 20 credentials (FIC design considerations).

That limit should stop an enterprise from attaching every SPIFFE workload in a fleet to one blueprint. It reinforces the boundary model from [[Enterprise-architect-decision-framework-for-Entra-Agent-ID-blueprints-on-non-Microsoft-platforms]]: one blueprint should represent a deliberate trust and blast-radius boundary, not become a universal token vending machine.

Microsoft has introduced flexible federated identity credentials that can match subject patterns and selected custom claims, but the feature is currently preview. Pattern matching also changes the risk model. An exact SPIFFE ID binds one registered workload to the blueprint. A claims expression binds a class of workloads. That can reduce object count, but it increases the importance of SPIRE registration policy and namespace governance.

Scale is not permission to blur identity boundaries. If 20 exact bindings are insufficient, first ask whether the blueprint boundary is too broad. Only then consider a flexible expression.

Workload federation authenticates the client in both autonomous and OBO flows

The source assertion proves the workload's identity. That makes the JWT-SVID a client credential, not a statement about whether the resulting flow is autonomous or delegated.

Microsoft separates autonomous agent authorization from on-behalf-of authorization, but both flows still require the client to authenticate. In the autonomous flow, the SPIFFE-backed FIC authenticates the blueprint before the child agent identity requests a resource token with its own application permissions. In an OBO flow, the same client-authentication path can be combined with an incoming user assertion so that both agent and user context participate (Microsoft identity platform OBO flow, Agent ID OBO flow).

For Agent ID, this remains a two-stage exchange. First, the blueprint presents the JWT-SVID as its client_assertion, includes the child agent identity in fmi_path, and receives T1. The child agent identity then performs the OBO exchange by presenting both T1 as its client credential and the incoming user access token as the user assertion:

POST https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id={agent-identity-client-id}
&scope=https%3A%2F%2Fresource.example.com%2Fscope1
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion={agent-blueprint-token-T1}
&grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&assertion={incoming-user-access-token}
&requested_token_use=on_behalf_of

The distinction between client_assertion and assertion is the architecture. client_assertion proves which client is making the exchange. assertion carries the signed-in user's delegated context. Workload identity federation replaces the client's stored secret; it does not replace the user token, user consent, delegated permissions, or OBO protocol.

This also sharpens the connection to [[The-industry-does-not-have-an-agent-identity-propagation-standard-yet]]. SPIFFE can authenticate the workload at a cross-platform boundary, and Entra can combine that client authentication with an Entra-issued user assertion. SPIFFE still does not independently preserve a human subject across identity provider domains, capture consent, or define who is accountable for translating user context.

Do not put a user's identifier into a private JWT-SVID claim and call the problem solved. The JWT-SVID authenticates the client. The incoming access token and OBO exchange carry delegated authorization.

The production decision

Use this pattern when all of the following are true:

the organization already operates SPIRE as a workload identity authority;
the agent runs outside Azure or across heterogeneous infrastructure;
the agent needs a governed Microsoft Entra identity for autonomous or OBO access;
eliminating blueprint secrets is worth operating an OIDC discovery and JWKS publication surface;
SPIFFE registration policy and Entra blueprint ownership have accountable operators;
exact workload-to-blueprint mappings fit the intended blast-radius model.

Do not use it as a shortcut around delegated consent or OBO. Use the JWT-SVID to authenticate the client, then supply the incoming user token through the documented assertion parameter. Reject the pattern when your only available credential is an X.509-SVID or when nobody owns the issuer surface and key-rotation path.

The final architecture is not "SPIFFE authenticates to Entra." That phrase hides too much.

SPIRE attests a workload. A dedicated JWT-SVID presents that workload identity to a deliberately operated OIDC issuer surface. An exact FIC authorizes that issuer, SPIFFE ID, and audience to authenticate an agent identity blueprint. Entra then issues a resource token for the governed agent identity, whose permissions remain independently controlled.

Two control planes. One narrow trust contract. No shared secret.

That is a strong architecture, provided you operate all three parts of the sentence.

References

Microsoft Graph least privilege has two control planes

Anton Staykov — Tue, 28 Jul 2026 09:37:00 +0000

The Microsoft Graph least-privilege story has improved a lot. That is not the problem.

The problem is that many teams are still looking at only half of it.

Granular permissions such as User.Create, User.EnableDisableAccount.All, User.RevokeSessions.All, and Application.ReadWrite.OwnedBy are a better design surface than the old habit of reaching for Directory.ReadWrite.All whenever an app needed to do anything useful in the directory. Microsoft Graph permissions intentionally follow a {resource}.{operation}.{constraint} naming pattern, which lets engineers express the operation an app is allowed to perform instead of throwing the app into a tenant-wide bucket (Microsoft Graph permissions overview).

That shift matters. But it does not finish the authorization model.

The less understood truth is this: Microsoft Graph least privilege has two control planes. The first is the Graph permission plane: what the client application is allowed to request from Microsoft Graph. The second is the Microsoft Entra control plane: who or what is allowed to control the application object, the service principal, and the directory objects the app will act on.

If you design only the first plane, your architecture can still be wildly overprivileged.

The first plane: Graph permissions authorize the client

Start with the piece engineers usually know.

Microsoft Graph supports delegated access and app-only access. In delegated access, the app calls Microsoft Graph on behalf of a signed-in user. In app-only access, the app calls Microsoft Graph as itself, without a signed-in user (Microsoft Graph permissions overview).

Delegated permissions are the easiest place to see the intersection model. Microsoft states it plainly: in a delegated scenario, the privileges an app has are determined by the Microsoft Graph permissions granted to the app and the user's own permissions (Microsoft Graph delegated permissions).

That sentence should be printed on every onboarding app design review.

If your custom HR onboarding app has been granted the delegated permission User.Create, the app has permission to call the create-user operation. But the signed-in user still needs the Entra authority to create users. The Graph permission authorizes the client. The Entra role authorizes the human. Delegated Microsoft Graph access needs both.

Flip it around and the same lesson holds. If the signed-in user is a User Administrator, but the app has not been granted the right delegated Microsoft Graph permission, the user's admin role does not magically donate authority to the client. A user can perform an operation in the Entra admin center and still fail through a custom app because the app itself is not authorized for the Graph call.

This is the first correction:

In a delegated scenario, admin role assignment is not a substitute for Graph consent, and Graph consent is not a substitute for admin role assignment.

The second plane: Entra controls who can control the thing doing the calling

Now comes the part that gets missed.

Microsoft Entra applications are represented by two related objects: the application object and the service principal object. The application object is the global template for the app. The service principal is the local representation of that app in a specific tenant, and it defines what the app can actually do in that tenant, who can access it, and what resources it can access (Application and service principal objects in Microsoft Entra ID).

That distinction is not directory trivia. It is a control-plane boundary.

The application object controls things like redirect URIs, credentials, requested permissions, exposed APIs, and ownership. The service principal controls the enterprise application instance in the tenant: assignments, local policies, consented permissions, provisioning configuration, sign-in behavior, and other tenant-specific settings (Application and service principal objects).

So when you ask, "is this Graph app least privileged?" the permission list is not enough. You also need to ask who can mutate the app registration, who can mutate the enterprise application, who can add credentials, who can add owners, who can change user assignment, and who can change the permissions the app requests.

That is the second plane.

Owner is not a label, owner is control

Application and enterprise application (service principal) ownership is one of the most underestimated privilege paths in Microsoft Entra.

Microsoft documents that an owner of an enterprise application can manage the organization-specific configuration of the application, including single sign-on, provisioning, and user assignment. The owner can also add or remove other owners. More importantly, Microsoft states that owners have the same permissions as application administrators, scoped to an individual application (Enterprise application ownership).

Read that again slowly: application administrator, scoped to one application.

That is not harmless metadata. That is delegated control over a highly sensitive object.

The default user permissions documentation is even more concrete:

Owners of application registrations can update application authentication (reply urls), credentials, owners, permissions, policies, and basic properties. Owners of enterprise applications can update service principal credentials, owners, permissions, app role assignments, provisioning settings, and related policies (Default user permissions and ownership permissions).

Microsoft also calls out the dangerous consequence directly:

... the application might have more permissions than the owner, which can become elevation of privilege because an owner can create or update objects while impersonating the application (Enterprise application ownership note).

That is the part many app teams miss. The owner does not need to have the same directory role as the app. If the app has powerful application permissions, the person who can add a credential or change ownership can potentially create a path to act as the app.

Static secrets get most of the attention here, but ownership is the quieter root. If I can become owner, add myself as another owner, add or rotate credentials, adjust the app configuration, or influence the service principal's local settings, I am no longer merely adjacent to the app. I am in the control plane of the app.

The bad pattern: broad Graph permission plus casual ownership

Here is the pattern I still see too often.

An engineering team builds a Graph automation app. They correctly avoid Directory.ReadWrite.All and use a narrower Graph permission. Good. Then they leave three developers as owners of the app registration, two operations engineers as owners of the enterprise application, and a shared service account with broad rights because "someone needs to maintain it."

On paper, the app permission set looks defensible. In reality, the control plane around the app is loose.

That is not least privilege. That is narrow API permission sitting inside broad object control.

The better question is not only "what Graph permissions does the app have?" The better question is: "who can change the identity that has those permissions?"

If the answer is a long list of permanent owners, the app is overprivileged even if the Graph permission list looks elegant.

Scoped Entra roles are the missing design tool

This is where Microsoft Entra role scoping becomes much more interesting than most app teams realize.

Microsoft Entra roles are usually assigned at tenant scope, but Microsoft also supports assigning roles at narrower scopes, including application registrations and administrative units. Microsoft describes the resource a role assignment applies to as the scope, and supports restricted scope for built-in and custom roles (Assign Microsoft Entra roles).

For app registrations, the model is direct. Instead of granting someone tenant-wide Application Administrator, you can assign a relevant built-in or even custom role scoped to a single app registration. Microsoft describes this as a way to let a principal update credentials and basic properties of a single app without granting tenant-wide application administration (Assign roles with app registration scope).

The Graph shape is simple:

POST https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments
Content-Type: application/json

{
  "@odata.type": "#microsoft.graph.unifiedRoleAssignment",
  "principalId": "<principal-object-id>",
  "roleDefinitionId": "<role-definition-id>",
  "directoryScopeId": "/<application-object-id>"
}

That directoryScopeId value matters. For app registration scope, /<id> means the principal can manage that Microsoft Entra object. Microsoft explicitly contrasts that with /administrativeUnits/<id>, which means the principal can manage the members of the administrative unit based on the assigned role (Assign roles with app registration scope).

That distinction is the whole architecture in miniature. Same role-assignment resource. Different scope semantics. Different blast radius.

Administrative units are not just for humans

Administrative units are usually explained as a delegation feature for helpdesk and regional administration. That is true, but incomplete.

Microsoft documents that Entra roles can be assigned with administrative-unit scope so the role permissions apply only when managing members of that administrative unit, not tenant-wide settings or unrelated directory objects (Assign roles with administrative unit scope).

For example, a User Administrator scoped to the "Germany Employees" administrative unit can manage users in that administrative unit without becoming User Administrator for the whole tenant, subject to the role's supported administrative-unit behavior and restrictions (Administrative-unit role scope).

That already matters for humans. It matters even more for automation.

If you are building an onboarding app for five subsidiaries, why should the app's runtime identity be able to manage every user in the tenant? If the work is limited to five administrative units, the role assignment should be limited to those administrative units.

This is the balance shift: Graph permissions are always tenant-wide. Entra role assignments can be scoped.

The widely unknown pattern: service principal plus administrative-unit scope

Now for the part that is still too obscure.

You can assign a Microsoft Entra role to a service principal at administrative-unit scope.

This is not how most portal walkthroughs teach the feature. Most examples show a user as the principal. Some examples mention groups. The architecture pattern for app identities is still widely unknown. But the Graph contract supports the pieces.

The unifiedRoleAssignment resource represents a role definition assigned to a principal at a scope, and Microsoft lists supported principals as users, role-assignable groups, and service principals (unifiedRoleAssignment resource type). The create-role-assignment API documents directoryScopeId formats for the directory provider, including / for tenant-wide scope, /administrativeUnits/{administrativeunit-id} for administrative-unit scope, and /{application-objectId} for application scope (Create unifiedRoleAssignment).

Put those two facts together and the payload becomes obvious:

POST https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments
Content-Type: application/json

{
  "@odata.type": "#microsoft.graph.unifiedRoleAssignment",
  "principalId": "<service-principal-object-id>",
  "roleDefinitionId": "<role-definition-id>",
  "directoryScopeId": "/administrativeUnits/<administrative-unit-id>"
}

That assignment says: this service principal has this Entra role, but only for the members of this administrative unit, subject to the role's administrative-unit support.

In practice, there is one more wrinkle engineers need to know. Microsoft documents that service principals and guest users do not receive directory read permissions by default, and service principals using an administrative-unit-scoped role assignment need corresponding read permissions, commonly Directory Readers at tenant scope or another role that includes the necessary read permissions (Service principals and administrative-unit scoped role assignments).

That tenant-scope read dependency annoys people at first. It should not. Read capability and write authority are different risks. A service principal might need enough tenant-level read to resolve directory objects while its actual administrative authority remains scoped to one administrative unit. That is still a materially better design than granting a tenant-wide write role because the app needs to manage one slice of the directory.

The pattern is not theoretical. It is validated, battle-tested, and still underused.

Why this changes Graph automation design

Once you see the two planes, the design review changes.

For a delegated app, you ask:

What Microsoft Graph delegated permission does the client need?
Which Entra role must the signed-in user hold?
Can that role be scoped to an administrative unit or application registration instead of the tenant?
Who owns the app registration and enterprise application?

For an app-only automation identity, you ask:

What Microsoft Graph application permission does the service principal need?
Can the operation be represented by an Entra role assignment instead of a broad Graph application permission?
Can that Entra role be scoped to an administrative unit or specific (application) object?
Does the service principal have only the directory read permissions needed to make that scoped role usable?
Who can add credentials or owners to the app and service principal?

That last question is not an afterthought. It is often the difference between least privilege and theater.

A practical model for app teams

Here is the model I would use with app and platform engineers.

First, choose the narrowest Microsoft Graph permission that matches the API operation. Use User.Create if the app creates users. Use Application.ReadWrite.OwnedBy if the app only needs to manage applications it owns. Avoid directory-wide permissions unless the operation truly has no narrower resource-specific permission (Microsoft Graph permissions reference).

Second, decide whether the app needs delegated or app-only access. In delegated mode, remember that Graph evaluates the client permission and the user's own authority. In app-only mode, remember that the app is the actor, so application permissions or role assignments must be treated as production privilege (Microsoft Graph permission types).

Third, scope Entra roles as aggressively as the business process allows. If the operator manages one app, use app-registration scope. If the automation manages one population, use administrative-unit scope. If the app really needs tenant-wide scope, make that an explicit exception, not the default (Assign Microsoft Entra roles at different scopes).

Fourth, treat owners as privileged. Application owners and enterprise application owners should be reviewed like role assignments, because they can control the object that holds the app's permissions and credentials (Default user permissions and ownership permissions).

Finally, keep the object model visible. The app registration and the service principal are not interchangeable. The app registration is the template. The service principal is the tenant-local instance that controls what the app can actually do in that tenant (Application and service principal relationship).

The sentence to bring to your next design review

Least privilege for Microsoft Graph is not "we picked a smaller Graph permission."

That is a good start. It is not the finish line.

Least privilege for Microsoft Graph means the client has the narrowest Graph permission, the actor has the narrowest Entra authority, the role assignment has the narrowest scope, and the app object has the narrowest ownership model.

Miss any one of those, and your beautiful permission list can still hide a control-plane problem.

The industry is finally getting better Microsoft Graph permission granularity. Now app teams need to get equally serious about the Entra control plane around those permissions.

Because the app that can touch your directory is only as least-privileged as the people and identities that can control the app.

References

Enterprise architects: your overdue Entra decision is an agent CSA schema

Anton Staykov — Thu, 23 Jul 2026 09:23:00 +0000

If you are an enterprise architect working on Microsoft Entra and AI agents, your first overdue job is not another policy wizard, another dashboard, or another governance steering committee. It is schema design.

Specifically, it is deciding how you classify non-human identities with custom security attributes in Microsoft Entra. Not eventually. Up front.

I keep seeing the same pattern across customers of every size: teams move quickly on agent experimentation, they onboard identities, they test controls, and then they realize they have no consistent attribute language for policy scope. At that point, every policy becomes a naming convention problem in disguise.

That is backwards.

The control plane starts with classification

Custom security attributes are not decorative metadata. They are tenant-scoped key-value classifications you can assign to users, enterprise applications (service principals), and agent identities that are modeled as a service principal subtype, with dedicated role and permission boundaries for who can define and assign them (overview, Graph model, agent identity service principal model).

That alone should change how architects think about them. This is not "nice to have taxonomy." This is policy input.

Microsoft Entra Conditional Access for agents supports attribute-driven targeting with custom security attributes, and policy evaluation happens during token issuance and refresh, not just at policy authoring time (Conditional Access for agents). In other words: if your classification is sloppy, your runtime decisions are sloppy.

Why agents raise the stakes

You can say "an agent identity is still a service principal" and be technically correct. Microsoft Entra Agent ID is built on service principal infrastructure (agent identities, service principals, and applications).

You can also miss the point.

Agent identity introduces a blueprint-centered model where one blueprint can represent many agents, where blueprint-level policy decisions can affect all derived identities, and where operational accountability (owners and sponsors) is part of the model (key concepts). This is not how most architects historically modeled "traditional" workload identities.

So yes, same substrate. Different operating semantics.

That difference is exactly why CSA strategy for agents should be deliberate, not inherited by accident from old workload identity templates.

Reuse your existing workload schema or create a dedicated agent schema?

This is the question every architecture board eventually reaches.

The honest answer is conditional, not ideological.

Reusing your existing workload schema has real advantages. It accelerates rollout, avoids duplicate governance machinery, and can be enough if your workload identity estate is already cleanly governed and your agent population is still limited.

But here is the trade-off many teams underestimate: semantic collision.

When the same attribute family has to describe static daemon services, integration apps, and AI agents with interactive and autonomous behavior patterns, naming starts to drift. Policy intent gets fuzzy. People read "criticality" or "environment" and assume shared meaning where meaning has already diverged. Then policy scopes become misleading even when the syntax is valid.

That is the failure mode I care about most. Not policy syntax errors. Policy intent errors.

For regulated enterprises, or any organization expecting meaningful agent scale, my default recommendation is to establish a dedicated agent CSA schema and keep crosswalk mappings to legacy workload attributes where needed. You can still align governance. You just stop pretending the populations are identical.

The architect's mistake: tactical granularity too early

Most teams that finally commit to an agent schema make the same second mistake: they overengineer it.

They try to encode every nuanced runtime trait into attributes on day one. They turn schema design into a cataloging exercise. They create dozens of values nobody will govern consistently.

Do not do that.

Strategic schema design means defining long-lived control boundaries, not short-lived implementation detail. Microsoft documents clear limits and lifecycle constraints on custom security attributes, including tenant-level definition caps and immutable naming characteristics, which is exactly why restraint is a design virtue (limits and constraints, Graph overview).

Start with coarse boundaries that support high-impact policy outcomes you know you will still care about two years from now.

Two coarse boundaries worth defining first

First boundary: approved workload state.

If your operating model says "no AI agent should sign in until explicitly approved," then encode exactly that as a first-class classification and enforce from there. This is the kind of architectural control objective that survives platform changes.

Second boundary: department trust segmentation.

If your operating model says "financial department agents should only authenticate within finance-defined trust boundaries," then encode that boundary at classification level before you layer finer controls. Entra policy and filtering surfaces are strongest when your classes reflect organizational trust zones, not implementation trivia (attribute-driven Conditional Access for agents, autonomous agent policy walkthrough).

These are strategic guardrails. The fine-grained boundaries should come from additional controls and deeper policy patterns, which we can cover in follow-up pieces.

Governance is part of schema, not a separate phase

Custom security attributes are security-sensitive by design, and Entra uses dedicated attribute roles for definition and assignment. Even Global Administrator is not automatically enough for these operations by default (custom security attribute roles, permissions reference).

Treat that as a feature, not friction.

Your schema decision should include explicit ownership for:

who defines agent attribute sets and values,
who is allowed to assign and update values on agent identities,
how schema changes are reviewed when agent programs evolve.

If those answers are not defined with the schema, your taxonomy will drift faster than your policies can keep up.

The practical position

Could you reuse your current workload identity schema for AI agents? Yes.

Should you, by default, in a large regulated enterprise? Usually no.

The better default is a dedicated agent schema with a small number of coarse, policy-driving attributes. Make the boundaries obvious. Keep the vocabulary stable. Optimize for long-term policy clarity, not short-term convenience.

This is architecture work in the most literal sense: defining the shape of control before control logic gets complicated.

We already did this in this series when discussing dynamic consent accumulation and agent governance pressure in The Overlooked Gem in Microsoft Entra and Your Agent Is Becoming the Crown Jewel. This article just names the next prerequisite: the classification layer that keeps your controls honest.

If you delay this decision, every downstream guardrail becomes harder to reason about.

References

How enterprise architects should decide Entra Agent ID blueprint boundaries for non-Microsoft platforms

Anton Staykov — Tue, 21 Jul 2026 10:47:00 +0000

Enterprise architects keep asking me the same question: how many agent identity blueprints should we create for third-party or custom agent platforms connected to Microsoft Entra Agent ID?

That question sounds operational, but it is architectural. You are deciding failure containment, ownership boundaries, and governance behavior, all at once.

Before we go deeper, one important acknowledgement. If your agents are built in Microsoft-managed builder paths such as Copilot Studio and Agent 365 integration flows, identity provisioning is largely handled for you, including automatic Agent ID creation and shared blueprint behavior in that platform path (Copilot Studio automatic Agent IDs, Agent 365 identity integration). If you choose that platform, you also accept its blueprint identity model by design.

This article is for the other world: non-Microsoft-built agent platforms, where your enterprise architecture team owns the blueprint boundary decisions.

I am also not going to summarize the canonical guidance. You should read both Plan your agent identity architecture and Microsoft Entra Agent ID design patterns directly, then come back. This piece is about decision framing, trade-offs, and policy posture.

Stop asking for a count, start defining trust boundaries

When architects ask "how many blueprints," they usually mean one of three fears:

"I do not want one compromised component to become tenant-wide damage."
"I do not want central identity teams to become a ticket bottleneck."
"I do not want unrecoverable sprawl six months from now."

That is a trust-boundary problem, not an object-count problem.

Microsoft's own architecture guidance is explicit that blueprint count should follow trust boundaries, while many common concerns (replicas, memory partitioning, session context) are not valid reasons to split identities (planning guidance, design patterns).

If your team still starts with org chart lines like "one blueprint per project by default," you are optimizing for slide readability, not for incident containment.

The blueprint power model, and the part teams keep confusing

You need one clear mental model.

The blueprint is your identity factory and authentication anchor. It is what enables creation of child agent identities at scale, including runtime or ephemeral patterns when your architecture needs on-demand identities (creation channels).

That is good news for delivery teams. Developers do not need to raise a central ticket for every single new identity if the right blueprint channel and controls are already in place.

But do not confuse that with automatic governance.

Blueprints are not where your organization magically enforces business access policy. Consent boundaries, entitlement policy, Conditional Access, and app-governance controls are separate control planes that still require explicit enterprise policy definition and rollout (user/admin consent model, define governance policy).

Treat the blueprint as a creation authority, not as the permission-grant layer and not as your per-agent lifecycle governance switch.

In plain terms, Entra Agent ID and Agent 365 capabilities do not enforce your internal architecture doctrine by themselves. Without internal policies, teams will improvise.

Blast radius reality: one compromised agent can become many identities

Here is the uncomfortable part.

Within a shared blueprint trust boundary, if one agent runtime is compromised and the attacker can use the same blueprint credential path, that attacker can request tokens that act as sibling identities under that blueprint boundary. This is exactly why Microsoft frames blueprint compromise as potentially affecting all child identities in that blueprint scope (planning guidance).

That is the architectural reason you model by trust boundary first.

It also explains a frequent false comfort pattern: "we will just split certificates or managed identity details but keep one shared blueprint boundary." If the effective authentication authority is still the same blueprint trust surface, your containment gain is smaller than people assume.

A risk-first decision framework for blueprint boundaries

Use this sequence. Do not skip steps.

1) Define hard trust boundaries

Map runtime, secret stores, network segmentation, and operational ownership. If compromise should not cross between two zones, they should not share a blueprint.

2) Define failure containment targets

State explicitly what should be kill-switch scope:

one identity,
one blueprint,
one environment,
or tenant-wide.

If this is undefined, your incident response design is fiction.

3) Define permission topology

Decide what is inheritable baseline and what is per-agent specialization. Keep inherited baseline tight and role-specific differentiation local to agent identities.

4) Define lifecycle behavior

Will identities be long-lived, or created dynamically for specific task windows? If dynamic creation is a first-class requirement, blueprint channel design and guardrails become even more critical.

5) Define governance ownership

Who approves what, who can create via which channel, who can override in emergencies, who attests quarterly. If there is no owner matrix, there is no governance.

When one blueprint is right, and when it is reckless

One blueprint with multiple agent identities is often correct when teams share the same trust boundary, runtime envelope, and operational ownership, while still needing per-agent attribution and differentiated downstream access (design patterns).

Concrete example: if your agents run in the same container orchestration boundary (for example, a shared Kubernetes namespace on AKS, EKS, or GKE), that is usually a strong indicator for one shared blueprint in that boundary. In practice, namespace-level controls define who can deploy, who can mutate workloads, what network policies apply, and what mounted/shared resources are reachable.

That matters because your real security perimeter is often the namespace and its attached runtime controls, not an individual pod. Most engineering organizations can consistently enforce controls at namespace scope for developers and CI/CD pipelines, while per-pod isolation is harder to guarantee as a durable operating model.

It becomes reckless when you cross security domains and still keep one blueprint for convenience. Separate teams, separate secret domains, separate runtime isolation, or separate regulatory boundaries should usually trigger separate blueprints.

Policy starter kit for enterprise architects

If you want consistency across teams, publish a short internal policy before the next project starts.

Blueprint policy baseline

One blueprint per trust boundary unless exception approved.
Mandatory sponsor and owner assignment, with periodic attestation.
Naming convention that encodes environment, domain, and business owner.
Conditional Access baseline and monitoring baseline applied at blueprint and identity levels where applicable (best practices, manage and govern agent identities).

Creation channel policy

Define which channels are allowed in your org: admin center, Graph, IaC/CLI, product-integrated channels.
Bind each channel to approved roles and permission grants.
Prohibit ad-hoc consent paths for production-grade identity creation unless explicitly reviewed (configure user consent).

Split and merge rubric

Require architecture review on:

trust-boundary changes,
new regulated data exposure,
new external execution platform,
incident lessons that show containment gaps.

If teams cannot explain why two workloads can safely share compromise blast radius, they should not share a blueprint.

The architect checklist to force before production

Before approving blueprint design, require crisp answers to these questions:

If one agent runtime is compromised, what exact identity scope can the attacker influence?
Which trust boundaries are represented, and why are they safe to share?
Which channels can create identities, and who controls them?
Which policies prevent consent and permission sprawl?
What is the fastest kill-switch path during incident response?
What quarterly evidence proves this model is still valid?

If your team cannot answer those six questions in one review, your blueprint model is not ready for production.

References

The industry does not have an agent identity propagation standard yet

Anton Staykov — Tue, 14 Jul 2026 11:07:00 +0000

Most architecture conversations about AI agents still get stuck on the wrong boundary.

Someone draws an agent in Azure, another agent in AWS, a resource behind Ping Identity or Auth0, a Microsoft Entra-protected API, an MCP server in the middle, and a user somewhere at the beginning of the chain. Then the room asks: can Microsoft Entra Agent ID work if the agent is not hosted on Microsoft infrastructure?

That is the easy question. Hosting is not the boundary.

Identity provider domain is the boundary.

An application can live in AWS, Google Cloud, a co-location rack, or a basement server room and still use Microsoft Entra ID for sign-in. The same principle applies to agents. Microsoft explicitly positions Entra Agent ID as working with Microsoft and non-Microsoft platforms, including integrations through the Microsoft Entra Auth SDK sidecar and workload identity federation (Microsoft Entra Agent ID, third-party agent integration patterns).

The hard part starts when the flow leaves one identity provider and must preserve the original user context in another identity provider's world.

That is where the industry is still awkward. Not because there are no standards. There are standards. The problem is that the standards describe token exchange mechanics better than they describe enterprise trust governance for long, agentic, multi-hop chains.

The diagram above is the mental model. A user signs in, an application invokes an agent, the agent calls a tool or MCP server, another agent appears, and eventually a REST API or database needs to decide whether to trust the original user's context. Some arrows stay inside Microsoft Entra. Some arrows cross into Ping Identity or another provider. Some resources are custom APIs. Some are Microsoft resources. Some are agentic systems calling other agentic systems.

The diagram looks like a flow. In practice, it is a chain of trust decisions.

Federation is not token exchange

One of the most useful audience questions in the discussion was simple: "We already solve multiple identity providers with federation. Why is this different for agents?"

That question matters because it separates two things teams often blend together.

Federation solves an interactive authentication problem. A user starts at one identity provider, is redirected to another identity provider, proves who they are, and returns with a token or assertion the application can use. That pattern is well understood in SAML, OpenID Connect, and enterprise SSO designs (OpenID Connect Core, Microsoft identity platform and OpenID Connect).

Token exchange solves a different problem. A component that already received one token asks an authorization server for another token intended for a different resource or context. The standard that most directly describes this is OAuth 2.0 Token Exchange, RFC 8693. RFC 8693 defines a Security Token Service style protocol for requesting and obtaining tokens from OAuth authorization servers, including delegation and impersonation semantics.

Those are not the same motion.

Federation is the front door. Token exchange is what happens in the hallway after the front door has already closed.

That distinction becomes brutally important for agents because agents create more hallways. A user does not simply sign in and call one API. The user asks an agent, the agent calls a tool, the tool calls an MCP server, the MCP server calls another agent, and that agent calls a REST API. Each hop may need a different token audience, a different scope, a different policy evaluation, and a different interpretation of who is acting.

RFC 8693 gives us language, not the whole operating model

RFC 8693 is important because it gives the industry precise words for what keeps showing up in agent conversations: subject_token, actor_token, audience, resource, scope, act, and may_act (RFC 8693).

It also draws a clean line between impersonation and delegation. In impersonation, principal A becomes indistinguishable from principal B within the token's rights context. In delegation, principal A remains visible as the actor representing principal B (RFC 8693, delegation vs. impersonation). For agents, that distinction is not academic. An enterprise should almost never want an agent to become invisible as the human. It wants the user, the agent, and the delegation relationship to remain visible.

RFC 8693 also defines the act claim as a way to represent the current actor and even nested actor chains in a JWT (RFC 8693, actor claim). That sounds like exactly what we need.

But the standard is careful about its own boundary. It defines a protocol. It does not solve every deployment trust model. It explicitly leaves token semantics, policy decisions, and many security characteristics to implementations and deployment configuration (RFC 8693 introduction, RFC 8693 security considerations).

That is the gap.

The standard can describe a token exchange. It cannot, by itself, answer the enterprise question: who configured the mapping that allows an actor from identity provider A to arrive at identity provider B and claim a privileged user context?

That question is not protocol syntax. That question is governance.

Autonomous agents are the solved part

If there is no user context to preserve, the picture is much cleaner.

An autonomous agent can authenticate as itself using client credentials, a certificate, a federated identity credential, or a managed identity, depending on the platform and operating model. Microsoft Entra Agent ID supports autonomous access and delegated access as different modes for agent identities (what agent identities enable). The Microsoft Entra Auth SDK sidecar is not the authentication method for the agent itself. It is a token-handling pattern that keeps credential exchange, OBO flows, token caching, and credential-source abstraction outside the agent code (Microsoft Entra Auth SDK sidecar).

This is also where workload identity federation fits well. Microsoft documents workload identity federation as a way for applications to access Microsoft Entra-protected resources without managing secrets, by trusting tokens from external identity providers (workload identity federation). Entra Agent ID's third-party integration guidance describes agents on external platforms exchanging native workload identity tokens for Microsoft Entra tokens before calling APIs (integrate third-party agents).

This pattern is not limited to Microsoft. AWS, Google Cloud, Kubernetes ecosystems, and SPIFFE-based systems all lean into the same broad direction: give workloads short-lived, attestable identities instead of static secrets. SPIFFE describes itself as a set of open-source standards for identifying software systems in dynamic and heterogeneous environments, with short-lived identity documents called SVIDs delivered through a workload API (SPIFFE overview).

For fully autonomous agents, the industry has enough pieces to build sane systems today.

The agent proves what workload it is. The target resource validates the token. The authorization system checks the agent's assigned rights. No human context needs to survive the journey.

That is not trivial, but it is tractable.

User context is where the floor drops

The difficult case is the one the audience kept circling back to: an employee signs in, an agent acts on behalf of that employee, the flow crosses identity providers, and a downstream resource must still know which human user started the journey.

Microsoft Entra Agent ID supports on-behalf-of flows for agents. The documented OBO pattern uses a user token sent to the agent identity blueprint, then performs token exchanges so the resulting resource token carries the signed-in user's delegated context together with the agent identity (Agent OAuth flows: on behalf of flow). Microsoft recommends using approved SDKs such as Microsoft.Identity.Web or the Microsoft Entra Auth SDK sidecar because manual implementation is complex and error-prone (Agent OAuth flows: on behalf of flow, sidecar sample scenarios).

Inside one coherent identity domain, that is already a serious amount of machinery. Across identity providers, it becomes a trust governance problem.

The downstream system is no longer asking only, "Is this token valid?" It is asking a longer set of questions:

Who was the original user?
Which agent is acting now?
Which prior agents or services participated in the chain?
Which identity provider translated the context?
Who configured that translation?
Are we allowed to trust that mapping?
How do we monitor and revoke that trust when risk changes?

This is where the diagram matters. Six hops are not theoretical in an agentic architecture. They are what happens when a human asks one assistant to do work that uses an MCP server, which delegates to another specialized agent, which calls a vendor API, which then calls an internal API.

The standards do not stop you from creating such a chain. OAuth OBO style flows do not impose a natural business limit on how many middle tiers can appear. RFC 8693 can represent actor chains through nested act claims. In theory, the chain can keep growing (RFC 8693 actor claim).

Then the old boring transport layer walks into the room.

Bearer tokens are commonly presented to resource servers in the HTTP Authorization header field using Authorization: Bearer ... (RFC 6750, authorization request header field). HTTP deliberately does not define one universal maximum length for a field line, field value, or header section. Implementations set their own limits, and a server that receives request fields larger than it is willing to process is supposed to reject the request with an appropriate 4xx response, not ignore the fields (RFC 9110, field limits).

That means a perfectly valid access token can still be operationally too large for one proxy, gateway, service mesh sidecar, WAF, CDN edge, or application server in the path.

This is not only an availability problem. It is a security design smell. If every delegated hop adds nested actors, subjects, issuers, audiences, or other chain evidence, the token can grow until one component in the HTTP path handles it differently than the component that issued it or the API that validates it. Best case, the call fails cleanly. Worse case, a proxy truncates, drops, rewrites, retries, normalizes, caches, or falls back in a way the authorization model never expected. HTTP itself warns that ignoring oversized header fields increases exposure to request smuggling, and its security considerations explicitly call out attacks via protocol element length (RFC 9110, field limits, RFC 9110, attacks via protocol element length).

This is how a governance problem becomes an incident report. The identity system issued a token that was cryptographically valid. The architecture allowed a chain long enough to make that token huge. The application team assumed middleware would fail closed. The proxy team assumed the upstream API owned authorization. Then an agent reaches data it should not see because one hop in the path handled an oversized credential differently than another.

Who owns that failure?

The vendor that supported unbounded chaining? The architect who allowed policies with no practical chain-depth ceiling? The developer who never measured token size or actor-chain depth? The HTTP proxy that mishandled an oversized Authorization header? The operations team that changed a WAF limit two months ago and did not know it was now part of the identity control plane?

This is why "it worked two months ago" is such a dangerous sentence in agent identity. Nothing in the agent code needs to change for the chain to become too long. More tools get added. More agents call each other. More claims get preserved for audit. More tenants and issuers appear. Suddenly the same logical flow produces a larger token, crosses a different intermediary, and starts failing. Or worse, failing open.

But a representable chain is not automatically a governable chain.

That is the industry's current problem in one sentence: we can describe the chain better than we can govern the chain.

Evidence helps, but it does not create trust

Once the conversation moves from "can I get a token?" to "can the downstream system understand the context?" teams naturally reach for more data in the token.

That instinct is reasonable, but it is also incomplete. A downstream resource may need to know whether the caller is an agent, which agent is acting, which human user is present, which tenant owns the agent, whether the human is external to the resource tenant, or whether the agent is multi-tenant. That context can make downstream decisions smarter.

But more evidence in a token is not the same as trust.

Adding agent context, actor context, tenant context, or multi-tenant application context can make a downstream authorization decision more informed. It does not answer who approved the mapping, whether the source domain is trusted, whether the chain is still valid, or how the receiving domain should react when a risk signal changes.

That is the mistake to avoid. Token evidence can describe what arrived. Governance decides whether what arrived should be trusted.

The difference matters. Carrying context is easier than proving that the context should be trusted across organizational, identity provider, and agent boundaries.

The emerging standards conversation is really about trust evidence

When people ask for "the standard," they often mean one protocol that makes the whole diagram safe. That is not how this will land.

The industry is moving along several tracks at once.

OAuth token exchange gives us the exchange grammar (RFC 8693). Workload identity federation gives us a workable model for autonomous workload trust without secrets (workload identity federation). SPIFFE gives us an identity framework for workloads in heterogeneous environments, including JWT and X.509 identity documents (SPIFFE overview). Shared Signals and CAEP give the ecosystem a way to communicate security events and state changes continuously, rather than treating access decisions as one-time snapshots (OpenID Shared Signals Working Group). Agent protocols such as MCP and A2A are pushing tool and agent communication into more formal shapes, and Microsoft explicitly lists OAuth 2.0, MCP, and A2A among the protocols supported by the Entra Agent identity platform (Microsoft Entra Agent ID).

The center of gravity is shifting from "can I exchange a token?" to "what evidence travels with the token, and who is accountable for trusting it?"

That is the right shift.

The next generation of standards work has to answer questions the current protocol layer only exposes:

How does a receiving domain know the original user is still the same user after multiple agent and tool hops?
How does the chain preserve both the human subject and the current agent actor without collapsing into impersonation?
How are identity provider mappings approved, reviewed, expired, and revoked?
How does a downstream resource distinguish a first-party enterprise agent from a multi-tenant external agent acting for an enterprise user?
How do risk signals travel fast enough that a compromised account or agent does not keep operating on stale trust?

None of those questions are solved by adding one more token parameter.

They require standards that combine identity evidence, delegation semantics, risk signaling, authorization policy, and observability.

What architects should do now

The correct response is not to wait for the perfect standard. It is to design with the current product and trust boundary in mind.

First, separate platform location from identity provider domain. An agent running in AWS can still use Microsoft Entra Agent ID. An agent running in Azure can still call a Ping-protected resource. The host is an implementation detail. The issuer, audience, subject, actor, and trust mapping are the security model (third-party agent integration patterns).

Second, split autonomous agent flows from user-delegated flows before you draw the final architecture. Autonomous flows can be built today with client credentials, certificates, federated identity credentials, managed identities, workload identity federation, and standard token validation. A sidecar can help keep token acquisition and credential handling out of the agent code, but it is not itself the agent authentication method.

The delegated case is different. With Entra Agent ID today, do not design for an OBO flow that carries Microsoft Entra user context across an identity provider boundary and expects the other domain to preserve that context as part of the same delegation chain. Entra Agent ID supports OBO patterns for agents, but cross-IDP user-context propagation is not the supported operating model (Agent OAuth OBO flow). If the downstream system is governed by another identity provider, treat that as a separate trust domain. Either keep the delegated path inside one identity provider boundary, use autonomous workload-to-workload trust where user context is not required, or design an explicit application-level handoff with its own audit and policy model.

Third, avoid cross-domain impersonation unless the business process genuinely requires it and the audit model can survive scrutiny. Delegation should preserve the actor. Impersonation hides the actor from the resource's practical decision point. For agents, hiding the actor is usually the wrong instinct (RFC 8693 delegation vs. impersonation).

The real standard we are missing

The industry does not lack token standards. It lacks a complete, interoperable agent identity propagation governance model.

That model must preserve the original user where appropriate, preserve the current agent actor always, make cross-IDP mappings explicit, carry enough evidence for downstream decisions, propagate risk and revocation signals, and give enterprises a way to audit who allowed which transition.

OAuth token exchange is part of that answer. Workload identity federation is part of that answer. SPIFFE is part of that answer. Shared Signals and CAEP are part of that answer. Agent-specific identity platforms such as Microsoft Entra Agent ID are part of that answer.

But no single one of them is the whole answer yet.

That is the uncomfortable but useful conclusion from the diagram. We can build useful agent identity systems today. We can secure autonomous agents today. We can do delegated agent flows inside well-understood trust boundaries today. We can even cross platforms without much drama when the flow is autonomous or the trust boundary is explicit.

The thing we cannot hand-wave is multi-hop, user-bound, cross-IDP identity propagation.

That is the work ahead. Not just for Microsoft. For the industry.

References

Access packages are the control plane for Entra Agent ID permissions

Anton Staykov — Thu, 09 Jul 2026 10:43:00 +0000

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.

References

Every change to an Entra extension is a Control Plane event: the monitoring contract

Anton Staykov — Tue, 07 Jul 2026 09:47:00 +0000

Parts 1 and 2 of this series (Microsoft Entra extensibility is a gift. It is also Control Plane. and Securing the code that decides who Entra trusts) made two static decisions. Where the code lives: a dedicated Control Plane subscription, directly under the root management group or under a dedicated Control Plane management group, never in the platform identity subscription or an application landing zone. What credential it uses to call out: a managed identity by default, federated identity credentials when the call must leave Azure, certificates as a tolerated middle step, and static symmetric keys never.

Both decisions are one-time. You make them, you walk away, you do not touch them for months.

The third decision is not like that. It is continuous, and it is the one most teams quietly skip: how do you know the deployed code on that Function App is still the code your reviewers approved? How do you know the Logic App workflow definition has not been rewritten since last Tuesday? How do you know nobody added a federated identity credential to the managed identity at 3 a.m. on a Saturday?

The answer is monitoring. Not "we have Log Analytics turned on." Monitoring with a specific operating contract attached.

The posture inversion

For most Azure workloads, the default operating posture is reasonable trust. Engineers deploy. Pipelines run. Configuration drifts a little. The team reviews changes weekly. Anomalies are caught eventually.

For a Microsoft Entra extension, that posture is wrong. The default has to be inverted.

Once an Entra extension lands in production, every change to it is suspicious by default.

Not "needs review." Not "let's check first." Suspicious. The default state of an alert firing on a Function App that hosts a custom claims provider is "the SOC is investigating, prove this was approved." If you cannot prove the change was approved within the team's response SLA, the change is treated as an incident and rolled back. That posture is harsh on purpose. The same RBAC inheritance chain that lets a Contributor four management groups above your Function App quietly replace its code (the central argument of Part 1) is what forces the inverted default. You cannot rely on the deployment surface to be small. You have to rely on the alerting surface to be loud.

That inversion is the monitoring contract this article is about.

The three change surfaces

A production Entra extension has three change surfaces, and each one needs its own forced-diagnostics control, its own alert, and its own row on the operating contract.

Surface 1: the runtime itself

This is the surface most teams think of first, and the one most teams under-instrument. The deployed code on the Function App. The workflow definition on the Logic App. The App Settings. The environment variables. The runtime version. The configured custom domain. Each of these is a knob that, if turned, changes the behavior of the extension the next time Entra calls it.

For the custom claims provider Function App, the relevant Azure Resource Manager operations to alert on are:

Microsoft.Web/sites/extensions/write (a new deployment was pushed).
Microsoft.Web/sites/config/appsettings/write (App Settings were changed, including any reference to a Key Vault secret).
Microsoft.Web/sites/config/web/write (runtime version, startup command, or general configuration was changed).
Microsoft.Web/sites/publishxml/action (publish profile credentials were generated, which is one of the easiest ways to deploy code outside the normal pipeline).

For the dynamic approval Logic App, the analogous operations are:

Microsoft.Logic/workflows/write (the workflow definition itself was modified).
Microsoft.Logic/workflows/connections/write and Microsoft.Web/connections/write (an API connection was created or modified, including the authentication target it points at).

Each of these should be backed by an Activity Log alert scoped to the Control Plane subscription, with an action group that routes to the SOC's primary intake. Not to the team's chat channel. Not to an email list. The SOC's intake.

Surface 2: identity and RBAC

This is the surface that does not look like the extension at all and is therefore the easiest to ignore. The extension is unchanged. The blast radius around it is what changed.

Specific things to alert on, across the Control Plane subscription:

Microsoft.Authorization/roleAssignments/write anywhere on the inheritance path, from the resource up to the subscription. A Contributor (or User Access Administrator, or Owner) just appeared on a tier in the chain. Walk the inheritance (Azure RBAC overview) and ask: does this new principal now have effective Contributor on the Function App? If yes, the SOC needs to know.
Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write on any user-assigned managed identity in scope. A new federated identity credential is, by construction, a new way to act as that identity from outside Azure. Treat it as a credential issuance event, because that is what it is.
Microsoft.KeyVault/vaults/accessPolicies/write and Microsoft.Authorization/roleAssignments/write scoped to the Key Vault. Same logic as the RBAC inheritance, sharper consequence: Owner on the Key Vault is operationally Owner of every certificate in it.
App registration credential events in the Entra audit log. The Function App and the Logic App that back the extension are both fronted by app registrations or managed identities in Entra. A new client secret, certificate, or federated credential added to that app registration is an alert-worthy event, full stop. The Entra audit logs capture these as Update application – Certificates and secrets management events; pipe them into the same SOC intake.

Surface 3: the Entra-side binding

This surface lives entirely in Entra, not in Azure. The custom claims provider is bound to the application through a custom authentication extension configuration. The dynamic approval Logic App is bound to an access package through an entitlement management custom extension. Those bindings are what make Entra actually call your code. Change the binding, and Entra now calls somebody else's code instead.

Two specific events worth their own alerts:

Changes to custom authentication extensions in the Entra audit log: the endpoint URL was repointed, the API authentication configuration was changed, the extension was disabled.
Changes to entitlement management custom extensions: a new callback URL, a new authentication method, a change to the access package policy that consumes the extension.

The same Entra audit log feed that the IGA team already monitors covers most of this. The extra step is making sure the SOC sees it alongside the Azure Activity Log events, because the correlation between "the Entra binding moved" and "a deployment happened on the new target one hour earlier" is exactly the story you want analysts to be able to tell.

Forced diagnostics: making the signal undeniable

Alerts only fire if the signal reaches the alert engine. Three controls turn diagnostics from "we enabled it on most resources" into a property of the subscription itself.

Azure Policy with deployIfNotExists for diagnostic settings. Apply built-in or custom policies at the Control Plane management group that force every Function App, every Logic App, every Key Vault, every Storage Account, and every Managed Identity created underneath it to ship diagnostic logs to a dedicated tenant-level Log Analytics workspace. The policy is deployIfNotExists, not audit, so a missing diagnostic setting is repaired by the platform, not just reported on. There are existing built-ins covering Logic Apps and many resource types; custom definitions cover the rest. The principle is: it is not optional, and it is not possible to deploy a resource into this management group without diagnostic settings.

Azure Policy deny for tampering with diagnostic settings. A deployIfNotExists policy creates the setting. A complementary policy denies its modification or removal by anyone except a tightly-scoped platform identity. If an engineer cannot turn the diagnostic setting off, an attacker who compromises that engineer cannot either.

Resource Locks on the resource groups that host the extensions. Resource Locks at CanNotDelete for everything, ReadOnly for the resource groups that hold the runtime resources, applied at the resource-group level. ReadOnly does not prevent code deployments through the Function App's own publish endpoint, so it is not a substitute for the alert on Microsoft.Web/sites/extensions/write, but it does block the entire class of "an attacker recreates the resource with the same name and a different definition" attack.

Layered: policy forces diagnostics on, policy prevents diagnostics from being turned off, resource locks prevent the resources from being deleted out from under the diagnostics, alerts on the resulting log stream surface every change. Each control compensates for the failure modes of the others.

Correlation: the story the SIEM has to be able to tell

Each individual alert is signal. The value lives in the correlation across feeds. The SOC should be able to ask, and answer, questions like:

A token issued by Entra at 14:07 carried a claim asserting "department=Finance." The custom claims provider for that application is hosted on Function App fa-claims-prod. Did the deployed code on fa-claims-prod change in the last 24 hours? Did its App Settings? Did any role assignment land on it, its resource group, its subscription, or any management group above it?
An access package request was auto-approved at 09:21 for a privileged group. The dynamic approval Logic App that decided is la-dynapproval-prod. Did the workflow definition change in the last 7 days? Did any of its API connections get repointed? Did the Logic App's managed identity get a new federated credential?

Both questions are answerable with Azure Activity Log, Entra audit log, Function App and Logic App resource logs, and the extension's own application logs, all sitting in one Log Analytics workspace, with Microsoft Sentinel on top stitching them together. The Sentinel queries are the easy part. The hard part is making sure the three feeds are guaranteed to be there, which is exactly what the forced diagnostics controls deliver.

The operating contract: three states, not four

Every alert from any of the three change surfaces lands in one of exactly three buckets. There is no fourth.

Approved change. The deployment was pre-declared in the change management system. The change record carries the artifact hash, the pipeline run ID, the requesting engineer, and a declared start and end window. The alert correlates to the change record automatically (on pipeline run ID, on deployment principal, on time window) and is closed within minutes. The audit trail shows the alert, the correlation, and the closure.

Informational platform change. Microsoft platform-driven activity that you do not control: automatic certificate rotations on platform-managed components, Microsoft-side runtime version refreshes, Azure-managed identity key rotations, and similar. These still ship to the same workspace and still fire as Activity Log entries, but they route to a low-severity "platform" queue, not to the SOC's primary intake. Two rules govern this bucket: the events must be attributable to a known Microsoft service principal or platform operation (the actor identity on the Activity Log entry is non-human and matches an allow-listed Microsoft pattern), and the bucket must be reviewed at least weekly so it does not become a quiet hiding place. Anything that does not cleanly match a platform pattern falls through to the third bucket by default.

Incident. Anything that is neither pre-declared by a change record nor cleanly attributable to a Microsoft platform operation. SOC intake, paged on-call, automatic rollback if the runtime change can be reverted, manual investigation either way. The default reaction is to revert first and investigate after. The cost of a wrongly-reverted legitimate change is a Slack apology. The cost of a wrongly-allowed malicious change is a forged claim in a token your applications already trusted.

That is the entire operating model. Approved, informational-platform, or incident. No "we will look at it later." No "probably the platform team." If it does not fit one of the first two buckets within a tight automatic correlation window, it is bucket three.

The three-legged stool

Part 1 placed the resources correctly. Part 2 made sure they authenticate without leaking secrets. Part 3 makes sure that, once they are running, every change to them is either justified or visibly investigated. None of the three legs stands alone. A correctly placed resource without monitoring is one quiet deployment away from being someone else's resource. A perfectly monitored resource using a static API key is monitoring around an already-compromised credential. A managed identity in the wrong subscription is a credential model wasted on an over-permissive blast radius.

Built together, they are how Entra extensibility stays the thing that makes Entra a great product, rather than the thing that quietly hollowed it out. Use the extensibility. Put the code where it belongs. Authenticate it with the right credentials. And treat every change to it, from the first day it is in production, as a Control Plane event worth proving.

DEV Community: Anton Staykov

Authorization options for your AI agents with Entra Agent ID

User assignment as your outermost gate

Conditional access as authorization policy

App roles as delegated authorization claims

Group membership claims as attribute-based gates

Access packages as the unified control plane

Best practices on group emit scope and immutable identifiers

Composing the authorization stack

References

Flexibility with admin consent in Entra: how to scale consent flows for AI agents

The usual admin consent model does not scale

An app consent policy is a permission envelope

The custom role binds authority to the envelope

Policy authorship and consent execution are different jobs

Watch for alternate paths around the policy

A domain-based consent operating model

AI agents turn a useful feature into an architectural requirement

The question this architecture creates

References

Dynamic client registration and CIMD are not a trust framework

What DCR was designed to remove

What CIMD adds to the picture

The enterprise security gap

Entra's deliberate answer: explicit registration as a trust decision

APIM AI Gateway: the bridge, and where the gap remains

A governance stack, not a binary choice

References

Why consent is the trust contract for Entra Agent ID

Consent is authorization, not authentication

User consent and admin consent are different risk gates

Consent policy is a leadership decision encoded in platform behavior

Consent phishing proves whether your model is real

Delegated vs application permissions for agents, with protocol constructs that matter

Agent ID already blocks high-risk permission paths, by design

Access packages are the practical admin-consent engine for agent scale

Dynamic approvals, SoD checks, and custom logic make governance adaptive

A practical operating model for mixed technical leadership

The core decision

References

From JWT-SVID to Entra Agent ID: a working SPIFFE PoC

Five SPIFFE concepts in one minute

The components in play

How the process becomes a SPIFFE workload

The issuer is a public protocol surface, not a string

The federated identity credential binds one workload to the blueprint

The application requests the JWT-SVID only when MSAL needs it

fmi_path turns blueprint authentication into one agent identity

What the PoC proves

What the PoC deliberately does not prove

The trust contract is now executable

References

Your SPIFFE workload can authenticate as an Entra Agent ID, but mind the trust gap

SPIFFE and Entra answer different questions

Only one of the two SVID forms fits the exchange

The bridge is an exact three-claim contract

The token flow, without the hand-waving

A SPIFFE bundle endpoint is not OIDC discovery

Short-lived bearer tokens can still be replayed

Rotation now crosses an organizational boundary

The 20-credential limit is an architecture signal

Workload federation authenticates the client in both autonomous and OBO flows

The production decision

References

Microsoft Graph least privilege has two control planes

The first plane: Graph permissions authorize the client

The second plane: Entra controls who can control the thing doing the calling

Owner is not a label, owner is control

The bad pattern: broad Graph permission plus casual ownership

Scoped Entra roles are the missing design tool

Administrative units are not just for humans

The widely unknown pattern: service principal plus administrative-unit scope

Why this changes Graph automation design

A practical model for app teams

The sentence to bring to your next design review

References

Enterprise architects: your overdue Entra decision is an agent CSA schema

The control plane starts with classification

Why agents raise the stakes

Reuse your existing workload schema or create a dedicated agent schema?

`fmi_path` turns blueprint authentication into one agent identity