DEV Community: Anton Staykov

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.

References

Securing the code that decides who Entra trusts: a Function App and a Logic App, end to end

Anton Staykov — Thu, 02 Jul 2026 10:37:00 +0000

Part 1 of this series, [[Entra-Extensibility-Is-Control-Plane]], made the case that every Microsoft Entra extension point hands a piece of the Entra trust boundary to a system Entra does not own. The Azure resources that host that code sit on the Control Plane (in the modern Microsoft Enterprise Access Model, what the legacy tiered model called Tier 0). The Azure RBAC inheritance chain makes them dangerously easy to compromise from far up the management-group tree, and they deserve a placement and a guardrail set normally reserved for domain controllers and Entra Connect.

This article gets concrete. Two real extension scenarios, end to end, and then the question that decides the security of both: what credential does the extension use when it calls out?

Example A: a custom claims provider backed by an Azure Function

The first scenario is the one most likely to land in a production tenant in the next six months. A team needs to inject custom claims into the access tokens issued to their applications. The supported path is a custom claims provider, implemented as a REST endpoint that Entra calls during the token issuance event. The reference implementation is an Azure Function.

The flow, in one paragraph. A user signs in to an application registered in Entra. Entra's token issuance pipeline reaches the configured custom claims provider extension. Entra calls the Function App's HTTPS endpoint with a server-to-server access token in the Authorization header, exactly as documented in the step that covers protecting your Azure Function. The Function validates the incoming token (issuer, audience, signature), inspects the request body, calls whatever upstream sources it needs to resolve the claims it cares about, and returns a JSON response describing which claims to add to the outgoing token. Entra builds the access token, including the returned claims, and hands it to the relying application. The application makes authorization decisions based on those claims.

Read that one more time. The application makes authorization decisions based on those claims. The Function App controls what your applications see. A compromised Function App is, in practical terms, a claim forger sitting inside your token issuance pipeline. Whatever an attacker can put in a returned claim, the downstream application will trust as if Entra had asserted it.

The blast radius of that Function App is therefore the union of everything that can change what code runs in it:

The source repository. Branch protection, code-owner approvals, the list of users with push rights to main, the list of users with admin rights on the repository who can bypass protection, and every CI configuration file that ships with the repo.
The CI/CD pipeline definition. Who can edit it, who can re-run it with arbitrary inputs, who can change which artifact gets deployed at the end of a run.
The identity the pipeline uses to deploy to Azure. This is the credential that lets the pipeline rewrite the Function App's code at any time. If that credential is a client secret stored as a CI variable, the Function App's code is one leaked variable away from being replaced.
The Function App resource itself, and every security principal that has Website Contributor, Contributor, or Owner on it directly. These principals can replace the deployed ZIP without ever touching the repository.
The resource group, the subscription, every management group above the subscription, and the root. As Part 1 walked, Contributor at any level inherits down. A Contributor (any role) on the root management group does not need to be a member of your identity team to replace your Function App's code.
The Key Vault holding any secrets, certificates, or connection strings the Function uses to talk to upstream systems. Owner on that Key Vault is, for practical purposes, Owner on the Function's ability to authenticate outbound.
The App Service Plan, because deployment slots, scaling rules, and runtime versions sit at that scope.

A real custom claims provider in production has to harden every item in that list. Missing any one of them is enough.

Example B: a Logic App backing dynamic approval for an access package

The second scenario is governance-shaped. An access package in Microsoft Entra entitlement management is configured to use dynamic approval, so that the approver of a request is selected at runtime by an Azure Logic App rather than statically declared in the policy.

The flow. A user requests assignment to the access package. Entitlement management invokes the configured Logic App, passing context about the requestor and the package. The Logic App runs whatever workflow you have authored. Typically that workflow needs to call Microsoft Graph (to resolve the requestor's manager, project assignment, or group membership) and at least one external system (a leave or vacation calendar, a shift roster, an IT change management board, a project allocation tool). The Logic App returns the identity of the human or group who should approve, or in some variants it short-circuits and returns an approval or denial directly. Entitlement management then routes the request accordingly.

The Logic App is now part of your access governance. If an attacker can rewrite the workflow, the attacker can name themselves as the approver for any access package that uses this dynamic approval policy. Or worse: rewrite the workflow to return "auto-approve" for a specific requestor and never invoke a human at all.

Most of the Function App blast-radius list applies here too, with one extra wrinkle. A Logic App often has fewer source-code artifacts (the workflow can be authored directly in the portal, although authoring it through a code project under source control is strongly recommended for exactly the reasons we are discussing). What a Logic App always has, in abundance, is connections. The Microsoft Graph connection, the SharePoint connection, the HTTP connector pointing at the change-management API, the Salesforce connection for project data. Each connection is a credential the Logic App will use, and each credential is something an attacker would happily inherit if they took ownership of the Logic App resource. The connection objects themselves are Azure resources in the same resource group, subject to the same RBAC inheritance chain.

The surface is broader than the Function App's. The principle is the same. The Logic App is Control Plane because of who calls it and what its answer is used for.

The credential ladder

Both examples force the same question. Once your code is running, what does it use to authenticate when it calls downstream? Microsoft Graph, the corporate HR system, a SharePoint list, an external SaaS API. Pick one. There are three honest answers, and they are not equivalent.

Static keys: assume already compromised

A static API key, or the symmetric client_id plus client_secret pair, is the least secure credential you can use, and you should treat it as already compromised. That is not hyperbole and it is not a "best practice" framing. It is the structural reality.

You did not pick the entropy. You do not know who pasted it into a chat window during an incident three years ago. You do not know whether the developer who first received it stored a copy in their personal note-taking app. You do not know whether the CI variable holding it was visible to the build agent's logs at some point during a regression. You do not know whether the rotation calendar reminder fired, and you do not know whether the previous value was scrubbed from every place it was ever stored.

For non-critical workloads, this is a manageable risk. For code that decides what claims your applications see, or who approves access to your most sensitive packages, it is not. If your Control Plane Entra extensions are still authenticating outbound with static symmetric credentials, the rest of your Zero Trust program is theater for that path.

Certificates: better, but only as strong as their issuance and storage

Certificate-based authentication is genuinely a step up. The credential is asymmetric, the private key never has to leave the host that uses it, and the rotation story is cleaner. The honest assessment, though, is that a certificate is only as secure as the process that produces, transports and stores it.

Be specific about the questions a certificate forces you to answer. How was the certificate issued: by a managed PKI, by your tenant's own CA, by a developer with openssl at a laptop? How did the public key end up in the Entra app registration credentials: a portal upload by a human, a pipeline call to Microsoft Graph, a manual step in a runbook? Where is the private key stored: on the host filesystem, in an HSM, in a Key Vault? If it is in Key Vault, is it non-exportable, or did someone tick the wrong box when they imported it? Was the certificate generated inside the Key Vault, or was it generated elsewhere and imported, in which case the original private key existed somewhere outside the HSM at least once?

And then the question Part 1 of this series spent an entire section on: who has Owner on that Key Vault? Walk the Azure RBAC inheritance chain from the Key Vault up through its resource group, its subscription, its management groups, and the root. Every Owner along that chain is, for practical purposes, an Owner of every certificate in that Key Vault. The certificate is not as static as a symmetric key, but the principals who can extract or replace it follow the same inheritance rules every other Azure resource follows.

A certificate in a Key Vault inside a wide-RBAC subscription is, operationally, not very different from a static key with extra steps. The credential improved. The principal model around it did not.

Managed Identities: the right baseline

The managed identity is the right baseline for any Entra extension hosted on Azure compute. The platform manages the credential. The compute resource (Function App, Logic App, App Service, container) requests an access token from a local metadata endpoint. Entra issues it. No human, no pipeline, no developer ever sees a secret.

When the call has to leave Azure, Workload Identity Federation extends the same pattern across trust boundaries. A managed identity can act as the credential for an Entra app registration through a federated identity credential, and an Entra-issued token can be exchanged for an external system's token as long as that system supports the OpenID Connect / RFC 7523 pattern. The longer treatment of how this composes for AI agent platforms is in Your agentic platform doesn't need a single secret, and most of the same building blocks apply when the workload happens to be an Entra extension instead of an agent runtime.

Even the right answer comes with its own discipline. A managed identity is not a free pass. Two specific guardrails matter:

System-assigned by default. A system-assigned managed identity is lifecycle-bound to a single Azure resource. Delete the resource, the identity is gone. Replace the resource, the new instance gets a brand-new identity that must be re-granted permissions. That friction is the whole point. It makes the credential and the resource indistinguishable, which is exactly what you want for a Control Plane workload.
User-assigned managed identities are subscription-scoped reusable identities. A user-assigned MI lives in a resource group and can be attached to any number of resources in the same tenant. That convenience is also a risk. Any Contributor on a resource in the same subscription can attach the same managed identity to a new resource of their choosing, and that new resource can now act as the privileged caller into Microsoft Graph. Treat user-assigned MIs that hold real downstream permissions as Control Plane objects of their own, place them in the same dedicated Control Plane subscription as the workloads that use them, and never share one across planes.

When a managed identity is placed correctly, on a Control Plane resource, in a Control Plane subscription, under a Control Plane management group, the answer to "who can use this credential against Microsoft Graph" collapses to "exactly the workloads I deployed there, and exactly the principals who have rights to deploy to that subscription." That is the credential model these extensions deserve.

Putting the two halves together

Part 1 of this series argued that Entra extensions belong on the Control Plane because of what they decide. This article argued that the security of those decisions is the security of the smallest detail underneath them: the source repository, the pipeline identity, the runtime principal model, the credential the runtime uses to call out, the Key Vault that backs it, the RBAC inheritance above all of them.

There is a uniform answer to the placement question. The Function App, the Logic App, the Key Vault, the user-assigned managed identities, the connections, the API connectors all belong in a dedicated Control Plane subscription under a dedicated Control Plane management group, directly under the root. Not in the platform identity subscription, not in a shared services subscription, not in an application landing zone. The list of principals with Contributor or Owner anywhere on the chain above those resources has to be short, audited, and reviewed on a cadence shorter than your access-review cycle.

There is a uniform answer to the credential question too. The default credential for a Control Plane Entra extension is a managed identity, scoped tightly, lifecycle-bound where possible, system-assigned where possible, with federated identity credentials covering the cases where the call has to leave Azure. Certificates are a tolerated middle step when the call truly has nowhere else to go. Static symmetric keys are not an option for code that influences Entra decisions, full stop.

Use the extensibility. It is what makes Entra a great product, and the next year will keep adding new hooks worth using. Just host the code behind those hooks the same way you host the things Entra is protecting. The point of a Zero Trust enforcement engine is undermined the moment its decisions are shaped by code anyone can quietly replace.

References

Microsoft Entra extensibility is a gift. It is also Control Plane.

Anton Staykov — Tue, 30 Jun 2026 09:17:00 +0000

Microsoft Entra is the Zero Trust policy enforcement engine sitting at the intersection of identities, endpoints, AI agents, networks and data. Every conversation about Conditional Access, every Privileged Identity Management workflow, every access package review, every token issued to an application or an agent: it all funnels through Entra. That is the entire point of the product, and that is why so much of the security industry's energy is spent hardening it.

The most interesting thing happening to Entra right now is not a new policy type. It is extensibility. In the last few years Entra has quietly become one of the most extensible identity platforms in the enterprise market. Custom authentication extensions let your code shape token issuance and authentication events. External authentication methods plug third-party MFA providers into the sign-in pipeline. PIM custom extensions let your business logic approve or deny privileged role activation. Lifecycle workflow custom task extensions let your code influence whether an employee account is enabled, disabled, or transformed. Entitlement management talks to Logic Apps for governance workflows, and a specific variant, dynamic approval, lets your code decide who approves an access package request, or whether the request should be approved at all. More extension points are coming. The trend line is obvious.

This is genuinely good. Identity decisions are business decisions, and business logic belongs in code your business writes. Extensibility is what turns Entra from a fixed product into a programmable enforcement engine, and that is the right direction.

It is also the part where the security conversation almost always stops.

The reframe nobody wants to write

Every extension point hands a piece of the Entra trust boundary to a system Entra does not own. The decision is still announced from Entra. The signal that drives the decision is shaped somewhere else. That somewhere else is now Control Plane, in the language of Microsoft's current Enterprise Access Model (what the legacy tiered administration model used to call Tier 0). Control Plane is the set of systems that grant access to everything else: the directory itself, the privileged groups inside it, and now, by extension, any code that shapes a directory decision at runtime.

Sit with the implications for a minute, scenario by scenario:

A PIM custom extension can influence whether an identity gets a high-privilege role activated, in milliseconds, with no human in the loop. The endpoint that responds to PIM is now part of your privileged-access path.
A lifecycle workflow custom task extension can be the anchor that decides whether a leaver's account is actually disabled tomorrow morning. The code that answers that workflow call is now part of your joiner-mover-leaver process.
A Logic App driving dynamic approval can decide who is allowed to approve a request for a sensitive access package, or whether the request gets pre-approved with no human reviewer at all. The Logic App is now part of your access governance.
An Azure Function backing a custom claims provider can inject custom claims into the access tokens your applications consume. The Function is now part of your token issuance.

Every one of those endpoints is a Control Plane system. Not "important." Not "in scope for the next pentest." Control Plane. The same category you reserve for your domain controllers, your Entra Connect server, your root CA, and the accounts that can write to any of them.

Most security writing about Entra extensibility focuses on the Entra side: how to register the extension, what scopes it needs, how the audit log captures the call. That work is necessary and well covered. The Azure side, where the actual code runs, is barely covered at all. That is the gap I want to close.

The Cloud Adoption Framework already saw half of this

The Azure Cloud Adoption Framework and the Azure landing zones reference architecture do something deliberate: they split platform landing zones from application landing zones, and inside platform they carve out a dedicated identity subscription for identity-related infrastructure. The subscription organization guidance treats identity as its own thing, not as a workload that shares a subscription with marketing analytics.

That is exactly the right instinct. The problem is that the identity subscription is almost always described as the home of legacy identity infrastructure: Active Directory Domain Services domain controllers, Entra Connect, a Privileged Access Workstation jump box, maybe a few related VMs. It is described as the place where the identity infrastructure that runs in Azure lives.

It is not yet described as the place where the Azure compute that influences Entra decisions at runtime lives. That is a different category, and it did not really exist five years ago in the volume it exists now. A landing zone designed in 2021 was not built to host the Function App behind your custom claims provider, the Logic App behind your dynamic approval policy, the queue-triggered Function that decides whether a lifecycle workflow disables an account. None of that was a workload pattern then.

It is now. And those workloads are at least as sensitive as Entra Connect, because they execute on every relevant identity event, and a successful tamper does not generate the noisy reconfiguration footprint that touching Entra Connect would generate. They are quieter and at least as powerful.

The Azure RBAC inheritance chain is the trap

Here is the part of the picture that does not get said out loud enough. Azure role-based access control inherits top-down, and the inheritance is unbreakable. A role assignment at a resource, resource group, subscription, management group, or the tenant root management group flows downward to every resource underneath. Contributor at the resource group flows to the resource. Contributor at the subscription flows to every resource group in it. Contributor at the management group flows to every subscription. Contributor at the root management group flows to everything.

This is fine for most workloads.

It is corrosive for workloads that influence Entra decisions.

That sentence is the entire argument of this article. Read it once more. The same RBAC model that makes Azure pleasant to operate at scale is the model that lets a Contributor four management groups above your Function App quietly become the author of the claims your applications trust. There is no Entra-side hardening that fixes this. There is no Conditional Access policy that fixes this. The fix is structural, and it lives in Azure.

Picture an organization with a moderately mature Azure footprint. There is a platform management group, an application management group, a couple of regional management groups, a Sandbox management group, a Production management group. The custom claims provider Function App lives in a shared "platform services" subscription because that is where the platform team puts platform things. Now ask the inheritance question: who is Contributor on that subscription? Who is Contributor on its parent management group? Who is Contributor on the root? In most organizations the answer is "more people than you think, and at least one service principal you forgot about." Any one of them can replace the deployed code on that Function App. They do not need to touch the source repository. They do not need to break the CI/CD pipeline. They just deploy a new ZIP. The next time Entra calls your custom claims provider, it is calling their code.

Source-control hardening is necessary and frequently celebrated. It is also not sufficient on its own, because Entra does not invoke your repository. Entra invokes the runtime.

Where these resources actually belong

My direct take. The Azure resources that host code which influences Entra decisions are Control Plane resources. They belong either:

directly under the root management group, in a dedicated subscription that exists for exactly this purpose, or
one level deeper, under a dedicated Control Plane management group that itself sits directly under the root.

Not deeper. Not in the platform identity subscription where your domain controllers live. Not in a shared services subscription. Not in an application landing zone, ever. The blast radius of "any Contributor anywhere on the inheritance path can swap the runtime" forces the resources up the tree, into a place where the list of principals with write rights is short, audited, and reviewed.

That choice has follow-on consequences. Resources at the top of the hierarchy do not benefit from the policies and guardrails the landing zone reference architecture applies further down. The dedicated Control Plane management group needs its own policy set: deny-by-default network rules, mandatory diagnostic settings to a tenant-level log analytics workspace, deny-create policies for everything except the resource types you actually need, and Resource Locks at the resource group level that survive the people who set them. Pinning these things at the top of the tree means designing them at the top of the tree.

The questions you must be able to answer

Before any Entra extension goes into production, the team that owns it has to be able to answer each of these without hedging:

Who controls the source code? Specifically, who has push rights on the protected branch, who can bypass branch protection, and who can approve a pull request?
Who controls the CI/CD pipeline? Who can edit the pipeline definition? Who can re-run a failed deployment with a different artifact?
What identity does the pipeline run as when it deploys to Azure? If it is a service principal with a client secret or a stored certificate, treat that credential as already known to the threat actor.
Who can directly replace the runtime, bypassing source and pipeline entirely? Walk the full RBAC inheritance chain from the resource up to the root, including every group, service principal, and managed identity with Contributor, Owner, or User Access Administrator.
Where do the credentials this extension uses to call downstream systems live? Who has Owner on that Key Vault? Walk the inheritance chain again.
Does the extension run with a system-assigned managed identity, a user-assigned managed identity shared with other workloads, a certificate in a Key Vault, or a client secret? Each answer has a different blast radius.
How fast can you detect that the deployed code on the Function App or the deployed logic on the Logic App has changed? How fast can you detect that a role assignment was created on the hosting subscription or one of its parents?

If any of those questions is uncomfortable, the extension is not yet ready to be invoked by Entra in production.

What comes next

The two scenarios I want to walk in detail are a custom claims provider backed by an Azure Function and a dynamic approval Logic App backing an entitlement management access package. Both are concrete. Both are increasingly common. Both expose the entire chain: source repository, pipeline identity, runtime resource, hosting subscription, RBAC inheritance, downstream credentials, Key Vault, the lot.

And both lead into a question that deserves a fair, opinionated answer: what credential should that code use when it has to call back into Microsoft Graph or out to an external system? Static API key, certificate, or managed identity? Each option has a real failure mode and a real guardrail. The right answer is rarely the convenient one.

That is the subject of the next article in this series. Where Part 1 makes the case that Entra extensibility is Control Plane, Part 2 will walk the two examples end to end and grade the credential ladder beneath them. Watch this space.

The goal of this series is not to talk anyone out of using Entra extensibility. The opposite. Use it. It is what makes Entra a great product. Just host the code that influences Entra decisions the same way you host the things Entra is protecting.

References

One identity, two clouds: an AWS-hosted agent that authorizes with Microsoft Entra Agent ID

Anton Staykov — Tue, 23 Jun 2026 09:23:00 +0000

There is a quiet assumption baked into most identity conversations, and it usually goes unstated because everyone in the room already believes it: Microsoft identity is for Microsoft resources, and you run it on Microsoft infrastructure. Both halves feel so obvious that nobody bothers to test them.

So I tested them. I built a proof-of-concept where an AI agent runs entirely on AWS, holds its own Microsoft Entra Agent ID, and uses that single identity to authorize calls to resources on both sides of the cloud boundary: a Microsoft service and an AWS Lambda. The agent never touches Azure compute. The Lambda never sees an AWS credential on the call. And nothing about it required a special bridge, because the bridge already exists and it is called OAuth.

The sample is astaykov/agentid-agentcore. This is the walkthrough of why it works, written for the architect whose first reaction to "Microsoft Entra in my AWS stack" is a raised eyebrow.

The shape of it, stated plainly

A browser single-page app signs the user in with MSAL.js and hands the resulting access token to an agent. The agent is hosted on AWS Bedrock AgentCore Managed Runtime, a fully managed runtime for agents. Inside that runtime, the agent acts on behalf of the signed-in user against two downstream resources:

an AWS Lambda, fronted by an API Gateway HTTP API (the PoC calls it the Echo API), and
the Microsoft MCP Server for Enterprise, the Microsoft-hosted tool surface over Microsoft Graph.

User
  ↓  sign-in (MSAL.js)
Browser SPA
  ↓  Entra access token  [Bearer, header-only]
AgentCore Managed Runtime  ── hosted on AWS, holds an Entra Agent ID
  ├─→  AWS Lambda  (API Gateway HTTP API, native JWT authorizer)
  └─→  Microsoft MCP server

Read that topology again and notice what is not in it. There is no Azure virtual machine, no Azure Container App, no Azure Function. The compute is 100% AWS. The identity is 100% Microsoft Entra. Those two facts are usually assumed to travel together. They do not.

The AWS resource is the whole point

It would be an unremarkable demo if the agent only called Microsoft services. Of course a Microsoft identity opens Microsoft doors. The claim that actually needs proving is the other one: that a Microsoft Entra-issued token can open an AWS door.

So look closely at the Echo API. It is an AWS API Gateway v2 HTTP API in front of a Lambda function. Nothing about it is Microsoft. And its access control is a native API Gateway JWT authorizer, the AWS-built-in kind, configured with exactly two things:

an issuer of https://login.microsoftonline.com/{tenant}/v2.0, and
an audience equal to the Echo API's own app registration.

That is the entire trust configuration. An AWS resource, gated by an AWS-native authorizer, that grants access only when presented with a token minted by Microsoft Entra and bound to the signed-in user. No Cognito. No IAM SigV4 signing on that request. No custom Lambda authorizer doing bespoke validation. The AWS platform validates a Microsoft token because, to an OIDC-aware authorizer, Microsoft Entra is simply another standards-compliant issuer.

This is the sentence I want the skeptical AWS architect to sit with: your API Gateway already knows how to trust Microsoft Entra. You have not been told to think of it that way, but the capability has been there all along.

Same identity, the Microsoft side

The same agent, carrying the same identity, also calls the Microsoft MCP server. One agent. One Entra Agent ID. Two destinations in two different clouds, each handed a token scoped to it, each validating that token on its own terms.

This is what makes Entra Agent ID interesting as an identity layer rather than a Microsoft-only convenience. The agent is not "an AWS thing that occasionally phones Microsoft." It is a governed identity in Microsoft Entra (an agent identity created from a blueprint) that happens to be hosted on AWS, and it reaches whatever it is authorized to reach regardless of which cloud the resource lives in. Microsoft's own documentation is explicit that Entra Agent ID works with agents built on non-Microsoft platforms, AWS Bedrock among them. The PoC is just that statement made concrete.

Why this should land for an AWS architect

The instinct to distrust cross-vendor identity is healthy, because most of it historically meant proprietary glue: a connector, an SDK shim, a sync job that copied identities from one directory into another and drifted out of band within a quarter. None of that is happening here.

What is happening is plain OAuth 2.0 and OpenID Connect:

✅ The AWS authorizer trusts an OIDC issuer. Entra publishes standard OIDC discovery metadata; the authorizer validates iss, aud, and signature against it. This is the same mechanism you would use to trust any external IdP.
✅ The agent acquires resource-scoped, user-bound tokens through a standard on-behalf-of style exchange. The user's sign-in is turned into a token audienced to each specific downstream resource before the call is made.
⚙️ The agent runtime does use MSAL Python to perform the exchange. That is not a proprietary bridge between the clouds; it is Microsoft's standards-based authentication library, the same one you would reach for to speak OAuth and OIDC to Entra from any Python application. The wire protocol is still OAuth and OIDC. MSAL is simply the most direct way to speak it from the agent.

If you already federate your AWS workloads to Microsoft Entra ID for human sign-in, this is the next step: it is time for your AI agents to get their identity from there too.

The token exchange, kept in its lane

There is real machinery behind "acts on behalf of the user," and it is worth one honest paragraph rather than a victory lap of acronyms. Before each downstream call, the agent converts the inbound user token into a token scoped to the specific target resource, in-process, using MSAL Python. The result is a token whose audience is the AWS Lambda for the Lambda call, and the MCP server for the MCP call, with the original user identity preserved throughout. The two-stage exchange that Entra Agent ID uses to do this is documented here; it is the plumbing, not the headline. The headline is that the user's delegated context survives the entire trip, across clouds, to the downstream resources. And this chain can be infinite hops long.

The security posture, briefly

A few properties matter more than the rest:

🔐 The agent never hands a credential to the model. Tools return only their response payloads; the inbound token lives in a tightly scoped variable that is cleared in a finally block after every invocation and never reaches the LLM.
🔍 Tokens are never logged. Only non-secret routing claims (issuer, audience, app id, scope, and the user's object id as a cache key) are emitted, never a token, header, or signature.
The blueprint credential is read once per process and dropped from memory immediately after the client is constructed.

And the honest production caveat, because a PoC that hides its rough edges is selling something: this sample authenticates the agent's blueprint with a client secret, which is fine for a demo and explicitly not recommended for production. The production path is a certificate or, better, a managed identity used as a federated credential so there is no stored secret at all. I have made the broader case for a secret-less agentic platform before.

What's next, and the thesis

The current PoC still keeps one secret on the AWS side: the blueprint credential. The next step closes that gap in the most fitting way possible: register AWS's own STS as a federated identity credential the Entra blueprint trusts, and let AWS issue the token that proves the agent's identity to Microsoft. At that point the loop is closed in both directions. AWS resources trust Microsoft-issued tokens, and Microsoft trusts AWS-issued tokens, with no shared secret anywhere between them.

That is the whole thesis, and it is smaller than it sounds: a resource trusts a token, not a cloud. The delegation semantics that have governed middle-tier APIs for years did not change when the middle tier became an AI agent, and they do not change when that agent moves to AWS. An identity is a protocol boundary. If your Lambda can trust Microsoft Entra Agent ID, your agent can run anywhere.

References

A transformational AI agent does not start with the permissions it needs

Anton Staykov — Wed, 17 Jun 2026 09:13:00 +0000

Most teams are still building AI agents the way they built automation in 2019: create an identity, shovel a pile of permissions onto it, pray the list is not too dangerous, and call that least privilege. That model was weak for static applications. For AI agents, it is worse.

An agent is not a static script. Its value comes from encountering new situations, discovering new APIs, and taking on work that was not fully known at deployment time. Pre-authorizing that kind of system is like issuing a master key because you do not know which doors the employee will need next month. Convenient, yes. Serious architecture, no.

The more useful pattern is the opposite: start the agent with effectively zero useful permissions for the task in front of it, let it discover what permission is actually missing when it hits a boundary, and force any expansion of access through a governed path such as access packages for agent identities. That is the pattern I wanted to understand better, so I built a practical sample around it.

The sample is astaykov/n8n-aca, a one-command starter for n8n on Azure Container Apps with Entra Agent ID. From Azure Cloud Shell, azd up provisions the Azure infrastructure, creates the Entra objects, installs the custom Entra Agent ID node for n8n, wires the credentials, imports the workflows, and activates the triggers. It is the fastest way I know to get from "I want to test agentic identity patterns" to a running system without spending the afternoon on scaffolding.

That convenience is not the interesting part, though. The interesting part is what the sample made easy to test: an autonomous agent on Microsoft Entra Agent ID that authenticates with its own identity, uses application permissions when it needs Microsoft Graph, and expands its access only through ID Governance when a real task justifies it.

The sample is the on-ramp, not the point

The repo gives a practical "one-click" starting point, even if the literal mechanism is a single command rather than a portal button. It deploys n8n on Azure Container Apps, provisions the surrounding Azure services, and creates the Entra building blocks you need: an agent identity blueprint and agent identity, plus the n8n credentials and workflows that let you immediately test autonomous and assistive patterns.

That matters because identity architects do not need another abstract reference architecture. They need something they can stand up, inspect, and break. The sample gives you that. But the design pattern it enables is the real story.

Microsoft Entra Agent ID exists precisely because traditional, deterministic application identities are the wrong abstraction for agents that evolve in production. Microsoft says that plainly: classic application identities were designed for static workloads and do not bring the governance model agents need, while agent identities and blueprints add lifecycle, sponsorship, and policy structure that maps to how agents actually operate. Once you accept that framing, the next question becomes obvious: if the identity model is dynamic, why are we still designing permissions as if they were static?

The right starting state is deliberate under-permissioning

When people hear "start with zero permissions," they often imagine an unusable toy. That is not what I mean.

I mean zero useful permissions for the specific task the agent has not encountered yet.

The authorization model for Entra Agent ID already points in that direction. Agents can use delegated permissions or application permissions, but high-risk permissions are blocked, lower-privilege access is preferred, and administrators are expected to grant access in a scoped way. Governance for agent identities goes one step further by describing access packages as the structure through which agents can receive OAuth application permissions, group memberships, and Entra roles in a time-bound, auditable way.

That combination changes the design target. The goal is no longer "figure out every permission the agent might need before go-live." The goal is "build an agent that can recognize a missing permission, identify the governed package that provides it, and request it through policy."

That is the shift. It is subtle, but it is the whole game.

Where the pattern actually lives in n8n

At a glance, the workflow looks almost too simple to carry this much identity behavior: webhook in, token acquisition, AI agent, webhook out. That is exactly why the image earns its place here. The interesting part is not the number of nodes. It is the control logic concentrated inside the agent and its tools.

The workflow is intentionally compact. The design pattern does not live in a sprawling orchestration graph; it lives in the policy encoded into the AI Agent node and the constraints encoded into the Microsoft Graph tool.

In my workflow, the pattern is not hidden in a policy engine or spread across ten helper scripts. It lives in two very concrete places:

The system prompt for the AI Agent node.
The custom configuration of the HTTP Request tool that calls Microsoft Graph.

That is worth emphasizing because too many "agentic architecture" discussions still pretend the prompt is fluff. It is not. In a tool-using agent, the system prompt is operational policy.

The n8n AI Agent node is a tools-based agent. It receives the user request, chooses tools, reasons about tool responses, and keeps going until it can answer or it hits a policy boundary. In this workflow, the agent is told something very specific:

You are an AI Agent with your own Microsoft Entra identity.
You authenticate as yourself using Microsoft Graph application permissions.
When any API call returns 401 or 403, do NOT give up.
Identify the exact permission, search access packages, inspect each package,
and request the matching package if self-request is allowed.

That instruction is doing real architectural work. It teaches the agent to treat 401 and 403 as a discovery loop, not as a dead end.

It also teaches the agent to stay honest about what kind of access it has. The prompt explicitly says it only works with application permissions for Microsoft Graph. That matters because Entra Agent ID distinguishes autonomous agents from assistive agents, and the permission model is different depending on whether the agent is acting as itself or on behalf of a user. For this workflow, the autonomous case is the point.

The Microsoft Learn MCP server is the underrated component

The agent has two tools in the workflow: a Microsoft Graph HTTP tool and a Microsoft Learn MCP client pointing at https://learn.microsoft.com/api/mcp.

That second tool is the underrated component.

The Microsoft Learn MCP Server is public, free, and does not require authentication. More importantly, it gives the agent runtime access to official documentation and code examples through MCP instead of forcing you to hardcode every Microsoft Graph rule into the prompt. That is what turns the workflow from "an agent with a bag of fixed API calls" into "an agent that can learn how to call Graph correctly when it needs to."

In practice, that means the agent can look up an endpoint, confirm which permission is required, and use the error it just received to tighten the search. That is the missing bridge between language-model flexibility and enterprise identity controls. Without it, the agent is guessing. With it, the agent has a documentation brain.

The HTTP tool matters just as much as the prompt

The n8n HTTP Request node is versatile enough to be dangerous, which is exactly why the custom tool configuration matters.

In this workflow, the HTTP tool is constrained to https://graph.microsoft.com, prefers /v1.0/ over /beta/, uses a predefined bearer credential, and is instructed to research the endpoint before writes. More importantly, it is configured to return the full response and never error. That is not a cosmetic choice. It means the agent gets the status code and body back even when Graph refuses the call, so it can reason over the authorization failure instead of having the workflow short-circuit.

That one setting turns a generic REST tool into a permission-discovery instrument.

The tool instructions also tell the agent to confirm state-changing operations before execution, except for one case: creating an access package assignment request. That exception is deliberate. If the whole point is to let the agent acquire governed access in context, then the request path itself needs to be part of the autonomous loop.

How the governed escalation loop works

The loop is simple enough to explain, which is usually a sign you are finally dealing with the right abstraction.

First, the agent attempts the Graph operation the user asked for.

If Microsoft Graph returns 401 or 403, the agent uses the error plus the Learn MCP server to identify the exact missing permission. The prompt forces it to write down the permission explicitly and to treat it as an application permission in this workflow.

Next, it enumerates the available access packages with GET /identityGovernance/entitlementManagement/accessPackages. Then it inspects the package contents through resource role scopes, looking for the role that maps to the missing permission. This is the key architectural move: the agent is not inventing new access. It is discovering which pre-governed package the identity team already made available.

Once it finds the matching package, it reads the assignment policies to determine whether self-request is allowed. If it is, the agent creates a POST /identityGovernance/entitlementManagement/assignmentRequests call for itself. If self-request is not allowed, it gives the user the package name, what it grants, and the My Access link so the user, their manager, or the sponsor can request it on the agent's behalf.

That is the pattern in one sentence: the agent can discover and request governed access, but it cannot bypass governance.

This is why access packages for agent identities matter so much. Microsoft explicitly supports three pathways: the agent can request access programmatically, the sponsor can request it on behalf of the agent, or an administrator can assign it directly. The workflow leans into those pathways instead of trying to outsmart them.

Why identity architects should care

This is not just a clever n8n trick. It is a better control model.

When an identity team pre-grants broad application permissions to an agent, they are making an up-front guess about future behavior. Those guesses age badly. They are rarely revisited, almost never shrunk, and eventually become the authorization equivalent of legacy firewall rules.

Access packages change the conversation. They let the identity team define bundles of allowed access, the approval and request policies, the expiration model, and the human accountability path. The agent still moves fast, but the boundary conditions are owned by governance, not improvised in code.

That is why I think this pattern matters: it decouples permission discovery from permission approval.

The agent is free to discover what it needs. The organization is still in control of whether that need maps to an approved package, whether self-request is allowed, who must approve it, and when the access expires. That is a much more adult architecture than stuffing Directory.Read.All into an app registration because the pilot customer wants the demo today.

The uncomfortable but necessary conclusion

The industry still talks about agent permissions as if the main design question were "what should this agent have?" That is already the wrong question.

The better question is: how should this agent acquire access when reality teaches us that the original permission set was incomplete?

If your answer is "we will update the app registration manually," you do not have an agentic permission model. You have an operations backlog.

If your answer is "the agent starts narrow, learns what permission is missing from the task and the docs, maps that need to a governed access package, and either requests it or hands the human the approval path," then you are finally designing for the world these systems actually live in.

That is what this sample helped me understand. n8n on Azure Container Apps with Entra Agent ID is a useful accelerator. The deeper lesson is the design pattern itself: agents should not begin life over-permissioned. They should begin life constrained, then earn their scope through policy, context, and governance.

That shift is the part identity architects should care about.

References

Seeing every agent sign-in in one place: an Azure Monitor workbook for Entra Agent ID

Anton Staykov — Wed, 10 Jun 2026 10:23:00 +0000

The earlier articles in this series (Part 1, Part 2, and Part 3) built the case from first principles: dynamic consent lets an agent earn its access in context, that accumulation quietly turns the agent into a high-value target, and the raw queries to discover what agents have been granted and what they actually exercise already exist in Microsoft Graph and Log Analytics. All of that is useful. None of it is visible unless someone remembers to run the query.

A KQL query in a Log Analytics window is something you execute when you already suspect a problem. An Azure Monitor workbook is a parameterized view you open (or pin to a shared dashboard) to see the shape of agent traffic before suspicion sets in. That is a different posture entirely, and it is the difference between investigation and awareness.

This article walks through an open-source workbook that provides that awareness for every agent identity in the tenant, grouped by the construct that matters most for governance: the Agent Identity Blueprint.

What the workbook shows

The workbook, available on GitHub, queries two log tables from Microsoft Entra:

AADNonInteractiveUserSignInLogs for delegated agent sign-ins, where an agent identity acts on behalf of a human user (or on behalf of another agent user).
AADServicePrincipalSignInLogs for autonomous agent sign-ins, where the agent identity authenticates with its own application-level credentials.

Both views are grouped by Agent Identity Blueprint, which is the parent construct that defines the agent's trust boundary. This is deliberate. Part 2 argued that the blueprint is the right choke point for Conditional Access and governance policy, because a policy applied to a blueprint propagates to every agent identity created from it. The workbook follows the same principle: start at the blueprint, drill into the agents underneath, then into the individual sign-in events.

The top-level summary tiles show total sign-in counts, unique agent identities, successes, failures, and interrupts (pending user action), each with a sparkline trend. Clicking a tile filters the rest of the workbook to that status category.

Prerequisites and deployment

The workbook requires a Log Analytics workspace with Microsoft Entra sign-in logs flowing into it. Specifically, the non-interactive user sign-in logs and service principal sign-in logs diagnostic categories must be enabled in the Entra diagnostic settings. If you already have Entra sign-in logs routed to Log Analytics (most organizations with any monitoring posture do), you are ready.

To deploy:

Download agent-id-sign-ins.json from the GitHub repo.
In the Azure portal, navigate to Azure Monitor > Workbooks > New.
Open the Advanced Editor (the </> icon in the toolbar).
Paste the JSON content and click Apply.
Select your Log Analytics workspace and save.

That is it. The parameters at the top of the workbook (time range, agent identity filter, user filter) populate automatically from the data in your workspace.

Delegated agent sign-ins

The upper section of the workbook covers sign-ins where an agent identity acts in a delegated context, on behalf of a user. This is the pattern that Part 1 described: the agent acquires tokens with the user's consent, and each sign-in event is recorded in AADNonInteractiveUserSignInLogs with the Agent property that identifies the agent type and its parent blueprint.

The hierarchy works like this: blueprints sit at the top level, each showing total sign-in count, a trend sparkline, failure count, and interrupt count. Expanding a blueprint reveals the agent identities created from it. Selecting a row on the left populates the detail grid on the right.

The detail grid is where the operational value lives. Each sign-in event shows:

A type indicator: 🙋 for a human user or 🤖 for an agent user (identified by agentSubjectType == 'agentIDuser' in the sign-in log).
The display name of the user or agent user who was the subject of the sign-in.
The resource that was accessed (Microsoft Graph, Azure DevOps, a custom API).
The OAuth scopes that were included in the token, extracted from the AuthenticationProcessingDetails field of the sign-in event.
Sign-in status, Conditional Access status, and error details when something went wrong.

The agent identity names in the left panel are clickable links that open the Agent Identity blade directly in the Microsoft Entra admin center. No copying of object IDs, no navigating through menus.

Notice what this view makes immediately obvious. In the screenshot above, the "Az DevOops Blueprint" has agent identities signing into Azure DevOps with user_impersonation scope. That is the exact scenario from the Azure DevOps article: an agent identity replacing a PAT with proper delegated access. The workbook shows it happening in production, with the user on whose behalf the agent acted, the resource it touched, and the scopes it used. If an unexpected resource or scope appears in that list, it is visible here without running a query.

Autonomous agent sign-ins

The lower section covers the other half: agents authenticating with application-level credentials, without a user context. These are the autonomous agents, the ones that run scheduled jobs, background processing, or act as service accounts with appRoleAssignments rather than delegated consent.

This section queries AADServicePrincipalSignInLogs filtered to agentType == 'agenticAppInstance', and uses the same blueprint-first hierarchy. Expanding a blueprint shows each agent identity, and now each agent identity row also shows the Resources column: a comma-separated list of every resource that agent has signed into during the selected time range. That is the agent's behavioral surface area in one cell.

The screenshot tells a real story. The Anthropic agent identity, created from its blueprint, has signed into Claude Service Account, Anthropic WIF Trust, Anthropic APIs, and Microsoft Graph. That is the secretless authentication pattern in action: the agent uses Workload Identity Federation to authenticate to Anthropic's APIs without an API key, and the sign-in logs capture every hop. The four failures against "Unknown Resource" are worth investigating (resource identity not resolved at sign-in time, typically a transient issue or a misconfigured resource), and they are visible here instead of hiding in a raw log table.

What the workbook does not show

This workbook covers the behavioral side of agent visibility: who signed in, to what resource, with which scopes, and whether it worked. It does not show what was granted via oauth2PermissionGrants or appRoleAssignments. That is the entitlement side, and it lives in the Microsoft Graph queries covered in Part 3.

The two are complementary. The workbook answers "what are agents doing?" The Graph queries answer "what could agents do?" The gap between the two, the granted-but-never-exercised permissions, is what Part 2 called the access-review backlog.

Getting started

The workbook is open source and available at github.com/Dayzure/entra-agent-id-workbooks. Import it, point it at your Log Analytics workspace, and see what your agents have been doing. If the answer surprises you, the earlier articles in this series explain what to do about it.

References

Your AI agent doesn't need a PAT to work in Azure DevOps

Anton Staykov — Thu, 04 Jun 2026 09:17:00 +0000

At Collab Summit 2026 in the beginning of May, a fellow I had not seen in years caught me between sessions. We did the usual catching up, and then he got to the real question: "We're building an AI agent that works inside Azure DevOps. It creates work items, pushes code to branches, opens pull requests. Right now it authenticates with a PAT. How do we do this properly?"

The room around us was full of people building similar things. AI agents that are not chatbots answering questions, but digital co-workers: autonomous participants on a development team, shipping code, triaging issues, responding to reviewer feedback. The pattern is already in production across more organizations than most conference talks acknowledge.

His question deserved a better answer than "use a service principal." So I went home and built one.

The identity primitives that were never designed for this

When a non-human caller needs to authenticate to Azure DevOps, two standard options exist today. Neither was designed for an autonomous AI agent acting as a member of a development team.

Personal Access Tokens (PATs). A PAT is a static bearer credential tied to a human user. It carries that user's identity and permissions, which means the agent's actions appear in audit logs as if the human performed them. There is no way to distinguish "the developer pushed a commit" from "the developer's agent pushed a commit." The token does not expire unless someone sets a date and remembers it. It cannot be scoped to a governed agent identity. It is a secret that sits in an environment variable and waits to be leaked.

Entra workload identities (service principals and managed identities). Azure DevOps now supports Entra workload identity authentication for pipelines, which is a genuine improvement: service principals and managed identities can be added as users to an Azure DevOps organization, and pipelines authenticate to Azure DevOps resources through Workload Identity Federation with zero stored secrets. The credentials problem is solved. But the identity model is still the pipeline model. A service principal added to an ADO organization has no concept of owner, sponsor, or blueprint. It has no delegated user pattern. Your SOC cannot filter its sign-in events as agentic activity. It is infrastructure plumbing designed for CI/CD jobs accessing repos and artifact feeds, not for a digital co-worker whose commits, work items, and PR comments should carry a traceable, governed agent identity with lifecycle metadata.

Both options were designed for a world where non-human callers were pipelines, scheduled jobs, or integration hooks. That world is not the one we are building in anymore.

What an AI agent actually needs

An AI agent that operates as a digital co-worker on a development team needs something fundamentally different from a pipeline credential. It needs an identity.

Not a token. Not a secret. An identity with the same governance surface that a human team member carries:

An owner who is accountable for what the agent does.
A sponsor with business context for why the agent exists.
Auditable sign-in events that your SOC can filter, correlate, and alert on, tagged explicitly as agentic activity.
A credential model where the agent's runtime code never touches secrets (because secrets in agent memory are an attack surface, not a convenience).
A lifecycle that ties the identity to the agent's existence, so decommissioning the agent means decommissioning its access.

This is not a wishlist for a future platform. This is what Microsoft Entra Agent ID provides today.

Entra Agent ID: the IAM shift

If you have followed this series, you have seen Entra Agent ID applied to calling third-party model APIs without API keys and to building secret-less agentic platforms with managed identities and Workload Identity Federation. The pattern is consistent, but it is worth stating the fundamental shift plainly, because it changes how we think about IAM for AI agents.

Traditional IAM for non-human workloads treats the workload as infrastructure. You create a service principal, hand it credentials, scope its permissions, and monitor it (if you remember) through workload identity logs that most SOC teams never look at. The workload has no owner in the governance sense. It has no sponsor. It has no blueprint that propagates policy to every instance. It is a row in an app registration table that someone created two years ago and nobody is sure whether it is still in use.

Microsoft Entra Agent ID treats the AI agent as a participant. The identity constructs are purpose-built:

Agent Identity Blueprints are the authentication foundation and the policy anchor. A blueprint holds (or federates) the credentials and parents one or more agent identities. Conditional Access policies applied to a blueprint propagate to every agent identity it creates. One policy decision, enforced across an entire family of agents.
Agent Identities are the runtime identity of a specific agent. No credentials of their own. They authenticate through their blueprint. They carry owner and sponsor metadata. They produce sign-in events tagged as agentic, visible in the same logs your SOC already monitors.
The Entra SDK Auth Sidecar handles all credential work in a separate container. The agent code never sees a secret, never handles token acquisition, never stores credentials in memory. The sidecar is not exposed to the host network, so the token acquisition surface is isolated from the agent's own attack surface.

This is not a better way to do service principals. It is a different category.

The delegated user pattern and Azure DevOps

For an AI agent that acts as a digital co-worker on a development team, the Agent ID User (delegated) pattern is the right fit. The agent acts on behalf of a specific user (its own agent user account in Entra), and every action it takes in Azure DevOps carries that user's identity.

The identity flow:

The sidecar authenticates to Entra ID using the blueprint's credentials.
The agent requests a token from the sidecar for Azure DevOps, specifying its Agent Identity and its Agent Username.
The sidecar performs the Federated Identity Credential (FIC) token exchange with Entra ID.
Entra issues a Bearer token scoped to the Azure DevOps resource (499b84ac-1321-427f-aa17-267ca6975798).
The agent calls the Azure DevOps REST API with that token.

The agent user is a real member of the Azure DevOps organization, with its own access level, project permissions, and repository access. When the agent creates a work item, it appears as created by the agent user. When it pushes a commit, the commit author is the agent user. When it opens a pull request, the PR creator is the agent user. The audit trail is clean, attributable, and governed.

No PAT. No service connection. No secret stored in agent code. The only credential in the system is the blueprint's, managed by the sidecar in an isolated container.

The proof of concept

I built a proof of concept that demonstrates the full pattern. The agent is powered by Azure OpenAI with function calling and can create work items, push file changes to new branches, open pull requests with reviewer assignments, read PR comment threads, and reply to reviewer feedback.

The architecture is deliberately simple: two containers on a Docker bridge network. The Entra SDK auth sidecar handles token acquisition; the agent handles DevOps operations. The sidecar has no host port exposure (per Microsoft's security guidance); the agent exposes a chat interface on port 4192 for demonstration purposes only.

The chat interface is there because it makes it easy to observe what the agent is doing during a demo. In a production deployment, the agent would be fully autonomous: triggered by events (a new issue, a failing build, a PR review request), executing its DevOps workflow, and reporting results through whatever channel the team uses. The identity model is identical either way.

The PoC includes a chat UI where you can give the agent instructions like "Create an issue titled 'Fix login timeout', push a fix to a new branch, and open a PR for it." The agent orchestrates the entire flow, calling Azure DevOps REST APIs through the sidecar-acquired tokens. The repository README covers the prerequisites, the Entra configuration (including the delegated permission grants that are easy to miss), and the Docker Compose setup.

What the Entra side requires

The Entra configuration involves four objects, and the relationship between them is worth understanding even if the README walks you through it:

A Blueprint app registration that holds the credentials (client secret for local development; managed identity as a federated credential for production, as covered in a previous article in this series).
An Agent Identity (service principal) created from the blueprint. This is the agent's runtime identity.
An Agent User in your Entra tenant. This is the user account the agent acts on behalf of.
Delegated permission grants created via Microsoft Graph's oauth2PermissionGrant endpoint. The Agent Identity needs user_impersonation on the Azure DevOps resource and the standard OpenID Connect scopes on Microsoft Graph. These grants must be scoped to the Agent User (consent type Principal, not AllPrincipals). This is the step most people miss on their first attempt.

What the Azure DevOps side requires

The Azure DevOps side is surprisingly straightforward:

The organization must be backed by the same Entra tenant.
The Agent User must be a member of the organization with Basic access level (Stakeholders cannot access Code/Repos).
The Agent User needs project-level permissions: Work Items (Read/Write), Code (Contribute), and Pull Requests (Create) on the target project and repository.

That is it. No service connection to configure. No PAT to mint and rotate. The agent authenticates through Entra, and Azure DevOps sees a regular user with scoped permissions.

From demo to production

The PoC runs on Docker Compose with a client secret for the blueprint. A production deployment changes three things:

Replace the client secret with a managed identity federated credential or a Workload Identity Federation credential from your compute platform (AKS, Container Apps, etc.). The sidecar supports both through its credential source configuration.
Use the sidecar for Azure OpenAI authentication too. The PoC uses an API key for Azure OpenAI because the focus is on the Azure DevOps identity pattern, but in production, the sidecar should acquire tokens for the Cognitive Services resource as well. No reason to have any static secret in the system.
Add the governance layer. Wire the agent's sign-in events into your SOC monitoring. Set up access reviews keyed to actual API usage, not calendar recertification. Apply Conditional Access policies to the blueprint. Earlier articles in this series (governance and discovering consents) cover the governance model in detail.

The answer to the question

The fellow at Collab Summit asked how to connect an AI agent to Azure DevOps properly. The answer is not a better secret. It is a better identity.

Microsoft Entra Agent ID gives the agent a governed, auditable, purpose-built identity. The Entra SDK auth sidecar keeps credentials out of agent code. The delegated user pattern makes the agent a traceable participant in Azure DevOps, not an anonymous caller hiding behind a PAT.

The proof of concept is on GitHub. Clone it, configure the Entra objects, run docker compose up, and watch an AI agent create issues, push code, and open pull requests, all authenticated through its own agent identity.

If your AI agents are still running on PATs, the question from Collab Summit applies to you too. And the answer is the same: stop managing secrets. Start managing identities.

References

Your agentic platform doesn't need a single secret: Managed Identities, Workload Identity Federation and Agent Identity Blueprints

Anton Staykov — Thu, 28 May 2026 10:17:00 +0000

Every enterprise has a drawer full of static API keys it pretends are under control. They are not.

A static API key is a bearer credential in the purest sense: it does not know who is using it, does not bind to a caller or a session, and does not expire unless someone remembers to set a date. It grants access to anyone who holds it, full stop.

And keys never stay where they are supposed to. They travel in plaintext emails, get committed to source control in .env files that .gitignore was supposed to catch, get pasted into wiki pages and Slack messages during incident response, and settle into CI/CD pipeline definitions that predate the team's current secrets-management policy. None of this is negligence. It is structural: the tooling makes keys trivially easy to mint and almost impossible to track once they leave the admin console. The result is technical security debt that compounds silently. Keys issued for a proof of concept three years ago are still valid, still embedded in a pipeline nobody touches, still granting day-one access. Revoking them is a game of "what breaks?" that nobody volunteers to play.

This is the foundation too many organizations are building their agentic platforms on. A foundation made of sand.

Managed Identities for Azure resources: the first answer

If your workload runs on Azure, the answer has existed for years: Managed Identities for Azure resources.

A managed identity is a service principal in Microsoft Entra ID whose credentials are entirely platform-managed. Your code never sees a secret, never stores a certificate, never rotates anything. The compute resource requests a token from the local metadata endpoint; Entra issues one. The credential that backs it is inaccessible to anyone, including the team that deployed the workload.

Three properties make this the default choice:

Complete elimination of static credentials. No API key to leak, no connection string to embed, no vault entry to maintain. The identity is the credential. This is not "better secrets management." It is the absence of secrets.
Automatic credential lifecycle. Rotation, renewal, and revocation happen without human intervention. No calendar reminders, no runbooks, no incidents when someone forgets.
Lifecycle binding (system-assigned). When the Azure resource is deleted, the identity is deleted with it. No orphaned service principals, no zombie credentials. User-assigned managed identities offer an independent lifecycle model for workloads that span multiple resources.

The conclusion is not nuanced: if your workload runs on Azure, you should be using a managed identity. Every client secret stored in Key Vault "for safety," every certificate rotated on a quarterly schedule, is a choice to do things the hard way when a safer path is right there. Managed identities are not a best practice. They are the baseline.

Workload Identity Federation: the cross-cloud, cross-provider standard

Managed identities solve the problem when your workload runs on Azure. But workloads do not stay neatly inside one cloud. A GitHub Actions pipeline needs to deploy to Azure. A service on AWS needs to call Microsoft Graph. A Kubernetes cluster on GKE needs to reach an Azure Storage account.

This is where Workload Identity Federation (WIF) enters the picture. WIF is not a Microsoft product. It is a pattern built on open standards: OpenID Connect for identity assertions and RFC 7523 for the JWT bearer token exchange. Instead of handing a workload a long-lived secret, you let it prove who it is using a signed JWT from an identity provider the receiving system already trusts. GitHub, Google Cloud, AWS, Kubernetes, and SPIFFE/SPIRE all issue OIDC-compliant tokens that participate in WIF flows today.

Microsoft Entra supports WIF in both directions, and this bidirectional capability is what makes the rest of this story possible:

Outbound (Entra as issuer). Your tenant issues JWTs that external systems can validate and trust, enabling Entra-authenticated workloads to call services outside the Microsoft ecosystem without static credentials. The earlier article in this series explored exactly this: an AI agent using its Entra-issued JWT to authenticate to Anthropic's Claude API through WIF, with no API key involved.

Inbound (Entra as relying party). Your tenant trusts JWTs from external identity providers and exchanges them for Entra-issued access tokens. This is what lets a GitHub Actions workflow or an AWS Lambda function access Entra-protected resources without a stored secret. The supported scenarios span AKS, EKS, GKE, GitHub Actions, Azure DevOps, SPIFFE/SPIRE, and any platform with an OIDC-compliant identity provider.

Federated Identity Credentials: the inbound trust mechanism

The inbound direction of WIF in Microsoft Entra is implemented through Federated Identity Credentials (FICs). A FIC is a configuration object attached to an app registration or a user-assigned managed identity that tells Entra: "when a JWT arrives from this issuer, with this subject, for this audience, treat it as a valid credential and issue an access token."

Three properties define the trust: issuer (the external IdP's URL, matched against iss), subject (the external workload's identifier, matched against sub), and audiences (typically api://AzureADTokenExchange). All matching is case-sensitive. When an external workload presents a JWT, Entra validates the signature against the issuer's published OIDC keys, checks the claims, and issues an Entra access token. No secret involved. No certificate involved. The trust is cryptographic and scoped to exactly one external workload.

The mental model: there must be a workload identity in Entra (app registration or managed identity) that trusts the external token and represents that workload within the Entra ecosystem. The external workload never gets a secret; it gets a trust relationship. (Design note: a maximum of 20 FICs can be configured per app registration or managed identity.)

Managed identity as a federated credential: the elegant twist

Managed identities eliminate secrets on Azure. FICs eliminate secrets for external workloads. But what about scenarios where you need an app registration (because the downstream API requires it, because your token needs specific optional claims) and yet you still want zero secrets?

The answer: configure the app registration to trust a managed identity as its federated credential. The workload acquires a managed identity token from the local metadata endpoint, presents it to Entra as a FIC on the app registration, and receives an access token scoped to the app. No client secret. No certificate. The managed identity is the credential. The managed identity handles the credential lifecycle; the app registration handles token shape, optional claims, and API permissions. Each does what it is good at, and no secret sits between them.

The convergence: Agent Identity Blueprints without secrets

Now bring in Microsoft Entra Agent ID.

An Agent Identity Blueprint is the authentication foundation for one or more agent identities. The blueprint holds the credentials and acquires tokens on behalf of all agent identities created from it. Conditional Access policies applied to the blueprint propagate to every agent identity it parents. It is, by design, the central point where credential management happens for an entire family of AI agents.

In the simplest deployment model, a blueprint holds a client secret. For production, teams typically upgrade to a certificate. Both are secrets that must be stored, rotated, and protected. Both are liabilities.

But a blueprint is, at its core, backed by an app registration in Microsoft Entra. And we just established that an app registration can trust a managed identity as its federated credential.

The implication is direct: configure a managed identity as the federated identity credential on the blueprint's underlying app registration, deploy the agent runtime on Azure compute with that managed identity assigned, and the blueprint acquires tokens using the managed identity token exchange. No client secret. No certificate. No vault. The managed identity, lifecycle-bound to the Azure compute resource, is the only credential in the system.

Three concepts, designed independently for different purposes, converge into a single architecture: Managed Identities provide the credential-free primitive for Azure compute. Workload Identity Federation extends it across trust boundaries via OIDC and RFC 7523. Federated Identity Credentials bind an external identity (including a managed identity) to an Entra workload identity, replacing secrets with cryptographic trust.

Applied to an Agent Identity Blueprint, these three deliver a secret-less agentic platform. Not a roadmap item. Not a preview. A production-ready architecture available today, using generally available constructs in Microsoft Entra ID.

If you are building an agentic platform in 2026 and your agents still hold secrets, the question is no longer "should we fix this?" The question is "why haven't we?"

References

Finding Out What Your AI Agents Actually Got: Discovering Consents and Active Agents in Microsoft Entra

Anton Staykov — Mon, 25 May 2026 12:36:00 +0000

The first two articles in this series argued that incremental and dynamic consent, paired with Microsoft Entra Agent ID, lets an interactive AI agent earn its access in the wild — and that the resulting accumulation quietly turns the agent into the highest-value target in your environment.

That argument is only useful if the accumulation is visible. This article is about that visibility. Specifically, two questions every identity and security architect should be able to answer on demand for any agent in the tenant:

What has this agent been granted?
What is this agent actually doing with what it was granted?

Neither answer requires a new product. Both live in surfaces that already exist in Microsoft Entra and Microsoft Graph — they just have not been wired into most operating models yet.

The two halves of the picture

Granted permissions and exercised permissions are different things, and they live in different places.

Granted delegated permissions — the consents Aria collects every time a user approves a new scope — are stored as oauth2PermissionGrants in Microsoft Entra and exposed through Microsoft Graph. Each grant is a tuple of (client service principal, resource service principal, principal the consent was granted on behalf of, scope string). For an interactive agent, the client is the agent's identity and the principal is the human who consented.

Granted application permissions — used mostly by autonomous agents — are stored as appRoleAssignments against the agent's identiy. They require admin consent, so they should be a smaller and more deliberate list.

Exercised permissions — what the agent actually used a token against — show up first in Microsoft Entra sign-in logs, specifically the non-interactive stream. Every time an agent requests a token for a resource (Microsoft Graph, SharePoint, a custom API), Entra records a non-interactive sign-in tagged with the agent identity, the appId, and the resourceId / resourceDisplayName of what was accessed. For agent identities provisioned through Microsoft Entra Agent ID, those events also carry an agent property describing the agentType and agentSubjectType — which is what lets you separate agent traffic from the rest of the workload identity noise without guessing.

For endpoint-level detail — the exact RequestUri, method, and response code per Microsoft Graph call — Microsoft Graph activity logs are the deeper layer, available once the diagnostic setting that streams them into a Log Analytics workspace is turned on. Sign-in logs answer which resources; Graph activity logs answer which endpoints on Microsoft Graph.

Holding the granted and exercised sides side by side is the entire game.

Discovering what Aria was granted

For a single agent like Aria, a Microsoft Graph call is enough.

GET https://graph.microsoft.com/v1.0/oauth2PermissionGrants?$filter=clientId eq '{aria-service-principal-id}'

The response is every delegated consent in force for Aria — the consenting user (principalId), the resource being accessed (resourceId, e.g. Microsoft Graph, SharePoint, the Finance API), and the space-separated scope string. Joining resourceId against /servicePrincipals resolves the resource to a name; joining principalId against /users resolves the consenter.

For a tenant-wide view — every agent identity, every grant — drop the filter and group by clientId. The shape is usually surprising the first time anyone runs it: a long tail of agents with two or three scopes, a smaller set with a dozen, and one or two outliers worth an immediate conversation with their owner.

Application permissions warrant a parallel sweep:

GET https://graph.microsoft.com/v1.0/servicePrincipals/{id}/appRoleAssignments

If an agent identity is meant to be interactive and you find non-trivial app role assignments here, that is a finding by itself.

Note: Microsoft Entra defines an Agent Identity as a speciliazed subtype of the service principal type. That's why the above query works directly on the /servicePrincipals collection. Of course you also use the specialized collection endpoint /servicePrincipals/microosft.graph.agentIdentity/{id}/appRoleAssignments. With respect to the information we are looking for - the result will be the same.

Identifying the most active agents

Granted scopes describe potential. Sign-in logs describe behavior, and behavior is what matters for triage.

The single most useful call for tenant-wide agent visibility is a filtered read of the non-interactive sign-in stream:

GET https://graph.microsoft.com/beta/auditLogs/signIns
    ?$filter=signInEventTypes/any(t:t eq 'nonInteractiveUser') 
        and agent/agentType eq 'agenticAppInstance' 
        and agent/agentSubjectType ne 'agentIDuser'
    &$select=id,createdDateTime,userPrincipalName,appId,appDisplayName,
        resourceId,resourceDisplayName,signInEventTypes,agent

That one query already returns the resources every agent identity in the tenant has touched in the last 24 hours (default), who the agent acted on behalf of, and how often. No diagnostic setting, no Log Analytics workspace, no extra licensing — just Microsoft Graph and the sign-in logs that Entra is already collecting.

Once those events are routed into Log Analytics (via the Entra diagnostic setting for SignInLogs / NonInteractiveUserSignInLogs), ranking the most active agents in the tenant becomes a one-liner:

AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| where tostring(parse_json(Agent).agentType) == 'agenticAppInstance'
| summarize Calls = count(),
            DistinctResources = dcount(ResourceDisplayName),
            LastSeen = max(TimeGenerated)
            by AppId, UserPrincipalName
| sort by Calls desc
| take 25

This single result set answers more operational questions than most identity dashboards: which agents are loud, what resource surface area they cover, and on whose behalf. The AppId ties each row back to the agent's service principal and its oauth2PermissionGrants.

A second query reveals which resources Aria is touching:

AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where AppId == '{aria-app-id}'
| summarize Calls = count(),
            LastCall = max(TimeGenerated)
            by ResourceDisplayName, ResourceIdentity, ConditionalAccessStatus
| sort by Calls desc

The output is Aria's behavioral fingerprint at the resource level: Microsoft Graph, SharePoint, the Finance API, with cadence and conditional-access outcome. Sudden new entries are leading indicators that the next consent prompt is about to fire — or that something has already gone sideways.

For teams that need endpoint-level detail on Microsoft Graph specifically — exact paths, methods, response codes — MicrosoftGraphActivityLogs is the natural follow-on, joined back on ServicePrincipalId. It is a deeper layer, not the entry point.

The query that should be on every architect's wall

The most useful query joins the two halves — granted scopes against resources actually touched:

let granted = externaldata(AppId: string, ResourceIdentity: string, Scope: string)
    [/* loaded from your oauth2PermissionGrants snapshot,
         joined to servicePrincipals to resolve resourceId */];
let used = AADNonInteractiveUserSignInLogs
    | where TimeGenerated > ago(30d)
    | where tostring(parse_json(Agent).agentType) == 'agenticAppInstance'
    | distinct AppId, ResourceIdentity;
granted
| join kind=leftouter used on AppId, ResourceIdentity
| where isnull(used_AppId)
| project AppId, GrantedButUnusedResource = ResourceIdentity, Scope

That is the grant-versus-use gap introduced in the previous article, made operational at the resource level. Every row is a resource an agent has consent for but has not touched in 30 days — a candidate for automated revocation, or at minimum a row in next quarter's access review, keyed to actual behavior rather than the calendar. Teams that have Microsoft Graph activity logs flowing can refine the same join down to the individual scope by replacing the used block with a MicrosoftGraphActivityLogs projection over Scopes.

Building this into an operating rhythm

Three lightweight habits convert these queries from one-off discoveries into a control:

A weekly snapshot of oauth2PermissionGrants per agent identity, written to a Log Analytics custom table or a storage account. This produces a time series of consent accumulation — the basis for velocity-based detections.
A scheduled top-callers query over AADNonInteractiveUserSignInLogs filtered to agentType == 'agenticAppInstance', run daily, feeding a workbook tile and an alert for sudden movers.
A monthly grant-versus-use report scoped to agent identities and owned by the agent's sponsor (the business-accountable role defined in Microsoft Entra Agent ID). The sponsor either justifies the unused resources and scopes or signs off on revocation.

None of this requires custom code beyond a handful of Microsoft Graph calls and Kusto queries. All of it scales with the agent population, and the entry-point query — non-interactive sign-ins filtered to agentic app instances — works against any tenant with Microsoft Entra Agent ID and the standard sign-in log retention, no extra diagnostic plumbing required.

What's next

The queries above are the minimum viable instrumentation. They work, but they are scattered across the Microsoft Graph console, the Log Analytics blade, and whatever notebook the architect happens to keep open.

The fourth and final article in this series brings them together as a custom Azure Monitor workbook for AI agent governance — agent inventory, consent accumulation, top callers, grant-versus-use gap, sponsor sign-off — designed to drop into an existing Microsoft Entra monitoring solution.

The visibility problem is solved as soon as someone decides to look. The next article is about making it impossible not to look.

Your AI Agent Doesn't Need an API Key: Entra Agent ID and Anthropic's Workload Identity Federation

Anton Staykov — Thu, 21 May 2026 10:30:00 +0000

Every system that authenticates with a static API key is carrying a liability disguised as a convenience. The key does not expire unless someone sets a calendar reminder. It does not know who is using it. It cannot tell you whether the request that just hit the endpoint came from the production agent it was minted for or from a laptop in a coffee shop where someone pasted it into a terminal two months ago. Static keys are the skeleton key of modern distributed systems — they open the door for anyone who holds them, and they never ask why.

This is not a new problem, but it is becoming a dangerous one. As AI agents proliferate across enterprise environments — calling model APIs, orchestrating workflows, accessing downstream services — the number of static secrets embedded in configuration files, environment variables, and CI pipelines is growing faster than any rotation policy can keep up with. The question is no longer whether your organization has a leaked key somewhere. The question is how many, and which ones an attacker has already found.

The industry's answer has been converging for years, and it has a name.

Workload Identity Federation

Workload Identity Federation (WIF) is a pattern — not a product, not a proprietary protocol — built on top of OpenID Connect and the RFC 7523 JWT bearer grant. The idea is disarmingly simple: instead of minting a long-lived secret and handing it to a workload, you let the workload prove who it is using a short-lived, signed JSON Web Token issued by an identity provider (IdP) you already trust. The receiving system validates the JWT's signature against the IdP's published keys, checks the claims against rules you configured, and — if everything lines up — issues a short-lived access token in return. No secrets to store. No secrets to rotate. No secrets to leak.

The pattern has been adopted across the industry — by major cloud providers, CI/CD platforms, container orchestrators, and increasingly by model providers. Microsoft Entra, for its part, supports WIF both as an issuer (your Entra tenant issues JWTs that external systems trust) and as a relying party (your Entra tenant trusts JWTs from external identity providers to grant access to Entra-protected resources). That bidirectional capability is what makes the rest of this story possible.

Anthropic embraces the standard

Anthropic has brought native Workload Identity Federation support to the Claude API — and this deserves more attention than it has received.

With Anthropic's WIF implementation, any OIDC-capable identity provider can authenticate workloads to the Claude API without a static sk-ant-... key ever being involved. You register your IdP as a federation issuer in the Anthropic Console, define a federation rule that maps incoming JWT claims to a service account, and your workload does the rest: present the JWT, receive a short-lived Claude access token, call the API. The SDKs handle the exchange and the refresh loop. API keys can be disabled entirely on the Anthropic workspace.

Three concepts on the Anthropic side matter here:

Service accounts (svac_...) — non-human identities inside your Anthropic organization. A federated token acts as a service account. Unlike an API key, a service account has credentials minted for it on demand, and you can audit which workloads acted as which service account.
Federation issuers (fdis_...) — the registration of your OIDC identity provider with your Anthropic organization. Each issuer tells Anthropic "JWTs signed by this provider may assert workload identity for my org."
Federation rules (fdrl_...) — the bridge between an issuer and a service account: "when a JWT from issuer X has claims that look like Y, mint a token for service account Z."

The Console includes presets for common providers and a generic OIDC option that works with any standards-compliant issuer — including Microsoft Entra ID. That last bullet is the one this article cares about.

Microsoft Entra Agent ID — identity built for agents

Microsoft Entra Agent ID introduces first-class identity constructs purpose-built for AI agents. Not repurposed service principals. Not human user accounts pressed into service. Dedicated objects with a dedicated governance model.

The constructs that matter for this story:

Agent identity blueprints — the template and authentication foundation for one or more agent identities. The blueprint holds the credentials (client secret, certificate, or federated identity credential) and uses them to acquire tokens on behalf of all agent identities created from it. Conditional Access policies applied to a blueprint propagate to every agent identity it parents.
Agent identities — the runtime identity of a specific AI agent. An agent identity has no credentials of its own. It authenticates through its blueprint.
The Microsoft Entra SDK for Agent ID — a containerized sidecar that handles token acquisition, validation, and secure downstream API calls. Your agent code asks the sidecar for a token; the sidecar handles the identity plumbing.

The proof of concept

The question I wanted to answer was concrete: can an AI agent, using Microsoft Entra Agent ID as its native identity, call the Anthropic Claude API through Workload Identity Federation — with no API key, no certificate in agent memory, and no cloud LLM proxy in between?

The answer is yes. I built a proof of concept that does exactly this.

The architecture

The PoC runs as two containers on a Docker bridge network:

claude-wif-agent — a Flask application that receives user queries, asks the sidecar for an Entra JWT, exchanges that JWT for a Claude access token, and calls the Claude Messages API.
claude-wif-sidecar — the Microsoft Entra Auth SDK sidecar, which handles the client-credentials flow against Entra ID and returns a signed JWT scoped to the agent identity.

The token flow has nine steps, but the critical insight lives in three of them:

Steps 4–5: The sidecar uses the blueprint's credentials to obtain an Entra-issued JWT for the agent identity. The JWT carries the agent's appid, oid, and — crucially — the xms_par_app_azp optional claim that identifies the parent blueprint.
Step 7: The agent application exchanges that Entra JWT for a Claude access token by posting to POST https://api.anthropic.com/v1/oauth/token using the RFC 7523 jwt-bearer grant. Anthropic validates the JWT's signature, checks the claims against the federation rule, and returns a short-lived token.
Step 9: The agent calls POST https://api.anthropic.com/v1/messages with the Claude token. No API key is involved. No MSAL library is needed. No certificates sit in agent memory.

Three Entra objects — and why the third is easy to miss

The PoC requires three distinct Microsoft Entra objects. Two of them sound similar and the third is implicit in WIF mechanics — which is exactly why it trips people up.

An Agent Identity Blueprint — holds the credentials (client secret for local dev; managed identity or federated identity credential in production) and parents the agent identity.
An Agent Identity — the runtime identity of the specific AI agent. No credentials of its own — the blueprint mints tokens on its behalf.
An App Registration representing the Anthropic API — and this is the one that is easy to miss. Anthropic's WIF rule validates an Entra-issued JWT, and the only way that JWT carries the right aud (audience) claim is if Entra issues it for a registered resource application whose ID matches what you configured as the audience of the federation issuer in the Anthropic Console. This app registration uses v2.0 tokens (requestedAccessTokenVersion: 2), has acceptMappedClaims: true, and configures the xms_par_app_azp optional claim on the access token — so that a single Anthropic federation rule can match all agent identities parented by the same blueprint, rather than requiring a rule per individual agent.

The token that reaches Anthropic carries:

iss = https://login.microsoftonline.com/<tenant-id>/v2.0
aud = the Application ID of the Anthropic API app registration
appid = the Agent Identity's client ID
oid = the Agent Identity's object ID
xms_par_app_azp = the Agent Identity Blueprint's application ID

Anthropic validates all of this against the federation issuer and rule you configured. No Anthropic API key is involved at any point.

Both flows work

The PoC supports both access patterns that the agent identity platform defines:

Autonomous (app-only): The agent identity acts independently. The sidecar obtains a client-credentials token, the agent exchanges it for a Claude token, and the response comes back tagged "flow": "autonomous".
On-Behalf-Of (OBO): When a signed-in user's Entra Bearer token is available, the sidecar performs an OBO exchange and mints an agent-on-behalf-of-user token, which is then exchanged with Anthropic WIF. The response comes back tagged "flow": "obo".

Both flows use the same Anthropic WIF endpoint. The only difference is whose authority the Entra JWT represents — the agent's own, or the agent acting on behalf of a human.

From local dev to production

The PoC uses a client secret on the blueprint for local development — a pragmatic shortcut for proving the concept. Moving to production requires changing exactly two environment variables in the sidecar configuration to switch from client secret to managed identity, and adding a federated identity credential on the blueprint for the managed identity. No agent code changes. The sidecar abstracts the credential source entirely.

The credentials-free agent

This is where the threads converge. Workload Identity Federation is an industry standard. Anthropic has built native support for it into the Claude API. Microsoft Entra Agent ID provides purpose-built identity constructs for AI agents — with blueprints that centralize credential management, agent identities that carry no secrets of their own, and a sidecar SDK that abstracts the entire token lifecycle.

Put them together and you get something that would have been difficult to describe two years ago: an AI agent that authenticates to a third-party model provider using its own agentic identity, issued by the enterprise identity provider, validated through standards-based federation — with no static API key, no certificate in memory, and no cloud LLM proxy sitting in between. The agent's identity is its credential.

The proof of concept is open on GitHub: astaykov/claude-wif-agentid. It is minimal by design — a Flask app, a sidecar, a docker-compose.yml, and a .env file. The README walks through every Entra object, every Anthropic Console configuration step, and the full token flow. Fork it, break it, extend it.

The age of the static API key — for AI agents, at least — is ending. The identity infrastructure to replace it is already here.

References

Your Agent Is Becoming the Crown Jewel: SOC, Reviews, and Governance for the Dynamic-Consent Era

Anton Staykov — Mon, 18 May 2026 13:34:00 +0000

The previous article in this series argued that the combination of incremental and dynamic user consent and Microsoft Entra Agent ID gives interactive AI agents something genuinely new: the ability to earn their access in the wild, scope by scope, prompted by the humans and other agents they work alongside. Aria, the example agent, started with two delegated permissions and grew into a productive contributor across SharePoint, ServiceNow, and the Finance API in roughly a quarter — without its creators pre-declaring any of it.

That was the optimistic half. This is the other half.

By the end of that quarter, Aria is — by any reasonable measurement — the most over-privileged identity in the tenant. No one noticed, because there was nothing to notice. Every grant was legitimate, contextual, and user-approved. The risk did not arrive in a single bad decision. It arrived as a hundred reasonable yeses.

A different kind of over-permissioning

Classic over-permissioning is an event. Someone hands a service account Directory.ReadWrite.All because the deployment was due Friday, an auditor flags it months later, a ticket is opened. Slow, but the control loop exists, and it is built around discrete moments of poor judgment.

Permission accumulation through dynamic consent is structurally different. There is no single bad decision to find. The permission graph grows monotonically — one narrow, well-justified scope at a time — because the mechanism that makes the agent useful is the same mechanism that makes it dangerous. Nothing in the platform prunes that graph by default, and nothing in most organizations does either: access-review tooling was designed around human role changes, not around agents whose role is to absorb new capabilities.

Why agents become the target

A compromised agent identity is qualitatively worse than a compromised user account, and the reasons are worth stating plainly.

A user holds permissions scattered across teams, sick days, role changes, and eventual departures. Their access constantly churns, and the blast radius of any single compromise is naturally bounded by the messiness of human work.

An agent does none of that. It persists. It centralizes. Every scope a hundred different users granted to it is reachable through one set of tokens, one blueprint, one set of credentials issued by that blueprint. Add the realistic threat surface of a modern agent — token theft, blueprint compromise, prompt injection used as a lateral-movement primitive — and the picture becomes uncomfortable: the most attractive principal in the tenant is also the one whose authority grew quietly enough to escape notice.

What the SOC must change

Most security operations centers treat sign-in logs as the primary identity signal. For agents under dynamic consent, that is no longer sufficient. The consent log itself becomes a first-class detection surface.

Three signal families deserve attention:

Scope-acquisition velocity. A productive agent acquires new scopes in bursts that follow human work. An agent that suddenly requests broad scopes — especially ones approaching admin-consent thresholds — outside its normal pattern is worth waking someone up for.
Grant-versus-use gap. Scopes that were granted but are never exercised are liability at best, pre-positioned capability for an attacker at worst. Track them, and feed the gap into automated revocation.
Introduction chains. When agent A pulls agent B into a workflow and B requests new scopes as a result, that chain is part of the audit story. SOC tooling needs to render it as a graph, not as isolated events.

None of these are exotic. They are sign-in analytics one layer up the stack.

What in identity governance must change

Access reviews built for humans assume a relatively stable role. The reviewer is asked, in effect, "does this person still need what they had last quarter?" That question does not work for an agent whose entire purpose is to absorb new capabilities continuously.

Three adjustments are required.

Reviews keyed to recent use, not recent grant. The relevant question is no longer "should the agent have this scope?" but "did the agent actually exercise this scope in the last N days, and was the use consistent with the original justification?" Scopes that fail both halves of that test should expire automatically.

Owners and sponsors as the accountable humans. Microsoft Entra Agent ID separates technical owners from business sponsors precisely so that someone with operational context and someone with business context can both be on the hook. Wire those roles into the review workflow. An agent without a current sponsor should not be holding sensitive delegated permissions.

Blueprint-level Conditional Access as the choke point. Because policies applied to a blueprint propagate to every agent identity created from it, the blueprint is the right place to enforce the constraints that should never be negotiable — geographic boundaries, sensitive-resource exclusions, step-up requirements for specific scope families. Treat the blueprint the way you treat a privileged-access workstation: small, hardened, watched.

A governance posture that grows with the agent

Three principles are worth taking back to the architecture board.

Consent is telemetry. Treat every dynamic consent event as a security signal of equal weight to a sign-in. Pipe it into the same analytics and the same review workflows.

Least privilege is a verb, not a noun. A static least-privilege list cannot survive contact with an agent that earns its access. The control objective is no longer to define the minimum scope set — it is to continuously prune toward it.

Grow with the agent; do not be the hurdle. The organizations that succeed will be the ones whose governance moves at the same cadence as the agent's learning. Quarterly reviews and annual recertifications were already too slow for humans. They are unworkable for agents.

Aria is going to keep growing. So will every other interactive agent in the tenant. The question for identity and security architects is not whether to allow it — that decision has already been made by the people on the other side of the chat window. The question is whether the controls, the detections, and the operating model are ready for what dynamic consent has quietly enabled.

If they are not yet, that is the work for this year.

The Overlooked Gem in Microsoft Entra That Gives Your AI Agents Super-Powers

Anton Staykov — Sat, 09 May 2026 13:41:16 +0000

Most enterprise conversations about Microsoft Entra stop at the obvious: single sign-on, multifactor authentication, Conditional Access, a handful of well-policed app registrations. Useful, mature, well understood. And almost entirely beside the point for what is about to happen inside every large organization.

Buried in the Microsoft identity platform developer documentation sits one short section that quietly rewires what an AI agent can become inside an enterprise. It is not a new product. It does not have a launch event. It is a paragraph titled Incremental and dynamic user consent, and it is the most underrated capability in the Microsoft Entra surface area for the agentic era.

A 30-second consent primer

Microsoft Entra exposes three broad consent shapes, all covered in the same developer consent guide:

Static consent. Every permission an application could ever need is declared up front in the app registration. Tidy, predictable, and brittle — users and admins are asked to approve the entire future of the app on day one.
Admin consent. A tenant administrator approves a permission set on behalf of the whole organization. Necessary for application permissions and for sensitive delegated scopes.
Incremental and dynamic user consent. The application requests a minimal set of scopes at first and then asks for additional delegated permissions over time, exactly when a feature needs them, by including the new scopes in the scope parameter of an authorization request. The user approves in context. Crucially, this mechanism applies to delegated permissions — permissions exercised on behalf of a signed-in human.

That last constraint is normally treated as a footnote. For AI agents it is the entire story.

From applications to agents

The other piece of the puzzle is Microsoft Entra Agent ID. Microsoft Entra Agent ID introduces first-class identity constructs for AI agents — agent identities, agent identity blueprints, owners, sponsors, managers — and a purpose-built agent's user account: an optional user object paired 1:1 with an agent identity, for systems (Exchange Online mailboxes, Teams channels, and similar) that require a user principal. A deliberate construct, so agents can participate in user-shaped systems without being misrepresented as humans.

On top of that, the industry designs AI Agents with two main data access patterns:

Autonomous access act as themselves, with their own authorizations on workloads, with or without human in the loop.
Interactive access sign a user in, and act on that user's behalf through a chat-style interface, using delegated permissions.

Read those points together. Interactive agents live on delegated permissions. Dynamic consent is the only Microsoft Entra mechanism that lets delegated permissions grow organically after deployment. The two features were designed for different reasons, in different teams, at different times. They meet exactly where the modern AI agent operates.

Meet Aria

Consider Aria, an internal productivity agent built on Microsoft Entra Agent ID, deployed as an interactive agent behind a corporate chat surface. Aria's blueprint ships with the bare minimum: User.Read and offline_access. On day one, Aria literally knows nothing about the tenant's systems and can do nothing inside them.

Then work happens.

In the first week, a product manager asks Aria to summarize discussions on a SharePoint site. Aria does not have that scope. Instead of failing, the runtime issues an authorization request that includes Sites.Read.All. The user sees a contextual consent prompt, approves it in the moment, and Aria returns the summary.

In the third week, a separate workflow agent invites Aria into a ticket-triage loop and points it at a ServiceNow connector. Aria requests a narrow read scope on incidents. The on-call engineer approves.

In the sixth week, a finance analyst asks Aria to reconcile an invoice against a vendor record. Aria requests a tightly scoped read permission on the Finance API. The analyst approves.

At no point did Aria's creators have to sit down and pre-declare Aria's world. Aria grew because humans and other agents pulled it into their work, and Microsoft Entra provided the mechanism for each step of that growth to be explicit, recorded, and reversible.

The mental model shift

Static permissions are a job description written before a new hire arrives. Whoever writes the description has to imagine every meeting that hire will ever attend, every system they will ever touch, every workflow they will ever join. The description is always wrong, usually in both directions: too narrow to be useful and, in places, too broad to be safe.

Dynamic consent is a different metaphor entirely. The agent earns scope by being useful. Three discovery vectors drive the growth:

Human delegation in context. A user asks the agent to do something it cannot yet do. The consent prompt becomes part of the act of asking.
Cross-agent introduction. Other agents — orchestrators, copilots, MCP-style tool surfaces — pull the agent into flows it did not know existed and surface the resources it needs.
Self-discovery. The agent encounters a tool catalog or an API description and recognizes a capability worth requesting.

This is not exotic. It is exactly how a competent new hire becomes productive in a complex organization: they are introduced to systems, granted access on demand, and gradually accumulate the reach required to contribute. Microsoft Entra is finally letting our non-human colleagues follow the same path.

The cliffhanger

After one quarter, Aria looks very different from the agent that booted with two scopes. It holds dozens of delegated permissions across half the enterprise — every single one of them granted legitimately, in context, by a real human, against a recorded purpose.

That is the fascinating half. The other half is that Aria is now, by any reasonable measure, the most over-privileged identity in the tenant — and nobody noticed, because there was no single moment of bad judgment to notice. Just a hundred reasonable yeses.

That accumulation is the crown jewel an adversary will eventually come looking for. It is also the thing your access reviews, your SOC playbooks, and your governance model were not designed to see.

That is the subject of the next article in this series: what changes in detection, in identity governance, and in the operating model of the security organization once dynamic consent meets agent identity at scale.

The gem is real. So is the bill that comes with it.