Microsoft Entra Agent ID on DR.365

Runtime agent governance: whose permissions does a delegated agent use?

Sat, 17 Oct 2026 07:00:00 +0200

An employee asks the HR agent on the intranet how many vacation days they have left. The HR agent knows the leave policy but has no numbers, so it hands the question to a connected payroll agent that another team built. The payroll agent queries the HR system through a connector. That connector was set up with the account of the person who built the payroll agent, and that person can read every employee’s record. Whether the answer contains only the employee’s own balance or a colleague’s as well is now up to the language model.

On paper, nothing is wrong here. Both agents have an owner, both are registered and approved. The question of whose permissions the second agent uses only comes up at the moment of the call, and that moment is what this post is about.

Design time and runtime

Part 2 covered governance at design time: three zones, seven phases, an owner for every agent and a Go, Change, Hold or Stop decision. Those decisions are made once, before an agent goes into production.

At runtime, the agent decides with every request which tool to call, which other agent to involve and what data to pass along. A language model makes those decisions. For me, runtime governance means that identity, policy, authorization and logging apply at each of these hand-offs, whatever the model suggests.

Part 1 maps the tools to three models: with Agent Builder the platform carries the risk, with Copilot Studio the administrator, with Foundry the organization. At runtime that mapping becomes concrete, and in places it shifts. Agent Builder agents do not call external services, so their runtime risk is the user’s permissions. In Copilot Studio, responsibility arises at every single tool. A maker who enters their own credentials takes part of the risk off the administrator’s desk and onto their own. With Foundry, the organization builds the controls itself, for example guardrails that inspect tool calls and tool responses (preview) (Microsoft Learn). This post focuses on Copilot Studio, because that is where most hand-offs can be configured.

Signing in to the first agent is not enough

A user signing in to the HR agent tells you nothing about what the payroll agent two steps further down may do. The user’s identity has to travel all the way to the business system. In Copilot Studio, each tool decides this on its own: it uses either the end user’s credentials or the maker’s. End-user credentials are the default, and the automatic security scan warns the maker before publishing if they switch it (Microsoft Learn).

Admins can turn off maker-provided credentials per environment or environment group in the Power Platform admin center (Microsoft Learn). Every action then runs as the person who is asking. The trade-off is real: autonomous agents that start on a schedule or an event without a signed-in user fail in those environments. I would enforce the setting in production environments for zone 2 and zone 3 agents and give autonomous agents a separate environment with its own rules.

Entra calls the same pattern on-behalf-of. The agent exchanges the user’s token for a new one issued for the target resource, and Conditional Access evaluates that exchange (Microsoft Learn). The agent also has an identity of its own. Since May 2026, new Copilot Studio agents get a Microsoft Entra Agent ID automatically: at creation in the standard harness, on first publish in the GitHub Copilot harness. The agent owner is added as its sponsor (Microsoft Learn).

Keep enforcement out of the prompt

The model picks the next tool, and a crafted email or a poisoned document in a knowledge source can influence that choice. A rule that only lives in the agent’s instructions (“never return salary data”) is therefore a request to the model. Enforcement has to happen somewhere the model cannot talk its way past.

Microsoft 365 offers several layers for this. Data policies in the Power Platform admin center define which connectors an agent may use, and the connector platform checks them again on every call (Microsoft Learn). Conditional Access evaluates tokens for agent identities. Microsoft Defender can inspect and block tool calls from Copilot Studio agents in real time, currently in preview (Microsoft Learn). Under the hood, the agent asks an external service for a verdict before each tool call. If no answer arrives within one second, Copilot Studio allows the call by default. In a regulated environment I would switch the error behavior to block (Microsoft Learn).

Limit context on purpose

What an agent passes on matters as much as what it retrieves. In Copilot Studio, a child agent always receives the parent’s context. For a connected agent you can turn off passing the conversation history, so it only receives the specific task (Microsoft Learn). That is what I would do in the example. The payroll agent needs the question about vacation days. It has no business seeing the earlier part of the chat where the employee may have mentioned being ill.

On the data side, the familiar controls apply. Copilot Studio only returns content the user can access, and for files encrypted by a sensitivity label the user also needs the EXTRACT usage right (Microsoft Learn). That protection depends on the query running with the user’s permissions. A tool that uses maker credentials sees whatever the maker sees.

Treat an MCP server like an API

The Model Context Protocol (MCP) defines how an agent discovers and calls tools. Authorization is explicitly optional in the specification. When a server implements it, the server acts as an OAuth 2.1 resource server: it must check that a token was issued for it and must not accept or pass on any other tokens (MCP specification). Whether a given server actually does that depends on its code. So I treat every MCP server like a third-party API and ask who runs it, what data it sees, how it authenticates and who approves it.

Copilot Studio connects MCP servers through a wizard that offers no authentication, an API key or OAuth 2.0. Because access runs through Power Platform connectors under the hood, data policies cover MCP servers too (Microsoft Learn). Agent 365 adds a second layer. Under Agents > Tools in the Microsoft 365 admin center, admins can block an MCP server for the whole organization. For supported servers, individual tools can be switched off as well, for example write and delete operations, while read operations stay available. This tool-level control is still rolling out and is enforced at runtime by the Agent 365 Tooling Gateway (Microsoft Learn).

The control plane: registry, identity, protection, audit

The tools so far live in several portals. The agent registry in the Microsoft 365 admin center pulls them together. Agent 365 has been generally available since May 1, 2026, and is licensed per user (Microsoft Learn). The registry lists agents from all platforms, including those registered in Entra, and with the right license it consolidates risk signals from Purview, Entra and Defender for each agent (Microsoft Learn).

Entra Agent ID provides the identity, with a sponsor, Conditional Access and ID Protection for agents. Purview captures prompts and responses in the unified audit log and surfaces them in DSPM for AI. For Agent 365 that explicitly includes agent-to-tool and agent-to-agent interactions (Microsoft Learn). Check licensing carefully. Conditional Access for agents requires Microsoft 365 E7, or Agent 365 together with at least Entra ID P1 or Microsoft 365 E3 (Microsoft Learn). Licensing terms change often, so verify the current version before you roll out.

Delegation without inherited permissions

Back to the payroll agent. Microsoft’s own guidance on multi-agent patterns says that a connected agent might have access to things the parent agent doesn’t, and that calling it should be treated like any other powerful action (Microsoft Learn). I turn that into three rules.

First, every tool in a connected agent uses end-user credentials unless there is a documented reason not to. Second, the setting “Let other agents connect to and use this one” stays off unless an agent is explicitly meant to be a building block. By default, any agent in the same environment can connect to it (Microsoft Learn). Third, agents with their own identity receive permissions through access packages with an expiry date. The sponsor is notified before access expires and has to request an extension actively. This is still in preview (Microsoft Learn).

Human approval for high-impact actions

Some actions no agent should take alone: payments, changes to master data, deleting records, changing permissions. Agent flows in Copilot Studio include human-in-the-loop actions for approvals and requests for information (Microsoft Learn). Multistage approvals combine manual stages with AI stages and conditions in between, but they are still in preview (Microsoft Learn). An AI stage can pre-sort routine cases. For high-impact actions I would always end with a human stage, so that the decision belongs to a named person.

Where the approval sits matters most. It belongs in the flow that performs the action. If it only exists in the agent’s instructions, the model decides once again whether to ask at all.

What this means for regulated environments

Organizations in scope of NIS2 in Germany must, under section 30 of the BSI Act (BSIG), among other things set up access control concepts and use multi-factor or continuous authentication (§ 30 BSIG). The law does not mention agents. I see no reason to treat an agent that reads from the HR system differently from a service account that does the same. That is my professional view, not legal advice.

For traceability, every action has to answer three questions: which user triggered it, which agents were involved, and under which identity the business system was called. The unified audit log covers a large part of this. Connected agents, however, produce separate transcripts that you have to correlate through identifiers in the telemetry (Microsoft Learn). If you may have to report an incident on a short deadline, build that query before you need it.

For recertification, agent identities belong in the same review cycle as service accounts. Sponsors and access packages with an expiry date make that possible in Entra, without anyone maintaining a spreadsheet.

A service provider adds one more question: who operates the runtime controls? Data policies, Conditional Access for agents and Defender real-time protection rules often sit with the provider, while approvals in agent flows sit with the customer’s business owners. Defender can, for example, block a tool call that would send email to an unsafe domain (Microsoft Learn). Who sees that alert at night, and who may then block the agent, has to be settled in advance. Multi-tenant agent management in the Microsoft 365 admin center (preview) makes blocking across tenants technically easy (Microsoft Learn). The authority to do it belongs in the contract.

Where Microsoft still has gaps

Conditional Access on the agent identity is currently evaluated only when a Copilot Studio agent runs in Microsoft Teams. Other channels still call connectors through the existing Power Platform flow (Microsoft Learn). On top of that, custom connectors, MCP servers and REST tools add no API permissions to the agent ID, so the Entra view is incomplete exactly where MCP comes in. Agent Builder agents get no agent ID at all.

The documentation does not describe how identity is passed from a parent agent to a connected agent. For the standard harness it only says that, depending on the authentication setup, you might need to share the connected agent with the end users as well. I would test this in my own tenant before relying on it. Several of the runtime controls above are also still in preview or rolling out, including Defender real-time protection for Copilot Studio, multistage approvals and tool-level blocking for MCP servers.

Five things you can check tomorrow

Check in the Power Platform admin center whether your production environments still allow maker-provided credentials. The agent inventory shows in the connectionProvider field (preview) which connector operations use them.
For your most important agent, list every connected agent and child agent and find out whether each one receives the conversation history.
Open Agents > Tools in the Microsoft 365 admin center and block every MCP server whose operator you don’t know.
Check in the Microsoft Entra admin center that every agent identity has a sponsor.
Pick one high-impact action an agent can perform today and put an approval into the flow in front of it.

Which frameworks you have to prove agent governance against, and who delivers which evidence, is the topic of part 4.

Sources

This post was prompted by a LinkedIn post from Rajeev Yadav.

Built for human pace: what Anthropic's source control rewrite means for enterprise IT strategy

Wed, 14 Oct 2026 07:00:00 +0200

In May 2026, Anthropic merged about 2,500 code changes per day into its monorepo. By September it was more than 30,000. Git and the mirror infrastructure around it could not keep up, so a team of seven built its own version control system and moved the entire monorepo onto it in five months (Anthropic Engineering).

Almost nobody reading this will build a version control system. That isn’t the point of the story. Every organization runs processes that were sized for the speed of people: change advisory boards, four-eyes approvals, access reviews, CI pipelines, budgets calculated in person-days. Once agents do a large share of the work, those processes become the bottleneck, and the question is which of them you redesign before they break.

TL;DR

Agents are becoming the main consumers of your systems. Architecture decisions should assume machine clients that are always online and call APIs at high volume.
Review and approval have to move from “a human looked at everything” to rules that decide where a human must look.
Every agent needs an identity, an accountable person and a cost center. Without those three you can neither govern nor budget agent work.

What Anthropic actually changed

The headlines say “Anthropic threw out Git”. The engineering post is more careful. The new system is called Scion, the review tool Antique. Anthropic explicitly says Scion is not a general replacement for git, because that would mean replacing the whole development toolchain. They published the design so that git platforms can adopt parts of it.

The numbers explain why they did it anyway. The main branch history is almost 100 GB, a compressed working copy more than 25 GB, and CI runs roughly 25 million checkouts per day. Git is designed for distributed clients that work offline. Anthropic’s clients are almost entirely agents and jobs that are always online. Scion moves the expensive work to the server: commits, merges, rebases, history and blame happen there, clients get sparse, virtualized checkouts that load files on demand, and much of the functionality is available through an API without any local repository. According to the post, the new infrastructure uses about 200 times less CPU and memory than the old git mirrors, and CI checkouts take seconds instead of minutes.

Three decisions in the post matter beyond source control:

There is no merge queue with a global lock. Anthropic invested in post-merge and pre-deploy testing instead. Conflicts between concurrent changes happen, and Claude usually fixes them faster than a human would notice them.
Antique can express semantic rules for approvals. A comment-only change gets treated differently from a change to sensitive logic, so human reviewers spend their time where it counts.
Access control at repository and directory level was built in from the start, not added later.

Agents are the new primary client

The first lesson is about architecture. Most enterprise systems assume a person in front of a screen. Agents behave differently: they poll, they run in parallel, and they don’t take lunch breaks.

In Microsoft 365 you can see this today in Microsoft Graph throttling. Microsoft lists two typical causes: many requests across all applications in a tenant, and many requests from one application across tenants. Polling a resource and repeatedly scanning collections are named as patterns that lead to throttling. The recommended alternatives are delta queries and change notifications, and for bulk extraction Microsoft points to Graph Data Connect instead of the REST APIs (Microsoft Learn). SharePoint Online goes one step further: an application that keeps exceeding limits can be blocked entirely (Microsoft Learn).

That guidance was written for integration developers. It now applies to every agent that reads mailboxes, sites or Teams channels on someone’s behalf. When I evaluate an agent scenario, I now ask how it detects changes before I ask what it does. An agent that rescans a document library every ten minutes works fine in the pilot and becomes a problem when 40 departments copy it.

For your own systems the same principle applies in the other direction. If agents are going to be the main consumers of an internal platform, give it a proper API, change feeds and per-client limits. A web UI with a scraping agent in front of it is the git mirror of your organization: it works until the volume grows tenfold.

Review by intent instead of line by line

The second lesson concerns control processes. The Anthropic team still reviews every change, but they review the intent, not every line. Their main job, as they describe it, is telling Claude “no”: when it violates system constraints, or when it over-engineers in response to hypothetical concerns.

In regulated environments this is the uncomfortable part. Many change processes implicitly promise that a qualified person checked everything. At 30,000 changes per day that promise can’t be kept, and honestly it often wasn’t kept at 30 per week either. The CAB that approves a stack of changes in 45 minutes is mostly checking that the form is complete.

In my experience, auditors want evidence that changes are controlled and traceable. NIS2 asks for risk management measures that include security in development and maintenance; it does not prescribe that a human reads every line. That leaves room for a model that ITIL already knows as standard changes, applied to agent output:

Low risk (documentation, tests, formatting, configuration within defined guardrails): automated checks, no mandatory human review, full logging.
Medium risk (business logic, integrations): human review of intent and test evidence, with the agent’s summary as input.
High risk (authentication, permissions, data flows across trust boundaries, anything regulated): line-level review by a named person, the way it has always been.

What decides the tier has to be a rule, not a gut feeling. Anthropic models this in the review tool, and you can model it in branch protection rules, CODEOWNERS files or a Power Automate approval flow. The rule itself is the control that an auditor will want to see.

I would be careful with one part of the Anthropic approach: moving checks after the merge. For an internal developer platform that is a reasonable trade. For a system in a KRITIS environment where a faulty change can reach production directly, I wouldn’t do it. The safeguard has to sit before deployment, even if it no longer sits before the merge.

Every agent needs an identity and an owner

Anthropic built access control into Scion from day one, down to the directory level. In Microsoft 365 the equivalent is the identity layer for agents. Microsoft Entra Agent ID gives agents their own identities in the directory, created from agent identity blueprints. Every agent identity requires a human sponsor who is accountable for purpose, lifecycle and access reviews. If the sponsor leaves, sponsorship transfers to their manager. Conditional Access and access packages from entitlement management apply to agents as well (Microsoft Learn). As of October 2026, identity governance for agents is labeled preview, and the licensing depends on Microsoft 365 E7 or Agent 365 licenses; check the current terms before you plan with it.

On top of that, Microsoft Agent 365 provides the registry as one inventory of Microsoft and non-Microsoft agents, including counts of agents without owners (Microsoft Learn). I described the governance side in more detail in the post on the agent lifecycle.

The strategic point: an agent that runs under a shared service account or a person’s delegated credentials cannot be distinguished in the audit log, cannot be throttled separately and cannot be billed separately. Fixing that later for hundreds of agents is the kind of project nobody wants to fund.

Measuring agent work

The budget side breaks in the same way. Controlling in most IT organizations still calculates in person-days, and that model has no line for agent work. A practical way to close the gap is to route agent sessions through an AI gateway, so that every token and every hour of runtime can be assigned to a project and a repository and priced at real cost.

A feature that needed 20 days last year and 3 days of review plus agent runtime this year doesn’t fit that model. Counting agent hours is a start, but hours are an input metric. What you want to know is the cost per accepted change: tokens and runtime plus the human time for review, rework and the cases where someone had to say “no”. Without the human share, agent work looks cheaper than it is.

For Microsoft agents, Agent 365 observability collects activity data and is meant to support business metrics like usage and time savings (Microsoft Learn). That covers part of the picture. Coding agents outside Microsoft 365 need their own attribution, and that is where the gateway approach comes in.

Decisions for the next twelve months

Anthropic expects other organizations to run into this class of problem within the next six to twelve months. Even if your timeline is longer, these are the decisions I would make now:

Inventory human-paced controls. List every approval, review and pipeline step that assumes a person and a working day. Mark which ones would break at ten times the volume.
Introduce risk tiers for changes. Write down which changes need a human, which need a human for intent only and which need logging only. Make the rule machine-readable.
Give agents their own identities. No shared service accounts, every agent with a sponsor, permissions through access packages with an expiry date.
Design integrations for machine clients. Delta queries, change notifications and API budgets instead of polling and scraping.
Attribute agent cost. Tokens and runtime per project, plus the human review time, from the first productive agent onward.

What I wouldn’t do is copy Anthropic’s tooling. Their problem was 25 million checkouts a day. Yours is more likely a change process that takes two weeks for a configuration change an agent prepared in ten minutes. That is the place to start.

References

Anthropic Engineering: Redesigning source control at Anthropic (October 13, 2026)
Microsoft Learn: Microsoft Graph throttling guidance
Microsoft Learn: Avoid getting throttled or blocked in SharePoint Online
Microsoft Learn: Governing agent identities
Microsoft Learn: Manage agent registry in Microsoft 365 admin center
Microsoft Learn: Agent 365 observability
EUR-Lex: Directive (EU) 2022/2555 (NIS2), Article 21

Which Copilot Feature for Which Job: A Four-Level Map With Agent Governance

Mon, 12 Oct 2026 07:00:00 +0200

Copilot Chat, Copilot in Word, Agent Builder, SharePoint agents, Copilot Studio, Cowork: that’s just the list for this quarter. Every month brings another entry point, and every new one gets the same question from users and stakeholders: “So should we use this now instead?” Answering it means knowing which tool fits which job, and keeping the agents you build from turning into the next generation of orphaned Power Automate flows.

TL;DR

Think of Copilot as four levels: ad hoc chat → Copilot inside the apps → agents → Copilot Studio and Cowork-style automation.

Four questions decide the level: Does it happen more than once a week? Does it use the same sources or tone every time? Is it rule-based? Does it span multiple systems and approvals? More “yes” answers mean a higher level.

The higher you go, the more governance you need, but one rule applies on every level: no agent without an owner. As of October 2026, the Agent 365 registry in the Microsoft 365 admin center shows you which agents are missing one.

A quick note on names

Microsoft has renamed things again: Microsoft 365 Copilot is now Microsoft Copilot, and Microsoft 365 Copilot Chat is now Microsoft Copilot Chat, with the app moving to copilot.cloud.microsoft. Licences, portals and docs will show both names for a while. I’m using the new names below. If your users are confused, that’s one more reason to give them a map instead of a product list.

The map: four levels

The idea comes from Patrick Kelbch’s session at M365 Con D-A-CH, and I like it because it organises things by the kind of work, not by product. Here’s how I’d fill it in with what’s actually available today:

Level	What it is	Typical job	Licence / cost (simplified)	Who governs it
1 – Chat	Copilot Chat in the Copilot app, Edge, Teams, Outlook	Ad hoc questions, drafting, summarising something you paste or upload	Included with eligible Microsoft 365 plans (web-grounded); work-grounded chat needs a Copilot licence	Copilot settings in the Microsoft 365 admin center
2 – In the apps	Copilot inside Word, Excel, PowerPoint, Outlook, Teams	Meeting recap, inbox triage, first PowerPoint draft from a document	Basic in-app features for eligible users; the full experience with a Microsoft Copilot licence	Same as above, plus your data foundation (permissions, labels)
3 – Agents	Agent Builder agents, SharePoint agents, agents from the Agent Store	A reusable assistant with fixed instructions and knowledge, e.g. a project FAQ	Included with a Copilot licence; without one via pay-as-you-go (web-only agents are free)	Agent registry in the Microsoft 365 admin center
4 – Automation	Copilot Studio agents (flows, triggers, autonomy) and Copilot Cowork	Multi-step processes across systems, with approvals	Copilot Studio: Copilot licence or Copilot Credits; Cowork: Copilot licence plus usage-based billing	Power Platform admin center + Agent 365 + Cost Management

The line between level 1 and 2 is now drawn by licensing more than by technology. Users without a Copilot licence get basic Copilot features in Word, Excel and PowerPoint, and Copilot Chat in Outlook and Teams can work with the content you have open. For users, it all looks like “Copilot in the app”. For you, the difference matters because it decides whether Copilot can reach into their mailbox, chats and files by itself, or only sees what they hand it.

Level 4 has two very different branches. Copilot Studio is process-centric: a maker builds an agent with topics, agent flows and event triggers, and it runs for many users, sometimes without anyone prompting it. Cowork is person-centric: a user delegates an outcome (“prepare the steering committee pack from last week’s mails and the project site”), Cowork plans the steps, works across Outlook, Teams, OneDrive and SharePoint, and asks for approval before sensitive actions. Microsoft calls Cowork an agentic system rather than an agent, and it’s governed through spending policies rather than the agent registry.

Four questions to find the right level

When a new use case or a new feature shows up, run it through four questions:

Does it happen more than once a week? If not, stay on level 1 or 2. Building something reusable for a one-off is overkill.
Does it use the same sources or the same tone every time? If yes, you’re looking at an agent (level 3): instructions plus a fixed knowledge base beat re-typing the same prompt.
Is it rule-based? If the steps are predictable (“when X arrives, check Y, then do Z”), you want deterministic logic: a Copilot Studio agent with topics or agent flows (level 4).
Does it span multiple systems and need approvals? Then you need level 4 with real process design: connectors, human-in-the-loop steps, and someone thinking about the credentials the agent runs with.

The more “yes” answers, the higher you climb. If you can’t answer yes, don’t climb: an agent nobody uses still has to be inventoried, reviewed and eventually retired.

I’d add one question of my own, and it’s the first one I ask in regulated environments: who will own this when it breaks? If nobody raises their hand, the use case stays on level 1 or 2, however good the idea is.

Governance per level, and an owner for every agent

On levels 1 and 2, governance is mostly about your data foundation: oversharing, sensitivity labels, permissions. Copilot only shows users what they can already access, which is exactly why messy permissions show up the moment Copilot is switched on.

From level 3 upward, you’re managing objects that live on: agents with knowledge, actions and sometimes their own identity. The session had a checklist for these; here’s how each item maps to current tooling:

An owner for every agent. The agent registry in the Microsoft 365 admin center (Agents > All agents > Registry) lists agents across platforms (Copilot Studio, Agent Builder, partner and Microsoft agents) and shows Agents without owners as a top-level number. Viewing the inventory doesn’t need an extra licence, only the right role; AI Reader is the least-privileged option. Assigning a new owner requires AI Administrator (or Global Administrator).

Owner vs. sponsor. For agents with a Microsoft Entra Agent ID, Entra separates two roles: the owner handles technical operations, while the sponsor is the business person accountable for whether the agent should still exist and what access it gets. Every agent identity needs at least one sponsor, and if a sponsor leaves the organisation, sponsorship transfers automatically to their manager. Use both roles. “IT built it” is not the same as “the business needs it”.

Approval for actions. Cowork asks for approval before sensitive actions. In Copilot Studio, you design it yourself: human-in-the-loop steps in agent flows for anything high-impact or irreversible. One detail worth knowing: event triggers in Copilot Studio authenticate with the maker’s credentials, so users of a published agent may reach data through the maker’s access. Least privilege applies to makers too.

One registry. Microsoft is converging the agent views from Entra and the Microsoft 365 admin center into Agent 365, so you end up with one inventory instead of three. Agents from other platforms can be synced into the registry as well.

Entra ID sprawl under control. Every agent with its own identity adds objects to your directory: blueprints, agent identities, possibly agent users. Treat them like any other non-human identity: Conditional Access, access packages with expiry, and lifecycle workflows that catch sponsor changes.

Lifecycle, licensing and cost. Agents can be blocked, deleted (with a 30-day recovery window) and reassigned from the admin center. On the cost side, Cowork and other usage-billed experiences run on Copilot Credits and are managed under Copilot > Cost Management.

A quick inventory with Microsoft Graph

If you want the registry in a script, for a monthly report or a review with the business, there’s a Package Management API in Microsoft Graph. It’s available on v1.0, needs CopilotPackages.Read.All (delegated or application), and requires a Microsoft Agent 365 licence.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# Requires: Microsoft.Graph.Authentication, permission CopilotPackages.Read.All
Connect-MgGraph -Scopes "CopilotPackages.Read.All" -NoWelcome

# Only packages that surface in Copilot, i.e. agents
$uri = "https://graph.microsoft.com/v1.0/copilot/admin/catalog/packages?`$filter=supportedHosts/any(h:h eq 'Copilot')"
$agents = while ($uri) {
 $page = Invoke-MgGraphRequest -Method GET -Uri $uri
 $page.value
 $uri = $page.'@odata.nextLink' # follow paging until no nextLink is returned
}

$agents |
 Select-Object displayName, type, platform, publisher, isBlocked, availableTo, deployedTo, lastModifiedDateTime |
 Sort-Object lastModifiedDateTime |
 Export-Csv -Path .\agent-inventory.csv -NoTypeInformation -Encoding utf8

Sorting by lastModifiedDateTime is a cheap first lifecycle check: agents that haven’t changed in a year are the first ones to review. For ownership, the Agents without owners view in the admin center is still the quickest way in.

Things to watch out for

A spending policy is an access control as well as a budget. For Cowork, anyone in scope of a policy that selects Cowork gets access, even if the limit is a single credit. To keep someone out, keep them out of the policy.
“Auto-apply new services” is on by default in spending policies. New usage-billed services can be covered automatically. If you’d rather review every new service first (a reasonable stance under NIS2-style change control), switch it off.
Set per-user limits. Otherwise one enthusiastic user can use up the whole month’s credits.
Agent 365 licensing is tiered. The registry inventory and basic actions (block, delete, reassign owner) come with Microsoft 365 Enterprise, Business, Education and Frontline plans. Policy templates, observability, tenant-wide tool control and the Graph API need Microsoft 365 E7 or Agent 365. Check the service description before you promise a feature.
Names and admin paths keep moving. The rename to Microsoft Copilot is recent; screenshots in your internal docs will be out of date sooner than you think.

Wrap-up

Build the map once, then place every new Copilot feature on it instead of debating it from scratch. Use the four questions to decide how high a use case should go, and be strict about the extra one: if nobody owns it, it doesn’t get built. For the agents you already have, the registry shows you exactly where an owner is missing.

Which level are most of your users on today, and how many agents in your registry are already missing an owner?

References

Inspired by a post from Marcel Broschk on LinkedIn summarising the session “Copilot everywhere: Chat, Agents, Automatisierung: wie finde ich mich noch zurecht?” by Patrick Kelbch at M365 Con D-A-CH.