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

#entra #entraagentid #aiagents #azuremonitor

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.