If you read Azure Copilot’s New Agent Lineup: What Changes Today, and What Platform Teams Should Do About It, you already know the headline: six named agents, one GA, five in preview, all default-on the moment your tenant has Copilot enabled. What that post doesn’t dwell on — reasonably, since it’s a governance piece — is how those agents actually see your environment well enough to reason about it in the first place. Read the docs on the Migration, Resiliency, and Troubleshooting Agents closely enough and the same phrase keeps showing up: Azure Resource Graph.
That’s not a coincidence, and it’s worth understanding, because Resource Graph isn’t new, isn’t glamorous, and most platform teams already have queries written against it for governance dashboards. It just quietly became load-bearing infrastructure for a wave of AI agents that most people evaluating those agents haven’t looked underneath.
What Resource Graph actually is
Strip away the AI story for a second. Azure Resource Graph is a query engine, not a resource type you deploy — it lets you explore Azure resources at scale, across subscriptions and management groups, with near-instant results. The mechanism that makes this fast is the important part: instead of querying each resource provider individually the way the Azure Portal’s standard resource list does, Resource Graph maintains a pre-indexed cache of resource metadata, so complex queries return in seconds even against an estate with thousands of resources.
The query language is Kusto Query Language (KQL) — the same language behind Log Analytics, Microsoft Sentinel, and Azure Data Explorer, which means if your team already writes Sentinel detection rules or Log Analytics queries, Resource Graph syntax will feel immediately familiar. Resource Graph exposes multiple tables beyond the default Resources table — things like AdvisorResources, AlertsManagementResources, and AppServiceResources — and supports joining across them to pull related properties together in a single query.
Access follows ordinary Azure RBAC: you need at least read access to a resource or subscription for it to show up in results at all, and Resource Graph respects that boundary strictly, returning nothing for anything you’re not permitted to see. That detail matters more than it looks like it should, and I’ll come back to it.
The governance use cases that made Resource Graph popular long before any of this agent lineup existed are the same use cases that make it a good foundation for agents: inventory management, tag compliance, orphan detection, policy compliance, and RBAC auditing — all done in seconds against an indexed cache rather than slow, provider-by-provider API calls.
Why an AI agent needs a graph, not just an API
Here’s the underlying problem every one of these Copilot agents has to solve before it can do anything useful: it needs a fast, accurate, permission-scoped picture of what actually exists in your environment before it can recommend anything, diagnose anything, or simulate anything.
Consider what that means concretely for three of the agents from the lineup:
The Resiliency Agent has to check whether your resources are actually spread across availability zones the way your architecture assumes they are — and it draws on Resource Graph specifically to generate those resiliency reports. That’s a textbook Resource Graph query pattern: join a resource type against its zone/region metadata, aggregate across a subscription or management group, and flag mismatches. Doing this via live ARM calls against every resource provider, one at a time, across a large estate would be too slow to feel like an interactive “agent” experience at all. Querying an indexed cache is what makes it feel instant.
The Migration Agent does agentless discovery that maps existing infrastructure and is application-aware rather than purely infrastructure-aware. Before it can recommend a migration path or generate target infrastructure as Bicep or Terraform, it needs an accurate topology of what’s already there — which resources exist, how they’re connected, what SKUs and configurations they’re running. That’s a discovery and inventory problem, and inventory-at-scale is precisely what Resource Graph was built to solve for governance teams years before “agent” was part of the conversation.
The Troubleshooting Agent runs diagnostics and returns either a fix or a support ticket, and it’s strongest on AKS, Cosmos DB, and Azure-hosted VMs — the workload types with the richest telemetry for it to reason over. Telemetry from Azure Monitor tells it what’s wrong; Resource Graph is what lets it correlate that against what else is nearby and how it’s configured without a slow round-trip through every relevant resource provider’s own API.
The pattern across all three: telemetry systems (Azure Monitor, Log Analytics) tell an agent what’s happening right now; Resource Graph tells it what the environment actually looks like structurally. An agent that skipped the graph and relied purely on live ARM calls per query would be noticeably slower and would struggle to reason across subscriptions and management groups in a single pass — which is exactly the kind of cross-cutting question a governance or resiliency agent gets asked most often (“show me every VM across all subscriptions without a paired availability zone”).
The detail that should change how you think about “agent access”
Go back to that RBAC point for a moment, because it’s the part with real governance implications, and it’s the part the earlier post on this blog only gestured at.
Resource Graph enforces read RBAC strictly: no results are returned for anything the querying principal doesn’t have at least read access to. On the surface, that sounds like a clean, comforting security boundary — the agent can’t see what the calling identity can’t see.
But sit with what that actually implies for the agent lineup: the scope of every Resiliency, Migration, and Troubleshooting Agent query is defined by whatever identity is running the agent, not by some narrower, purpose-built service principal Microsoft configured for the agent’s specific job. If that identity has broad read access across your tenant — which platform engineers, subscription owners, and a lot of “just in case” elevated roles often do — the agent’s view is exactly as broad. There’s no additional narrowing happening at the Resource Graph layer beyond ordinary RBAC.
That reframes the access-review recommendation from the earlier governance post. It’s not enough to ask “who can reach Azure Copilot chat, Azure Monitor, and Azure Migrate.” The more precise question is: for every identity that can invoke one of these agents, what does that identity’s Resource Graph read scope actually look like today? Those are two different audits, and the second one is the one that tells you what an agent can actually see and reason over, tenant-wide, the moment someone asks it a cross-subscription question.
What this means practically for platform teams
A few concrete things follow from understanding this dependency, beyond the general “review access” guidance already out there:
Your existing Resource Graph queries are a preview of agent behavior. If your team already has governance queries — tag compliance checks, orphan detection, zone-redundancy audits — those queries are functionally similar to what the Resiliency and Migration Agents are doing under the hood, just without the generative layer turning the output into prose and next steps. Reading through your own governance query library is a fast, concrete way to understand what these agents can plausibly see and compute, rather than treating them as an unknowable black box.
Tag and metadata hygiene now has an AI-facing payoff, not just a governance one. Resource Graph queries are only as useful as the metadata on the resources they’re querying. An estate with inconsistent tagging or missing metadata doesn’t just make your compliance dashboard messier — it also means the agents built on top of the same graph are reasoning over incomplete or inconsistent data when they generate a resiliency report or a migration plan. Cleaning up tagging discipline is now, indirectly, an AI-agent-quality investment.
Management group structure affects what a single agent invocation can see in one pass. Because Resource Graph queries can span subscriptions and management groups in a single query, the way you’ve organized your management group hierarchy determines how naturally an agent can reason across your whole estate versus needing multiple narrower invocations. If your management groups map cleanly to environments or business units, that structure is doing useful work for the agents too, not just for your policy assignments.
“Read access” needs to be audited as “agent-relevant scope,” not just human-relevant scope. The RBAC-scoping point above is the one worth carrying into your next access review cycle specifically: broad standing read access that felt low-risk when the only consumer was a human clicking through the portal reads differently once that same access implicitly defines the boundary of what an autonomous agent can see and act on.
None of this is a reason to slow down adoption of the Copilot agent lineup — Resource Graph is a mature, well-understood, RBAC-respecting service, and building on it rather than on ad hoc per-resource-provider calls is the right architectural choice for Microsoft to have made. But “built on infrastructure we already trust” is different from “requires no new thinking,” and the access-scope question is the piece of that thinking that’s easy to skip past when the agent in front of you feels like a chat box rather than a query engine wearing a conversational interface.
The agents are new. The graph underneath them is not. Understanding where one ends and the other begins is what turns “the AI can see everything, I guess” into an actual, auditable statement about your environment.
Discover more from ksharp
Subscribe to get the latest posts sent to your email.
