Everything else on this site you could, eventually, assemble from Microsoft's documentation. This page you couldn't. These are the things that bit me — or nearly did — while actually deploying this stack: schema traps, licence boundaries dressed up as empty tables, and controls that stopped working without saying so. Short, specific, and dated to August 2026.
arg_max(Timestamp, *) collapses your fleet to one rowAgentsInfo stores repeated snapshots of every agent, so the tempting one-liner summarize arg_max(Timestamp, *) returns exactly one agent — the most recently written row in the entire table. I shipped that into a workbook tile and stared at an inventory of one for longer than I'd like to admit. The correct reduction is summarize arg_max(Timestamp, *) by AgentId, and then filter out LifecycleStatus == "Deleted", or your inventory quietly counts ghosts.
Before declaring a data gap, work out which one: the licence gate isn't met, you're on the wrong query surface, or there is genuinely no data. The surfaces don't degrade gracefully — a table queried on the wrong one fails outright. CopilotActivity is a Log Analytics table that Advanced Hunting has never heard of; UnifiedAgentObservability exists only in the Sentinel data lake; AgentsInfo populates its local-agent rows on E5 but needs Agent 365 for the cloud ones. Same symptom, three different fixes — and only one of them costs money.
Agents built before agent identities existed authenticate with an ordinary app registration or the maker's own credentials. They appear in none of the agent identity views — not Entra's Agent ID blade, not the data lake identity tables — which is precisely what makes them the population to worry about. The service principal tag AgentCreatedBy:CopilotStudio is how I find them. If your governance story starts at "agents with identities", these agents aren't in it.
Learn pages reference AgentInfo; the deployed table is AgentsInfo. The retired AIAgentsInfo still sits in the schema listing next to its replacement. The Graph audit table is spelled GraphAPIAuditEvents on one Learn page and GraphApiAuditEvents on another. Not malice — a product moving faster than its docs. But it means the schema tab in your own portal outranks any web page, this one included.
The four EntraAgent* identity tables landed in the data lake (preview) with no published column reference — the announcement blog shows a handful of camelCase fields, and that's all anyone has. Every query I write against them wraps columns in column_ifexists() and carries a "validate in-tenant" flag. Preview tables are absolutely usable; just never let a dashboard break because a column got renamed underneath it.
The registry counts published titles. Defender's inventory counts what it can see, local agents included. Entra counts only what holds a directory principal. Even within one product, Microsoft's own documentation shows the registry portal tile and the catalog API returning different counts for the same tenant. The spread between these numbers isn't noise — most of the time it is the finding. How I reconcile them is on the Agent Map page.
The Agent 365 SDK's capabilities are separable, and its observability can run on a plain Entra app registration. So an agent can send you rich telemetry while holding no agent identity at all, and an agent with a first-class identity can be telemetry-silent. I audit them as two columns, and the interesting rows are the ones where they disagree.
Agent identities hold no credentials of their own — the blueprint holds the secrets and impersonates its agents. One leaked blueprint credential is therefore every agent under that blueprint; Microsoft's own guidance calls blueprint count "a security boundary decision". The useful corollary: disabling a blueprint stops all of its agents authenticating, in one action. That's your fleet kill switch. Write it into the emergency runbook before you need it.
When agent blocking moved under the Security for AI policy umbrella in mid-2026, pre-existing Block rules were reported to simply stop enforcing until recreated in the new location — no error, no alert, just an old rule that no longer did anything. Verify that one in your own tenant; it's exactly the kind of behaviour that gets fixed quietly. The durable lesson stands either way: after every platform migration, ask which of your controls came along — and how you would know.
Defender for Cloud Apps session controls apply only to apps onboarded to Conditional Access App Control — which public AI sites are not, so a session policy never sees that paste. Endpoint DLP can govern it, but paste content is classified locally: exact data match and trainable classifiers don't fire on paste; only standard pattern-based sensitive info types do. And blocking carries its own cost — people route around controls, so visibility is usually worth more than prohibition.
These notes date fast — that's rather the point. Anything here older than a couple of months deserves re-verification against Microsoft Learn before you rely on it.