Perform basic administrative tasks for Copilot and agents
Agent Approval, Access, Monitoring, and Lifecycle
Govern who can use agents, how requests become published experiences, which inventory answers each question, and how agents are monitored, updated, blocked, transferred, or retired.
What you need to know
- User access has layers: the user must be entitled or metered where required, allowed to access the agent, able to access the agent artifact/channel, and authorized to every knowledge source and action. Scoping the agent to Finance does not remove non-Finance users from a broadly shared source.
- A maker can create and sometimes share an agent under maker policy. Making an agent broadly discoverable in the organization can require submission and administrator approval. The administrator reviews purpose, owner, data sources, tools/actions, requested permissions, protection, audience, and publisher trust.
- The requests view supports pending review, update, or activation scenarios depending on agent type. An administrator can reject or publish/activate and scope the audience to selected users/groups or everyone. A material update—especially new data or write actions—needs fresh review.
- The Microsoft 365 admin center Agent Registry, now also described in current Microsoft Agent 365 material as the Agent 365 registry, focuses on agents available in the tenant, requests, access, status, metadata, ownership, and usage/operational information.
- Power Platform inventory shows agents built on Power Platform, including Copilot Studio and Microsoft 365 Copilot Agent Builder resources, across environments and can include drafts. It helps find owners, orphaned agents, connectors, environments, and resources that are not yet available in the Microsoft 365 catalog.
- Counts differ by design: the Microsoft 365 catalog includes first-party, third-party, and organization-published/shared agents available to users, while Power Platform inventory focuses on Power Platform-built resources and includes drafts but not every other-source agent.
- Monitoring includes usage/adoption, status, errors or operational insights where available, owner and audience, connector/source changes, risk/security signals, and business purpose. Low use can indicate poor discoverability or low value; high use can increase the need for reliability and data review.
- Lifecycle actions include approve/publish, assign audience, update/reapprove, block, remove, transfer ownership, and retire. Agents that are unsafe, obsolete, ownerless, unsupported, or no longer justified should be blocked or retired according to policy.
How it works
- Maker builds/tests → shares within allowed scope or submits for organization publication → administrator reviews metadata/data/tools/permissions/audience → publishes or rejects → organization monitors → update is reviewed → agent is blocked, transferred, or retired when needed.
- Agent Registry answers “What is available/requested in the tenant and who can use it?” Power Platform inventory answers “What Power Platform-built resources exist across environments, including drafts, owners, and connectors?”
- Blocking changes agent availability; source permissions remain separate and may need remediation. Removing an agent from the catalog does not automatically delete every source, connector, or Power Platform draft.
Compare and distinguish
- Creation vs sharing vs organizational publication: produce a draft vs allow selected use vs make available through an approved tenant audience/catalog.
- Agent approval vs source access: governance approval for the package/audience vs each user’s authorization to knowledge and actions.
- Agent Registry/Agent 365 registry vs Power Platform inventory: tenant available/requested catalog vs Power Platform-built environment inventory including drafts.
- Block vs remove vs retire: make unavailable immediately vs remove a catalog/deployment artifact vs planned end-of-life including ownership/data/dependency handling.
- Usage insight vs operational insight: whether/how much people use an agent vs health, errors, behavior, or runtime signals.
- Prior approval vs update approval: trust in the reviewed version vs fresh review of changed data, permissions, tools, or behavior.
Objects and administrative surfaces
- Agent Registry/Agent 365 registry, Requests, All agents, audience/access, status, publisher, data/tools/permissions, usage and operational insights — Microsoft 365 admin center.
- Inventory, environments, owners, drafts, connectors, regions, resource status, and organization-built agents — Power Platform admin center.
- Detailed authoring, testing, analytics, connector/action configuration, and versions — Copilot Studio.
- Identity groups and Conditional Access — Entra; source permissions — SharePoint/workloads; data/security evidence — Purview and Defender.
Scenario examples
- Scenario: A finance agent is approved only for a pilot — reasoning: scope the agent audience to the pilot group and separately verify source permissions.
- Scenario: An update adds a connector that creates external records — reasoning: review the new data flow, action, permission, audience, and failure impact before approving it.
- Scenario: An administrator needs unpublished Copilot Studio drafts owned by a departing employee — reasoning: filter Power Platform inventory by owner/resource type.
- Scenario: A security defect requires an agent to be unavailable now — reasoning: block the agent, preserve evidence, remediate source/action risk, and reapprove before return.
- Scenario: Registry and Power Platform counts differ — reasoning: clarify whether the request is all available tenant agents or Power Platform-built resources including drafts.
When to use it
- Use Microsoft 365 admin center to review requests, publish to a scoped audience, control availability, and inspect the tenant’s available agent catalog.
- Use Power Platform inventory to find drafts, ownerless resources, environments, connectors, and Power Platform-built agent counts.
- Block immediately when an active agent presents unacceptable risk; transfer or retire when ownership/business purpose changes; review material updates before release.
Security and governance implications
- Require accountable owners, backup ownership, least-privileged sources/actions, documented audience, review dates, and retirement criteria.
- Use a limited pilot, monitor use and failures, review high-impact actions and data sources, and reapprove material updates.
- Coordinate Agent Registry, Power Platform, Entra, Purview, Defender, and source-workload evidence rather than expecting one inventory to answer every risk question.
Troubleshooting signals
- Agent unavailable: check entitlement/metering, tenant agent settings, approval/publication status, block state, audience/group membership, channel, source/action permission, and service health.
- Inventory mismatch: identify which agent origins/states are included, whether drafts and first/third-party agents count, environment/tenant scope, filters, and refresh delay.
- Owner departure: locate published and draft resources, identify dependencies/connectors, transfer useful agents to accountable owners, and retire the rest.
- Operational issue: inspect usage/operational insight, recent version/source/connector change, runtime error, permission, and downstream service before republishing.
Exam traps
- Publishing to a group does not grant that group access to every knowledge source or connector.
- A draft may appear in Power Platform inventory but not the Microsoft 365 available-agent catalog.
- Approval does not certify every future response or automatically approve every update.
- Blocking an agent does not repair an overshared source, and deleting a billing assignment is not the same as retirement.
- Agent Registry and Power Platform inventory counts are both valid within different scopes.
Key takeaways
- Create/test → share or submit → review → publish to scope → monitor → update/reapprove → block/transfer/retire.
- Microsoft 365 registry = available/requested tenant catalog; Power Platform inventory = organization-built environment resources and drafts.
- Agent audience, source access, actions, ownership, and lifecycle remain separate governance questions.
Related objectives
- D3.3.a
- D3.3.c
- D3.3.d