This is not an official U.S. federal government website. The Federal Modernization Workbook is independent technical analysis. It does not represent the position of, and has not been reviewed or endorsed by, any federal agency.

Federal Modernization Workbook · Book 17 · What

Chapter 07 — Monitoring, Drift and Shadow AI

How the program watches AI identities once they exist: the sign-in, audit and risk signals for workload and agent identities, how to find AI systems nobody declared, the drift findings that compare the declared record with what is observed, and how each finding becomes evidence under the Book 12 contract and the Book 13 drift model.

An AI identity that nobody watches drifts the day after it is issued, and an AI system nobody declared is drift from the start.

NoteIn this chapter

What federal policy asks monitoring to do for AI, and what it doesn’t. Where workload and agent identities show up in Microsoft Entra sign-in and audit logs, and what ID Protection detects for them. Four places shadow AI hides and the tools that see each one, with their release stage and government-cloud availability. The program’s AI drift findings, among them a high-priority finding for an agentic AI system with no governed identity and one for a deployed system with no recorded authorization, and how each finding becomes a record in the evidence contract of Book 12 and the drift model of Book 13.

The earlier chapters of this book give every AI system an identity record, an accountable owner, a lifecycle and credentials scoped to the work (Chapter 05, Chapter 06). None of that stays true by itself. A sponsor changes jobs. A developer adds a client secret to unblock a test and never removes it. A team connects a new tool to an agent and the agent’s permissions grow to match. A program office signs up for a generative AI service with a purchase card. The identity record says one thing and the estate says another, and the gap widens quietly.

Monitoring AI identities is therefore the same job Book 13 describes for every other governed object: compare what was declared with what is observed, classify the difference, and send it to someone who can act. What is different about AI is the third input. For users and servers, discovery mostly confirms what the inventory already lists. For AI, a large share of what matters was never declared at all, because it was adopted outside the identity program. The chapter therefore treats discovery as a standing input, not a one-time cleanup.

Figure 1: Monitoring AI identities joins three inputs: what was declared, what the known identities are observed doing, and what discovery finds that nobody declared.

What policy asks monitoring to do

OMB M-25-21 makes ongoing monitoring one of the minimum risk management practices for high-impact AI. Agencies must test and periodically review high-impact use cases to identify adverse impacts to “the performance and security of AI functionality,” and the monitoring “must be designed to detect unforeseen circumstances, changes to an AI system after deployment, or changes to the context of use or associated data.”¹ NIST’s AI Risk Management Framework says the same in its own terms: mechanisms to inventory AI systems (GOVERN 1.6), monitoring of the system’s functionality and behavior in production (MEASURE 2.4), and post-deployment monitoring plans that cover incident response, recovery and change management (MANAGE 4.1).²

Two limits matter. First, M-25-21’s monitoring practice binds high-impact use cases, and it is about the AI’s performance and its effects on people as much as its security. Identity monitoring is one input to that practice, not the whole of it. Second, neither document says how to monitor an AI system’s identity. That is where the program’s design comes in, and where this chapter leans on the identity telemetry Book 12 already collects. A change to an AI system’s credentials, permissions, tools or owner is exactly the kind of “change to an AI system after deployment” the memo asks agencies to detect, and the identity logs are where those changes are recorded first.

Watching the identities you know

Where AI sign-ins land

Microsoft Entra ID has four sign-in log types: interactive user sign-ins, non-interactive user sign-ins, service principal sign-ins and managed identity sign-ins.³ Workload identities appear in the last two. An application or service principal authenticating with a certificate, a secret or a federated credential lands in the service principal sign-in log; a managed identity lands in its own log, where Azure manages the secret. Book 12, Chapter 03 lists the diagnostic categories and the Log Analytics tables each one fills, and the program routes all four to the agency’s workspace.

Agents are less tidy. Microsoft Entra Agent ID adds an agentSignIn resource type to the sign-in logs, and because an agent can sign in with delegated or app-only permissions, “their sign-ins might appear across each of the four sign-in log types.” The admin center filters sign-ins by Agent type (agent ID user, agent identity, agent identity blueprint, or not agentic) and by Is Agent; Microsoft Graph exposes the same data on the beta endpoint.⁴ The Agent ID platform became generally available in April 2026.⁵ Microsoft Entra Health monitoring, in preview, adds two agent scenarios that alert on a large increase in sign-in failures: Agent ID autonomous sign-ins, investigated from the service principal sign-in log, and Agent ID interactive sign-ins, for sign-ins in a user-delegated context where an agent’s user account is the token subject, investigated from the non-interactive user sign-in log.⁶⁷ An alert there is a reason to look, not a finding: Microsoft notes that failure volume alone doesn’t establish an outage or an attack.⁸

Principal	Where its sign-ins land	How the audit log records changes to it	How to tell it is AI
App registration or service principal used by an AI system	Service principal sign-ins	Application and service principal events	Only from the identity record; the directory has no AI marker
Managed identity used by an AI workload	Managed identity sign-ins	Service principal events	Only from the identity record
Agent identity blueprint	Service principal sign-ins	Application events, agentType = agenticApp	agentType on the event; Agent type filter
Agent identity	Service principal sign-ins (app-only), or a user log when acting for a user	Service principal events, agentType = agenticAppInstance	agentType; Agent type filter
Agent’s user account	User sign-in logs	User events, agentType = agentIDuser	agentType; Agent type filter
Agent acting for a signed-in user (on-behalf-of)	The user’s sign-in logs	—	The token represents the user and also identifies the calling agent9

The first two rows are why the identity record matters. An AI system built on an ordinary app registration or a managed identity, which is most AI built before Agent ID existed and much built since, looks in the logs exactly like any other workload. Nothing in the sign-in tells the analyst it is an AI system, who sponsors it or which inventory entry it belongs to. The program’s join key, described below, is what supplies that.

What the audit log shows, and what it hides

The audit log records agent activity “under the base identity type from where the activity originates”: creating a blueprint appears as Add application, creating an agent identity as Add service principal, and creating an agent’s user account as Add user. The agentType property on the initiator, performer and target tells the event apart, with values for a blueprint (agenticApp), an agent identity (agenticAppInstance), a blueprint principal and an agent’s user account.¹⁰ Two Microsoft cautions shape the program’s queries. Audit logs “don’t distinguish agent identities from other Microsoft Entra identity types by default,” and Microsoft Graph activity logs “don’t currently separate agent identities from other identity types”: requests from an agent identity are logged as an application and requests from an agent’s user account as a user, so the analyst joins with the sign-in logs to find the entity type.¹¹ Detection rules that filter on “is this an agent” therefore belong on the sign-in and audit tables, not on the Graph activity table alone.

Retention is the other constraint. Entra keeps audit and sign-in logs for 30 days with P1 or P2 (seven with Free), and Microsoft Graph activity logs aren’t retained at all unless they are sent to storage or an analytics workspace.¹² The program’s rule, from Book 12, is that every category it relies on for evidence is exported on the day the tenant is built. An AI identity created before export was turned on has no recoverable history.

WarningIllustrative, not tested against a production tenant

The request below is the one Microsoft documents for retrieving agent identity sign-ins. It uses the Microsoft Graph beta endpoint, which can change without notice; review it before building anything on it, and prefer the exported log tables for evidence.

GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=signInEventTypes/any(t: t eq 'servicePrincipal') and agent/agentType eq 'AgentIdentity'

In a GCC High or DoD tenant the Graph host is different (graph.microsoft.us or dod-graph.microsoft.us),¹³ and the Agent ID features themselves need to be confirmed for that cloud first, as the release table later in this chapter explains.

What to alert on

Microsoft’s own guidance for Agent ID lists the signals worth an alert: sudden spikes in token requests, access to unexpected APIs, sign-ins from unfamiliar IP ranges, changes to blueprints, credential additions, permission grants and role assignments “that happen outside your normal deployment pipeline,” credentials nearing expiry, an agent blocked by Conditional Access or ID Protection, excessive failed token acquisition, and unexpected permission or role changes.¹⁴ The list applies just as well to AI systems running on ordinary service principals and managed identities. In the program’s design, security operations owns these detections like any other (Book 12, Chapter 11), and two of them double as drift findings below: a credential added outside the pipeline, and a permission that grew without a change record.

Other clouds offer the same raw material in their own shape. AWS CloudTrail’s userIdentity element records the IAM identity that made each request and, for temporary credentials, the role that issued the session (sessionIssuer) and, where configured, the original sourceIdentity behind an assumed role.¹⁵ Google Cloud’s Agent Identity overview says its audit logs identify the agent both when it acts as itself and when it acts for an end user; the page doesn’t state a release stage or government availability, so an agency should confirm both before relying on it.¹⁶

Risk detection for workload and agent identities

Workload identities

Microsoft Entra ID Protection detects risk on workload identities as well as users. Its detections for service principals include leaked credentials, suspicious sign-ins against a learned baseline, anomalous service principal activity such as suspicious directory changes, suspicious Microsoft Graph traffic or directory enumeration, threat-intelligence matches, malicious or suspicious applications, and an administrator’s confirmation of compromise. Every detection is offline. Single-tenant, non-Microsoft SaaS and multitenant apps are in scope; managed identities aren’t. All customers receive the detections, but full risk details and risk-based Conditional Access need Workload ID Premium, and the Conditional Access response can block only single-tenant service principals registered in the tenant.¹⁷ Workload ID Premium is listed as available in Azure Government.¹⁸ The remediation Microsoft describes is the one the program uses: inventory the identity’s credentials, add a new one, remove the compromised ones, rotate any Key Vault secrets the identity could read, and disable the service principal if it must stop at once.¹⁹

Agents

ID Protection for agents applies the same idea to agent identities. Its detections are an administrator’s confirmation of compromise, early-life malicious activity by a newly created agent, directory reconnaissance, failed attempts to reach resources the agent isn’t authorized for, threat-intelligence matches, sign-in spikes, credentials newly added to a blueprint and then used, and access to resources the agent doesn’t usually touch. All are offline. A learning mode suppresses behavioral alerts for agents without enough history, with a separate detection for malicious early-life behavior. In on-behalf-of flows the risk is attributed to the user, not the agent, so a compromised user session is remediated without disrupting the agent for everyone else. The Risky Agents report offers confirm compromise, confirm safe, dismiss and disable; confirming compromise sets the risk to High and triggers any Conditional Access policy that blocks high agent risk.²⁰

The release stage is the part to read carefully. Microsoft’s agent administration guide says ID Protection for agents “requires a Microsoft Entra ID P2 license during preview,” and the Conditional Access condition that uses it is labeled Agent risk (Preview); the ID Protection page adds that it will soon require a Microsoft Agent 365 license.²¹²²²³ The Conditional Access assignment for agents is itself still labeled preview, and agent identities support only the Block control, which is what Book 04, Chapter 03 records.²⁴ The program follows Book 04’s rule: it collects the agent risk tables (Book 12, Chapter 03 lists AADRiskyAgents and AADAgentRiskEvents) and triages what they report, but it doesn’t make an enforcement design depend on a preview signal.

Finding what nobody declared

Shadow AI is not one problem. It shows up on four surfaces, each seen by a different kind of tool, and the program needs all four because no single tool sees more than one or two.

Figure 2: Shadow AI shows up on four surfaces; whatever discovery finds is reconciled with the identity record, and anything without a record is a finding.

Generative AI services that staff use. Microsoft Defender for Cloud Apps has a Generative AI category in its cloud app catalog, which Microsoft says now holds more than a thousand generative AI apps, each with a risk assessment across security and compliance factors. An agency can filter discovered apps on the category, sanction or unsanction each one, and set policies that alert on any newly discovered generative AI app.²⁵ Microsoft Entra Global Secure Access adds a network view: its shadow AI discovery inspects internet and Microsoft 365 traffic for connections to generative AI apps, SaaS MCP servers and AI model provider APIs, matches them against the same catalog, and reports users, usage and bytes sent.²⁶ Generative AI Insights, in preview, goes a level deeper: with TLS inspection it logs the prompt content and MCP operations sent to those services, and because it reads the MCP protocol itself rather than matching a catalog, it finds private and shadow MCP servers too. Its events can be streamed to Log Analytics or Microsoft Sentinel as the NetworkAccessGenerativeAIInsights category; MCP servers running locally on a device aren’t visible to it.²⁷ Any of these views tells the agency which services are in use. Neither tells it whether a service is authorized to hold federal data; that is the authorization verdict of Book 15, Chapter 06, which applies to AI services exactly as to any other SaaS.

Applications holding consented access. An AI service a user connected through OAuth holds a delegated grant to agency data whether or not anyone thinks of it as AI. The consent baseline (SCuBA MS.AAD.5.2v1, user consent restricted) and app governance in Defender for Cloud Apps are described in Book 04, Chapter 05 and Book 15, Chapter 06. Two Agent ID behaviors matter here. The admin consent workflow “doesn’t work correctly for permissions requested by agent identities,” so requests for agents bypass the workflow the program relies on for everything else and go directly to an administrator; and a set of high-risk Microsoft Graph permissions, including Application.ReadWrite.All, RoleManagement.ReadWrite.All and User.ReadWrite.All, can’t be granted to agents at all.²⁸ The program’s consent review therefore lists grants to agent identities separately, because they never passed through the workflow’s record.

Agents running on endpoints or reaching the internet. Microsoft Defender for Endpoint discovers local AI agents, including command-line agents, desktop apps, agentic IDEs and editor extensions, and their configured MCP servers on Windows and macOS. Discovery is generally available on both, except listed preview scenarios such as VS Code extensions on macOS and agents in Windows Subsystem for Linux.²⁹ Most agents are listed when Defender observes the agent’s process running; VS Code extensions are listed from installed-extension data the client collects, without the extension running. Microsoft is explicit that this “isn’t a complete inventory of installed software.”³⁰ The Defender portal’s AI agent inventory combines those local agents with agents built in Copilot Studio, Microsoft Foundry, Microsoft 365 and supported non-Microsoft platforms, with risk indicators, tools and identities for each.³¹ Global Secure Access’s AI agent discovery, in preview, classifies each agent it sees in network traffic as managed or shadow according to whether it is registered with Microsoft Entra Agent ID, and needs the Global Secure Access client with TLS inspection for local agents.³² The managed-or-shadow test is the right one; the program applies it to every source, not only to network traffic.

AI built in the agency’s own clouds. The AI security posture management capability in Defender for Cloud’s Defender CSPM plan discovers AI workloads and models in use, such as Azure OpenAI, Azure Machine Learning and Amazon Bedrock resources.³³ A model endpoint stood up in a development subscription is shadow AI if no inventory entry and no identity record cover it, even though it sits inside an authorized cloud boundary.

One gap no tool closes. Conditional Access, and every Entra signal in this chapter, protects only resources secured by Microsoft Entra ID: “if an agent accesses resources using an API key, it bypasses the Microsoft Entra ID authentication and token issuance pipeline entirely.”³⁴ An agent that reaches a model provider or a third-party API with a static key is invisible to identity monitoring. That is one reason Chapter 06 treats stored secrets as a finding in their own right, and why the endpoint and network surfaces above are not optional.

Release stage and government-cloud availability

Every tool above is in a different place, and several are absent from the higher government clouds. The table is as of October 2026; the program’s rule is to re-check the vendor’s own availability page at procurement and at every annual inventory refresh.

Capability	Release stage	GCC (commercial Entra)	GCC High and DoD (Azure Government)
Agent ID platform: agent identities, blueprints, sponsors, agent sign-in and audit logging	Generally available (April 2026)35	Agent 365’s registry, lifecycle and Entra features listed as available in GCC36	Not listed on the Entra availability page for Azure Government;37 confirm with Microsoft
ID Protection for workload identities	Generally available	Available	Workload ID Premium listed as available in Azure Government38
ID Protection for agents; agent risk in Conditional Access	Preview3940	Listed for agents with delegated access41	Not stated; confirm
Defender for Cloud Apps generative AI discovery	Generally available	Available	Parity with commercial except listed app governance detections42
Global Secure Access shadow AI discovery	Not labeled preview on its page43	Global Secure Access available in GCC44	Not yet supported45
Global Secure Access AI agent discovery	Preview46	As above	Not yet supported
Global Secure Access Generative AI Insights (prompt and MCP logging)	Preview47	As above	Not yet supported
Entra Health monitoring for agent sign-ins	Preview48	Not stated; Health monitoring needs P1 or P2	Not stated; confirm
Defender for Endpoint local AI agent discovery	Generally available on Windows and macOS, except VS Code extensions on macOS and Windows Subsystem for Linux, in preview49	Agent 365’s “sync shadow AI endpoint agents” and “block unsanctioned local endpoint agents” listed as not available in GCC50	Not stated; confirm
Defender CSPM AI security posture management	Generally available	Azure commercial	Generally available in Azure Government51

Microsoft states that as of October 1, 2026, Agent 365 “meets all FedRAMP High controls reviewed by Microsoft’s independent third-party assessor” and that final authorization “is pending.”⁵² Until a certification appears on the FedRAMP Marketplace, an agency treating Agent 365 as in its boundary is relying on a pending decision. The agency still authorizes its own system, as Book 10, Chapter 03 explains.

Drift: comparing what was declared with what is observed

The declared side

The declared side of an AI system has two halves. The federal AI use-case inventory supplies the agency’s own reported facts about it; Chapter 03 reads those fields as identity obligations. The 2025 inventory’s data dictionary includes the use case’s development stage, its classification (with “Agentic AI” defined as “AI systems that perform tasks or make decisions autonomously with minimal human intervention”), whether it has an associated authorization to operate (have_ato) and the name of that system (system_name_ato), whether it involves PII maintained by the agency (has_pii), an optional link to its privacy impact assessment (pia_url), the agency bureau, and a contact email for the responsible individual or team.⁵³ The program’s identity record (Chapter 05) supplies the rest: the directory objects the system uses, its sponsor and technical owner, its organizational placement and its credentials.

M-25-21 requires each agency (other than the Department of Defense and the Intelligence Community) to inventory its AI use cases at least annually.⁵⁴ The inventory is therefore a slow, self-reported source. The program uses it as a declaration to check, not as an observation, and it marks any inventory vintage older than 13 months as stale, which is a design choice, not a federal rule.

The findings

Each AI finding is an instance of one of the five drift classes in Book 13, Chapter 06, as every domain check in the workbook is. Book 13 lets a domain check pin its own severity; the severities below are the program’s pinned values, with the reason given where they differ from Book 13’s default rule.

Finding	What is compared	Class	Severity	Fixed automatically?	Routed to
An agentic AI system with no governed identity	An inventory entry classified as agentic, piloted or deployed, with no identity record, or an identity record whose directory objects have no sponsor	Identity	P1	Never	System owner and ISSO; the authorizing official informed
A shadow AI identity	A directory object, consented app or discovered agent that acts with credentials and matches no identity record	Identity	P1	Never	Security operations first, then the owner once found
A deployed AI system with no recorded authorization	have_ato is No or blank, or system_name_ato doesn’t resolve to an authorization in the agency’s records	Authorization	P2 on the inventory answer; P1 once the records confirm it	Never	Authorizing official and ISSO
An AI identity with no accountable human	No sponsor, a sponsor who has left, or no sponsor who is a federal employee mastered in HR	Identity	P2 (pinned)	Never	Identity governance officer
A credential or permission added outside the pipeline	An audit event adding a credential, grant or role with no matching change record	Authorization	P1	Never	Security operations
An AI system with no organizational placement	The identity record lacks the placement attribute every governed principal carries	Schema	P2	Within its operation class’s ceiling	Identity engineering
PII with no privacy impact assessment reference	has_pii is Yes and no PIA in the privacy office’s register covers the system	Provenance	P2 (pinned)	Never	Privacy officer
An unsanctioned generative AI service in use	A discovered service with no authorization verdict	Authorization	P2 (pinned)	Never	The SaaS authorization gate of Book 15, Chapter 06
An inventory entry with no development stage recorded	A use case whose stage column is empty, so the stage-dependent checks cannot run	Provenance	P2	Never	Inventory coordinator
A retired AI system whose identity still holds access	An inventory entry reported as retired, with a credential, grant or role still live on a matching directory object	Identity	P1 (identity drift on a live object)	Never	Security operations first, then the identity governance officer
An inventory entry with no contact	A use case whose contact field is empty, so no person can be asked about it	Provenance	P2	Never	Identity governance officer
A non-agentic AI system with no identity record	An inventory entry classified as not agentic, with no identity record for any directory object it uses	Identity	P2	Never	System owner and identity engineering

Five of the rows need comment; the four inventory-quality and leaver rows at the end of the table take P2 except the retired system that still holds access, which is P1 because it is identity drift on a live object.

The agentic AI system with no governed identity is the finding this book exists to prevent. An AI system that can act, not just answer, and has no identity record behind it is a principal nobody owns holding access nobody reviews. Book 13’s default rule makes identity drift on a live object P1, and the program keeps it there: it halts, it alerts a named person, and nothing remediates it automatically, because the right fix might be to issue an identity, to disable an agent that turns out to be unwanted, or to correct an inventory entry that misclassified a chatbot as an agent. Those are decisions, not repairs.

The deployed system with no recorded authorization is pinned at P2 on the inventory answer alone because the inventory is self-reported and the field can be wrong in either direction: a use case answered No when it sits inside an authorized platform, or Yes with a system name that matches nothing. The finding asks the ISSO to resolve the answer against the agency’s authorization records. Once the records confirm that a deployed AI system is operating with no authorization, the finding becomes P1, because M-25-22 requires an AI system operated as an information system to receive an authorization to operate “prior to deployment.”⁵⁵ The finding never closes on its own and the engine never accepts the risk; only the authorizing official does (Chapter 08).

The AI identity with no accountable human includes the sponsor who left. Microsoft Entra Lifecycle Workflows can transfer an agent’s sponsorship to the departing sponsor’s manager, generally available since May 2026,⁵⁶ and Agent ID requires a sponsor when an agent identity or blueprint is created but allows guest users to be sponsors.⁵⁷ The program’s record requires a federal employee mastered in HR as sponsor (Chapter 08), so an AI system whose only sponsors are guests or contractors is a finding even though the platform accepts it, and a transfer to a manager who doesn’t accept the sponsorship within the program’s window is too. The row is pinned at P2, below Book 13’s P1 default for identity drift on a live object, because the finding has its own bounded response: once the identity governance officer confirms it, a person disables the agent, and the sponsoring office has 30 days to name a sponsor or retire it (Chapter 05). Raising it to P1 is the alternative if the agency wants no such window.

The PII with no PIA reference row is pinned below Book 13’s default for provenance drift because the inventory’s pia_url field is optional and asks only for a publicly available link,⁵⁸ so its absence proves nothing. The finding asks the privacy office whether its own register covers the system. A confirmed gap goes to the privacy office as a privacy decision, not to the identity team.

The unsanctioned generative AI service is a finding about data, not about an identity the agency issued, and its remedy is the SaaS gate: an authorization verdict and then either sanction or block. Marking an app unsanctioned in Defender for Cloud Apps blocks it on devices onboarded to Defender for Endpoint, or warns users if the security team chooses.⁵⁹ The program pins it at P2 so it enters the queue with an owner and a clock, rather than living only in a discovery dashboard.

What the engine does and doesn’t do

The AI findings follow the same rules as every other finding in Book 13. Severity sets the clock; the operation class’s ceiling sets who may act. The program enumerates no AI finding for unattended remediation except filling a missing placement from the sponsor’s organization, and even that runs only as a gated change. Disabling a running agent is never automatic. It may be the right response, and Agent ID gives both sponsors and owners the ability to disable an agent identity,⁶⁰ but whether an agent’s behavior is an incident is a security operations decision and whether it should exist at all is the sponsor’s.

The annual inventory refresh is the other trigger. When the agency submits a new inventory, the program compares it with the last one: a new piloted or deployed entry needs an identity record before its next sign-in; a retired entry starts the leaver process of Chapter 05; a changed authorization answer is re-checked against the records. Chapter 09 describes how the scan runs at agency and central level.

From finding to evidence

Every finding above becomes one record in the evidence contract of Book 12, Chapter 02, with the same eight fields as a patch or configuration finding. The design question is the join key. Book 12’s key is the naming plane’s authoritative asset identity, because every stack has its own idea of what a server is called. AI systems have the same problem in a sharper form: the inventory’s use-case ID, the directory’s object IDs for each blueprint, agent identity and service principal, the Defender agent ID and the cloud resource ID all describe one system and agree on nothing. In the program’s design, asset_id for an AI finding is the AI system’s identity record key, and the record maps every one of those identifiers to it. A finding keyed on a display name is rejected at intake, because display names are reused and renamed.

Field	Example: an agentic system with no governed identity
asset_id	The identity record key, or for a system with no record, the inventory use-case ID it was found under
source	The inventory comparison (or the discovery tool, for a shadow finding)
surface	identity
control	AC-2, IA-4
state	Inventory classification Agentic AI, stage Deployed; no identity record; no sponsor
verdict	fail
observed_at	The time of the comparison, in synchronized time
disposition	open

The control column uses SP 800-53 Rev. 5. The program’s mapping, which is design rather than a published crosswalk, is:

Finding	Controls
Agentic system with no governed identity	AC-2 (account management), IA-4 (identifier management), IA-9 (service identification and authentication)
Shadow AI identity	CM-8 and CM-8(3) (component inventory; automated unauthorized component detection), CA-7
No recorded authorization	CA-6 (authorization), CA-7 (continuous monitoring)
No accountable human	AC-2, CM-8(4) (accountability information)
Credential or permission outside the pipeline	AC-2, AC-2(12) (account monitoring for atypical usage), IA-5 (authenticator management)
No organizational placement	IA-4, AC-2
PII with no PIA	RA-8 (privacy impact assessments)
Unsanctioned generative AI service	SA-9 and AC-20, as in Book 15, Chapter 06
No development stage recorded	CM-8 (system component inventory), PM-5 (system inventory)
Retired system still holding access	AC-2 (account management), IA-5 (authenticator management), CM-8
No contact	AC-2, CM-8(4) (accountability information)
Non-agentic system with no identity record	AC-2, IA-4 (identifier management)

The source design for this mapping cited PT-2 as the privacy impact assessment control and AR-2 for privacy risk assessment. In Rev. 5, PT-2 is Authority to Process Personally Identifiable Information, the privacy impact assessment control is RA-8, and the AR family from Rev. 4’s privacy appendix no longer exists; the table is corrected accordingly.⁶¹ It also drops CA-8 (penetration testing) and SI-7 (software integrity), which don’t describe the gaps those findings measure.

The disposition rules are Book 12’s. A record is applied only when a later observation of the same asset_id shows the fixed state: an identity record that now exists with a sponsor, an authorization the ISSO located, a credential removed. It is accepted risk only with the authorizing official’s acceptance and its plan of action and milestones reference. A ticket marked resolved closes nothing. Chapter 10 shows how these records reach the authorization package.

Honest limits

• Discovery is partial by design. Endpoint discovery needs observed activity and an onboarded device; network discovery needs the client and TLS inspection; cloud posture discovery sees only subscriptions it is connected to. An agency that can’t see a surface should say so in its continuous monitoring strategy rather than report a clean result.
• API keys are invisible to identity monitoring. Any AI that authenticates with a static key outside Entra produces no sign-in, no risk detection and no Conditional Access decision.
• The inventory is self-reported and annual. It is a declaration, and the comparison can only be as current as its last vintage.
• The higher government clouds lag. Several capabilities in this chapter are commercial or GCC only, and some Agent ID features aren’t listed for Azure Government at all. A GCC High or DoD agency may have to rely on ordinary workload identity telemetry and the identity record for longer.
• Preview signals change. Agent risk, the agent Conditional Access targets and network agent discovery are preview. The program collects them and doesn’t build enforcement on them.

What this chapter establishes

Old habit	What replaces it
AI systems are monitored like any other app, if at all	Every AI identity’s sign-ins, changes and risk are collected, and each one is tied to an identity record
Shadow AI is a one-time discovery exercise	Four discovery surfaces feed the same comparison continuously
“Is this an agent?” is answered from a display name	It is answered from the identity record key, with the agentType property where Agent ID is used
A discovered AI tool sits on a dashboard	It becomes a finding with a class, a severity, an owner and a window
An agentic system with no identity is a backlog item	It is P1: halt, alert and a human decision
The inventory’s authorization answer is taken at its word	It is resolved against the agency’s authorization records, and a confirmed gap is P1
Preview features are switched on and relied on	They are collected and triaged; enforcement waits for general availability in the agency’s cloud

TipContinue the book

← Previous: Chapter 06 — Credentials, Least Privilege and Access Policy for AI · Book index · Next: Chapter 08 — Who Owns AI Identity Governance →

---

1. Office of Management and Budget, M-25-21, Accelerating Federal Use of AI through Innovation, Governance, and Public Trust, April 3, 2025, §3(b)(v) (annual inventory) and §4(b)(iii) (ongoing monitoring), https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-21-Accelerating-Federal-Use-of-AI-through-Innovation-Governance-and-Public-Trust.pdf (accessed Oct 22, 2026).

2. National Institute of Standards and Technology, NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0), January 2023, GOVERN 1.6, MEASURE 2.4 and MANAGE 4.1, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf (accessed Oct 22, 2026).

3. Microsoft Learn, “What are Microsoft Entra sign-in logs?,” https://learn.microsoft.com/entra/identity/monitoring-health/concept-sign-ins (accessed Oct 22, 2026).

4. Microsoft Learn, “Microsoft Entra Agent ID logs,” https://learn.microsoft.com/entra/agent-id/sign-in-audit-logs-agents (accessed Oct 22, 2026).

5. Microsoft Learn, “Microsoft Entra releases and announcements,” April 2026 (“General Availability - Microsoft Entra Agent ID platform”) and May 2026 (“General Availability - Manage Agent ID sponsorship lifecycle with Lifecycle Workflows”), https://learn.microsoft.com/entra/fundamentals/whats-new (accessed Oct 22, 2026).

6. Microsoft Learn, “How to investigate Agent ID autonomous sign-ins,” Understand what autonomous means, Prerequisites and Investigate the signals and alert, https://learn.microsoft.com/entra/identity/monitoring-health/scenario-health-agent-id-autonomous-sign-ins (accessed Nov 9, 2026).

7. Microsoft Learn, “Investigate Agent ID interactive sign-ins,” https://learn.microsoft.com/entra/identity/monitoring-health/scenario-health-agent-id-interactive-sign-ins (accessed Nov 9, 2026).

8. Microsoft Learn, “How to investigate Agent ID autonomous sign-ins,” Understand what autonomous means, Prerequisites and Investigate the signals and alert, https://learn.microsoft.com/entra/identity/monitoring-health/scenario-health-agent-id-autonomous-sign-ins (accessed Nov 9, 2026).

9. Microsoft Learn, “Conditional Access for agents,” section “Boundaries and limitations,” https://learn.microsoft.com/entra/identity/conditional-access/agent-id (accessed Oct 22, 2026).

10. Microsoft Learn, “Microsoft Entra Agent ID logs,” https://learn.microsoft.com/entra/agent-id/sign-in-audit-logs-agents (accessed Oct 22, 2026).

11. Microsoft Learn, “Frequently asked questions about Microsoft Entra Agent ID,” sections on consent and on monitoring and logs, https://learn.microsoft.com/entra/agent-id/faq (accessed Oct 22, 2026).

12. Microsoft Learn, “Microsoft Entra data retention,” https://learn.microsoft.com/entra/identity/monitoring-health/reference-reports-data-retention (accessed Oct 22, 2026).

13. Microsoft Learn, “Configure the Agent 365 CLI for US Government clouds,” section “Configure GCC High or DoD,” https://learn.microsoft.com/microsoft-agent-365/developer/configure-cloud-endpoints (accessed Oct 22, 2026).

14. Microsoft Learn, “Best practices for Microsoft Entra Agent ID,” section “Monitor and audit agent activity,” https://learn.microsoft.com/entra/agent-id/best-practices-agent-id (accessed Oct 22, 2026).

15. Amazon Web Services, “CloudTrail userIdentity element,” AWS CloudTrail User Guide, https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html (accessed Oct 22, 2026).

16. Google Cloud, “Agent Identity overview,” https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/agent-identity-overview (accessed Oct 22, 2026).

17. Microsoft Learn, “Securing workload identities,” https://learn.microsoft.com/entra/id-protection/concept-workload-identity-risk (accessed Oct 22, 2026).

18. Microsoft Learn, “Microsoft Entra feature availability” (Azure for US Government), updated February 13, 2026, https://learn.microsoft.com/entra/identity/authentication/feature-availability (accessed Oct 22, 2026).

19. Microsoft Learn, “Securing workload identities,” https://learn.microsoft.com/entra/id-protection/concept-workload-identity-risk (accessed Oct 22, 2026).

20. Microsoft Learn, “ID Protection for agents,” https://learn.microsoft.com/entra/id-protection/concept-risky-agents (accessed Oct 22, 2026).

21. Microsoft Learn, “Manage agent identities in your organization,” section “Detect and remediate agent risk,” https://learn.microsoft.com/entra/agent-id/manage-agent-identities-admin (accessed Oct 22, 2026).

22. Microsoft Learn, “Target agent identities in Microsoft Entra Conditional Access policies,” https://learn.microsoft.com/entra/identity/conditional-access/howto-target-agent-identities; and “Secure autonomous agents with Conditional Access,” section “Block high-risk agent identities” (“Agent risk is in Preview”), https://learn.microsoft.com/entra/identity/conditional-access/policy-autonomous-agents (both accessed Oct 22, 2026).

23. Microsoft Learn, “ID Protection for agents,” https://learn.microsoft.com/entra/id-protection/concept-risky-agents (accessed Oct 22, 2026).

24. Microsoft Learn, “Target agent identities in Microsoft Entra Conditional Access policies,” https://learn.microsoft.com/entra/identity/conditional-access/howto-target-agent-identities; and “Secure autonomous agents with Conditional Access,” section “Block high-risk agent identities” (“Agent risk is in Preview”), https://learn.microsoft.com/entra/identity/conditional-access/policy-autonomous-agents (both accessed Oct 22, 2026).

25. Microsoft Learn, “Discover AI apps and data,” step 3, “Discover, sanction, and block AI apps with Microsoft Defender for Cloud Apps,” https://learn.microsoft.com/security/security-for-ai/discover (accessed Oct 22, 2026).

26. Microsoft Learn, “Shadow AI discovery in Global Secure Access,” https://learn.microsoft.com/entra/global-secure-access/concept-shadow-ai-discovery (accessed Oct 22, 2026).

27. Microsoft Learn, “Generative AI Insights in Global Secure Access (preview),” Generative AI Insights vs. Shadow AI discovery, Stream Generative AI Insights to a SIEM and Limitations, https://learn.microsoft.com/entra/global-secure-access/concept-generative-ai-insights (accessed Nov 9, 2026).

28. Microsoft Learn, “Frequently asked questions about Microsoft Entra Agent ID,” sections on consent and on monitoring and logs, https://learn.microsoft.com/entra/agent-id/faq (accessed Oct 22, 2026).

29. Microsoft Learn, “Microsoft Defender for Endpoint AI agent support matrix,” section “AI agent discovery support” (generally available on supported Windows and macOS devices except the preview scenarios listed; macOS VS Code extensions and Windows Subsystem for Linux marked preview), https://learn.microsoft.com/defender-endpoint/ai-agent-support-matrix (accessed Nov 9, 2026).

30. Microsoft Learn, “Local AI agent discovery with Microsoft Defender for Endpoint,” https://learn.microsoft.com/defender-endpoint/local-agent-discovery-overview (accessed Oct 22, 2026; re-read Nov 9, 2026: process-based discovery and installed VS Code extension data).

31. Microsoft Learn, “Discover AI agents and assess security posture using Microsoft Defender,” https://learn.microsoft.com/defender-xdr/security-for-ai/ai-agent-inventory (accessed Oct 22, 2026).

32. Microsoft Learn, “AI agent discovery in Global Secure Access (preview),” https://learn.microsoft.com/entra/global-secure-access/concept-ai-agent-discovery (accessed Oct 22, 2026).

33. Microsoft Learn, “Support matrices for Defender for Cloud,” section “Cloud support” (AI security posture management: GA in Azure and Azure Government; Defender for AI Services not available in Azure Government), updated July 1, 2026, https://learn.microsoft.com/azure/defender-for-cloud/support-matrix-defender-for-cloud; and “Discover AI apps and data,” step 4, https://learn.microsoft.com/security/security-for-ai/discover (both accessed Oct 22, 2026).

34. Microsoft Learn, “Conditional Access for agents,” section “Boundaries and limitations,” https://learn.microsoft.com/entra/identity/conditional-access/agent-id (accessed Oct 22, 2026).

35. Microsoft Learn, “Microsoft Entra releases and announcements,” April 2026 (“General Availability - Microsoft Entra Agent ID platform”) and May 2026 (“General Availability - Manage Agent ID sponsorship lifecycle with Lifecycle Workflows”), https://learn.microsoft.com/entra/fundamentals/whats-new (accessed Oct 22, 2026).

36. Microsoft Learn, “Microsoft Agent 365” service description, section “Feature availability,” https://learn.microsoft.com/office365/servicedescriptions/microsoft-agent-365/microsoft-agent-365 (accessed Oct 22, 2026).

37. Microsoft Learn, “Microsoft Entra feature availability” (Azure for US Government), updated February 13, 2026, https://learn.microsoft.com/entra/identity/authentication/feature-availability (accessed Oct 22, 2026).

38. Microsoft Learn, “Microsoft Entra feature availability” (Azure for US Government), updated February 13, 2026, https://learn.microsoft.com/entra/identity/authentication/feature-availability (accessed Oct 22, 2026).

39. Microsoft Learn, “Manage agent identities in your organization,” section “Detect and remediate agent risk,” https://learn.microsoft.com/entra/agent-id/manage-agent-identities-admin (accessed Oct 22, 2026).

40. Microsoft Learn, “Target agent identities in Microsoft Entra Conditional Access policies,” https://learn.microsoft.com/entra/identity/conditional-access/howto-target-agent-identities; and “Secure autonomous agents with Conditional Access,” section “Block high-risk agent identities” (“Agent risk is in Preview”), https://learn.microsoft.com/entra/identity/conditional-access/policy-autonomous-agents (both accessed Oct 22, 2026).

41. Microsoft Learn, “Microsoft Agent 365” service description, section “Feature availability,” https://learn.microsoft.com/office365/servicedescriptions/microsoft-agent-365/microsoft-agent-365 (accessed Oct 22, 2026).

42. Microsoft Learn, “Microsoft Defender for Cloud Apps for US Government offerings,” section “Feature variations,” https://learn.microsoft.com/defender-cloud-apps/editions-cloud-app-security-gcc (accessed Oct 22, 2026).

43. Microsoft Learn, “Shadow AI discovery in Global Secure Access,” https://learn.microsoft.com/entra/global-secure-access/concept-shadow-ai-discovery (accessed Oct 22, 2026).

44. Microsoft Learn, “Known limitations for Global Secure Access,” section “Global Secure Access In Government Cloud limitations,” https://learn.microsoft.com/entra/global-secure-access/reference-current-known-limitations (accessed Oct 22, 2026).

45. Microsoft Learn, “Known limitations for Global Secure Access,” section “Global Secure Access In Government Cloud limitations,” https://learn.microsoft.com/entra/global-secure-access/reference-current-known-limitations (accessed Oct 22, 2026).

46. Microsoft Learn, “AI agent discovery in Global Secure Access (preview),” https://learn.microsoft.com/entra/global-secure-access/concept-ai-agent-discovery (accessed Oct 22, 2026).

47. Microsoft Learn, “Generative AI Insights in Global Secure Access (preview),” Generative AI Insights vs. Shadow AI discovery, Stream Generative AI Insights to a SIEM and Limitations, https://learn.microsoft.com/entra/global-secure-access/concept-generative-ai-insights (accessed Nov 9, 2026).

48. Microsoft Learn, “How to investigate Agent ID autonomous sign-ins,” Understand what autonomous means, Prerequisites and Investigate the signals and alert, https://learn.microsoft.com/entra/identity/monitoring-health/scenario-health-agent-id-autonomous-sign-ins (accessed Nov 9, 2026).

49. Microsoft Learn, “Microsoft Defender for Endpoint AI agent support matrix,” section “AI agent discovery support” (generally available on supported Windows and macOS devices except the preview scenarios listed; macOS VS Code extensions and Windows Subsystem for Linux marked preview), https://learn.microsoft.com/defender-endpoint/ai-agent-support-matrix (accessed Nov 9, 2026).

50. Microsoft Learn, “Microsoft Agent 365” service description, section “Feature availability,” https://learn.microsoft.com/office365/servicedescriptions/microsoft-agent-365/microsoft-agent-365 (accessed Oct 22, 2026).

51. Microsoft Learn, “Support matrices for Defender for Cloud,” section “Cloud support” (AI security posture management: GA in Azure and Azure Government; Defender for AI Services not available in Azure Government), updated July 1, 2026, https://learn.microsoft.com/azure/defender-for-cloud/support-matrix-defender-for-cloud; and “Discover AI apps and data,” step 4, https://learn.microsoft.com/security/security-for-ai/discover (both accessed Oct 22, 2026).

52. Microsoft Learn, “Microsoft Agent 365” service description, section “Feature availability,” https://learn.microsoft.com/office365/servicedescriptions/microsoft-agent-365/microsoft-agent-365 (accessed Oct 22, 2026).

53. Office of Management and Budget, 2025 Federal Agency AI Use Case Inventory, Validation/data_dictionary.md (fields contact_email, development_stage, classification, have_ato, system_name_ato, has_pii, pia_url), https://github.com/ombegov/2025-Federal-Agency-AI-Use-Case-Inventory (accessed Oct 22, 2026).

54. Office of Management and Budget, M-25-21, Accelerating Federal Use of AI through Innovation, Governance, and Public Trust, April 3, 2025, §3(b)(v) (annual inventory) and §4(b)(iii) (ongoing monitoring), https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-21-Accelerating-Federal-Use-of-AI-through-Innovation-Governance-and-Public-Trust.pdf (accessed Oct 22, 2026).

55. Office of Management and Budget, M-25-22, Driving Efficient Acquisition of Artificial Intelligence in Government, April 3, 2025, §4(e)(i), https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-22-Driving-Efficient-Acquisition-of-Artificial-Intelligence-in-Government.pdf (accessed Oct 22, 2026).

56. Microsoft Learn, “Microsoft Entra releases and announcements,” April 2026 (“General Availability - Microsoft Entra Agent ID platform”) and May 2026 (“General Availability - Manage Agent ID sponsorship lifecycle with Lifecycle Workflows”), https://learn.microsoft.com/entra/fundamentals/whats-new (accessed Oct 22, 2026).

57. Microsoft Learn, “Administrative relationships in Microsoft Entra Agent ID (Owners, sponsors, and managers),” https://learn.microsoft.com/entra/agent-id/agent-owners-sponsors-managers (accessed Oct 22, 2026).

58. Office of Management and Budget, 2025 Federal Agency AI Use Case Inventory, Validation/data_dictionary.md (fields contact_email, development_stage, classification, have_ato, system_name_ato, has_pii, pia_url), https://github.com/ombegov/2025-Federal-Agency-AI-Use-Case-Inventory (accessed Oct 22, 2026).

59. Microsoft Learn, “Manage generative AI apps for your organization,” section “Use Defender for Cloud Apps to discover, monitor, or block generative AI apps,” https://learn.microsoft.com/microsoft-365/copilot/manage-generative-ai-apps (accessed Oct 22, 2026).

60. Microsoft Learn, “Administrative relationships in Microsoft Entra Agent ID (Owners, sponsors, and managers),” https://learn.microsoft.com/entra/agent-id/agent-owners-sponsors-managers (accessed Oct 22, 2026).

61. National Institute of Standards and Technology, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, release 5.2.0, controls AC-2, AC-2(12), CA-6, CM-8, CM-8(3), CM-8(4), IA-4, IA-5, IA-9, PT-2 and RA-8, https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; control text checked against the release 5.2.0 OSCAL catalog, https://github.com/usnistgov/oscal-content/tree/main/nist.gov/SP800-53/rev5/json (both accessed Oct 22, 2026).