This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure compute (20–25%)
--> Implement security for AI
--> Manage agents in Microsoft 365 admin center
Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.
Overview
AI agents can perform tasks, retrieve information, interact with users, call tools, and access organizational data. As organizations deploy more agents, security teams need a consistent way to discover, approve, deploy, monitor, restrict, and retire them.
The Microsoft 365 admin center provides centralized agent-management capabilities through the Agent workload, including the Agent overview, Agent Registry, Requests, and Agent settings.
For the SC-500 exam, the important concept is that Microsoft 365 admin center acts as a governance and management control plane for agents across the organization. It helps administrators answer:
- Which agents exist in the tenant?
- Who owns each agent?
- Which agents are available, installed, blocked, or at risk?
- Which agents are using organizational data or tools?
- Which agents require approval?
- Which users or groups can access an agent?
- Which agents should be retired or removed?
Agent governance is intended to provide consistent control throughout the agent lifecycle, from creation and approval through deployment, monitoring, and retirement.
What Is Agent Management in Microsoft 365 Admin Center?
Agent management is the process of controlling the availability, access, configuration, ownership, distribution, and lifecycle of AI agents.
The Microsoft 365 admin center provides a centralized view of agents from several sources, including:
- Microsoft Copilot Studio
- Microsoft 365 Copilot
- Agent Builder
- Microsoft Foundry
- Agents Toolkit
- SharePoint
- Other Microsoft agent experiences
- Supported external or third-party agent platforms
The Agent workload helps administrators:
- Discover agents in the tenant
- Review agent owners and publishers
- Control agent availability
- Approve or reject agent requests
- Install or uninstall agents
- Block or unblock agents
- Pin agents for users or groups
- Assign ownership
- Investigate agents at risk
- Review agent usage and governance information
- Apply lifecycle-management rules
The registry is not limited to agents created directly by a single Microsoft product. It is designed to provide a broader inventory of agents available to the organization.
The Agent Workload
The Agent workload is the central administrative experience for agent governance.
It provides visibility into the agent ecosystem and supports decisions about:
- Adoption
- Security
- Compliance
- Ownership
- Access
- Distribution
- Lifecycle management
The Agent workload should be viewed as a governance control plane rather than as the place where every agent is built or developed.
For example:
- An agent may be created in Copilot Studio.
- A model or hosted agent may be created in Microsoft Foundry.
- An agent may be shared by an employee.
- An administrator may review and govern the agent through Microsoft 365 admin center.
The agent’s development platform and its administrative control plane may therefore be different.
Agent Overview
The Agent overview provides a high-level summary of agent activity and governance conditions in the tenant.
It can include:
- Total agents
- Active users
- Agent usage trends
- Agent adoption information
- Pending requests
- Agents without owners
- Agents at risk
- Agents with exceptions
- Governance actions requiring administrator attention
The overview generally focuses on recent activity, including a snapshot of activity and actionable insights for the last 30 days. The overview may show only the most-used platforms in some summary cards; the Registry provides a more complete inventory view.
Why the overview matters
The overview helps administrators identify governance issues without manually inspecting every agent.
For example, it may reveal:
- A growing number of agents with no assigned owner
- A large number of pending publication requests
- Agents with security or compliance concerns
- Agents that are widely used but lack appropriate governance
- Agents with operational exceptions
The overview is useful for prioritization, but administrators should open the relevant Registry or request view to investigate and take action.
Agent Registry
The Agent Registry provides a centralized list of agents available to the organization.
To access it, an administrator generally navigates to:
Microsoft 365 admin center → Agents → All agents → Registry
The registry can be used to:
- View agents
- Filter agents
- Open agent details
- Review ownership
- Review status
- Manage availability
- Install or uninstall agents
- Block or unblock agents
- Pin agents
- Assign owners
- Investigate agents at risk
- Export agent information
The registry also supports different agent categories.
Agent types
Common agent categories include:
| Agent type | Description |
|---|---|
| Microsoft agents | Agents built and maintained by Microsoft |
| External partner-built agents | Agents built by trusted external developers |
| Published by your organization | Custom agents approved and published by the organization |
| Shared by creator | Agents created and shared by users or developers in the organization |
The exact labels and supported agent types may evolve as Microsoft expands Agent 365 and the Microsoft 365 agent ecosystem.
Agent Details
Selecting an agent in the Registry opens an agent-details pane.
Depending on the agent type, the details may include:
- Agent name
- Description
- Publisher
- Owner
- Agent type
- Status
- Availability
- Users
- Data sources
- Tools
- Security information
- Connected agents
- Instances
- Available administrative actions
The available tabs and information may vary by agent.
For example, an agent that connects to other agents may display a Connected Agents tab. An agent that supports multiple instances may display an Instances tab.
Agent details help administrators determine whether an agent is appropriate for organizational use and whether it has the correct ownership, permissions, data access, and deployment scope.
Agent Requests
Agent requests provide a controlled approval process for agents that require administrative review before becoming available to users.
Requests may include:
- Pending review
- Pending update
- Pending activation
When a user or developer publishes an agent to the organization, an administrator can review details such as:
- Agent description
- Agent owner
- Data sources
- Tools
- Requested permissions
- Intended audience
- Deployment scope
- Security and compliance considerations
The administrator can then:
- Publish the agent to the organization
- Scope it to selected users or groups
- Apply required protection policies
- Grant required permissions
- Reject the submission
The approval process helps prevent uncontrolled deployment of agents that may access sensitive data or perform consequential actions.
Publish versus reject
Publish to store makes the requested agent available to the intended audience.
Reject submission prevents the requested agent from becoming available through the organization’s agent store.
Publishing an agent does not necessarily mean that every user receives access. Administrators may limit the audience to specific users or groups.
Installing Agents
Administrators can install an agent for:
- The entire organization
- Specific users
- Specific groups
A typical installation workflow is:
- Open the Microsoft 365 admin center.
- Select Agents → All agents.
- Select the Registry tab.
- Filter for available agents.
- Select the agent.
- Select Install.
- Choose all users or selected users and groups.
- Review requested permissions.
- Grant administrator consent if required.
- Complete the deployment.
Installing an agent can affect its availability in Microsoft 365 Copilot and supported host applications such as Teams, Outlook, Word, Excel, or PowerPoint.
Administrators should review requested permissions before granting consent. The fact that an agent is available in the catalog does not automatically mean that its requested permissions are appropriate for every user or business scenario.
Blocking and Unblocking Agents
Administrators can block an agent when it should not be used in the organization.
Reasons to block an agent may include:
- Security concerns
- Excessive permissions
- Unapproved data access
- Inappropriate functionality
- Compliance concerns
- Malicious or suspicious behavior
- Unsupported external publisher
- An agent that no longer meets organizational requirements
Blocking an agent restricts access to it across the organization.
Unblocking restores access, subject to other applicable policies and assignments.
Blocking is different from deleting:
- Block: Prevents use while retaining the agent in the inventory.
- Delete: Removes the agent and associated files, where supported.
Administrators should generally investigate and preserve relevant information before deleting an agent associated with a security incident.
Deleting Agents
The delete action permanently removes an agent from the inventory and deletes associated files, where applicable.
Deletion should be used carefully because it is a lifecycle action rather than merely an access restriction.
Before deleting an agent, administrators should consider:
- Whether the agent is still used
- Whether it has dependent workflows
- Whether it is connected to other agents
- Whether it owns or references data
- Whether audit or investigation information must be retained
- Whether the agent should be blocked instead
- Whether the owner or development team needs to be notified
A useful governance practice is to block or quarantine a risky agent first, investigate it, and delete it only when the organization has determined that deletion is appropriate.
Agent Ownership
Every active agent should have a responsible owner.
An owner is accountable for:
- Maintaining the agent
- Reviewing its permissions
- Managing its data sources
- Updating its instructions
- Reviewing security and compliance requirements
- Responding to incidents
- Retiring the agent when it is no longer needed
The Agent overview and Registry can identify agents without owners.
Administrators can assign a new owner to ownerless or active agents. For Agent Builder agents, administrators may also add or remove owners under the supported ownership rules.
Ownerless agents create security and operational risks because no individual or team is clearly responsible for:
- Access reviews
- Security updates
- Data-source changes
- Incident response
- Cost management
- Retirement decisions
Ownership is therefore a major part of agent lifecycle governance.
Agents at Risk
The Registry can identify agents at risk.
An agent may be considered risky because of issues involving:
- Security
- Compliance
- Permissions
- Data access
- Ownership
- Configuration
- Exposure
- Operational behavior
Administrators should investigate agents at risk and determine whether to:
- Correct the configuration
- Restrict access
- Assign an owner
- Apply a policy
- Block the agent
- Remove the agent
The exact risk signals depend on the agent type and the integrated governance capabilities.
Agent Instances
Some agents can have multiple instances created by users after an administrator activates the agent.
The Agent Registry can show the number of instances associated with an agent. Administrators can open the agent details and select the Instances tab to review individual instances.
Instance management can include:
- Viewing instances
- Managing individual instance settings
- Reviewing security status
- Reviewing compliance status
- Blocking instances
- Deleting instances
This distinction is important:
- The agent is the published or available agent definition.
- An agent instance is a user-created or deployed instance based on that agent.
Managing the parent agent does not always provide the same level of control as reviewing individual instances. Administrators should understand whether a security issue affects the agent definition, one instance, or multiple instances.
Pinning Agents
Administrators can pin an agent so that it appears in the agent list within Microsoft 365 Copilot.
Pinned agents can be targeted to:
- Everyone in the organization
- Specific users
- Specific groups
Administrators can:
- Pin an agent
- Unpin an agent
- Change the audience
- Rank pinned agents
Pinning improves discoverability and encourages users to use approved agents.
However, pinning is primarily a distribution and visibility control. It does not replace:
- Identity controls
- Data permissions
- Agent security policies
- Content filtering
- Network controls
- Compliance policies
- Least-privilege access
After an agent is pinned, it may take several hours before end users see the change.
Agent Settings
The Agent settings page provides tenant-wide controls for agent governance.
Common settings include:
- Agent management rules
- Allowed agent types
- Policy templates
- Sharing
- User access
- Agent feedback sharing
- Tags
These settings help administrators establish consistent policies instead of managing every agent independently.
Allowed Agent Types
The Allowed agent types setting controls which categories of agents users can view and install from the agent catalog.
Common categories include:
- Apps and agents built by Microsoft
- Apps and agents built by the organization
- Apps and agents built by external publishers
Disabling an agent type can prevent users from installing agents in that category.
Some Microsoft-built agents may remain visible even when the corresponding setting is disabled, but users may be prevented from installing them.
This setting is useful when an organization wants to:
- Allow only Microsoft-built agents
- Allow Microsoft-built and internally developed agents
- Restrict external agents
- Reduce exposure to third-party data-handling practices
- Apply a controlled adoption strategy
Allowing an agent type does not automatically grant the agent access to all organizational data. Data access remains governed by the agent’s permissions and the underlying services.
User Access
The User access setting controls which users or groups can access agents.
Typical options include:
- All users
- No users
- Specific users or groups
The default option may allow all users to access agents, subject to existing application policies and assignments.
Selecting specific users or groups is useful when an organization wants to:
- Pilot an agent
- Restrict access to a business unit
- Limit access to trained users
- Control licensing or consumption costs
- Test an agent before broad deployment
- Reduce the risk of exposing sensitive capabilities
User access settings should be considered together with:
- Microsoft Entra groups
- Application policies
- Agent permissions
- Data-source permissions
- Licensing
- Regulatory requirements
A user who can access an agent is not necessarily authorized to access every data source that the agent can reach.
Sharing Controls
Sharing settings determine who can share agents and how agents can be shared within the organization.
Sharing controls can help prevent uncontrolled distribution of agents that:
- Use sensitive data
- Call external tools
- Perform business actions
- Have not been reviewed
- Have unclear ownership
- Have excessive permissions
Organizations should define whether users can share agents broadly or only with approved groups.
Policy Templates
Policy templates provide predefined security and governance settings that can be applied consistently to agents.
Templates can help standardize:
- Security requirements
- Compliance controls
- Allow lists
- Access rules
- Deployment expectations
- Protection settings
Using templates reduces configuration drift and helps ensure that newly onboarded agents follow the organization’s baseline requirements.
Templates should complement, not replace, detailed review of an agent’s:
- Data sources
- Tools
- Permissions
- Instructions
- External connections
- Intended business purpose
Agent Management Rules
Agent management rules allow administrators to identify agents that meet specified conditions and apply governance actions in bulk.
Instead of manually reviewing every agent, administrators can create rules that:
- Identify agents matching defined conditions.
- Review the affected agents.
- Apply a supported action to the matching agents.
Examples of supported scenarios include:
- Installing Microsoft-built agents
- Reassigning ownerless Agent Builder agents to a manager
- Blocking ownerless agents without usage
- Rejecting old agent publication requests
Rules-based management is useful for enforcing lifecycle policies at scale.
For example, an organization may decide that:
- Every active agent must have an owner.
- Unused ownerless agents should be blocked.
- Publication requests older than a defined period should be rejected.
- Approved Microsoft agents should be installed for a specific audience.
Rules should be reviewed carefully before execution to avoid unintentionally affecting business-critical agents.
Roles and Permissions
Agent management capabilities are controlled through Microsoft Entra administrative roles.
Important roles include:
| Role | Typical capability |
|---|---|
| Global Administrator | Broad tenant-wide visibility and management |
| AI Administrator | Tenant-wide agent governance and management |
| Global Reader | Read-only access to supported information |
| AI Reader | Read-only agent information |
| Security Administrator | Security-related administrative visibility, without all agent-management actions |
| Security Reader | Read-only security visibility |
| Reports Reader | Reporting and usage visibility |
The Global Administrator and AI Administrator roles have broad agent-management authority.
Other roles may be able to view agent information but may not be able to:
- Approve requests
- Install agents
- Modify agent configuration
- Assign ownership
- Block or delete agents
Organizations should follow least privilege and assign the smallest role that supports the required task. Global Administrator should not be used for routine agent administration when a more specific role is sufficient.
Security and Compliance Considerations
Managing agents is not limited to whether an agent is installed.
Security teams should evaluate the entire agent capability chain:
- User identity
- Agent identity
- Agent instructions
- Connected data
- Tools and APIs
- Permissions
- Network access
- External publishers
- Logging and auditing
- Lifecycle ownership
Data access
An agent should have access only to the data required for its purpose.
Administrators should review:
- Data sources
- SharePoint sites
- Microsoft Graph permissions
- Databases
- Storage accounts
- Search indexes
- External APIs
- Connected agents
Tool access
Tools can allow agents to perform actions rather than simply provide information.
Examples include:
- Sending email
- Creating records
- Updating files
- Calling APIs
- Modifying tickets
- Executing workflows
Agents that perform consequential actions require more rigorous review than read-only agents.
External agents
External agents may process data under terms that differ from Microsoft’s agreements. Organizations should review:
- Publisher trust
- Data handling
- Privacy terms
- Data residency
- Security controls
- Compliance requirements
- External network access
Auditing
Administrative actions performed through Microsoft agent experiences may be recorded in the relevant workload audit logs, such as Microsoft 365, Microsoft Entra, or Teams audit logs.
Auditing helps organizations investigate:
- Who installed an agent
- Who changed its configuration
- Who approved a request
- Who blocked or deleted an agent
- Which administrative action occurred
- When the action occurred
Recommended Agent Governance Lifecycle
A mature governance process can follow these stages.
1. Discover
Identify agents across supported platforms and external sources.
2. Classify
Classify agents according to:
- Business purpose
- Data sensitivity
- Publisher
- Risk
- Required permissions
- Intended audience
- Whether the agent performs actions
3. Review
Review:
- Owner
- Data sources
- Tools
- Permissions
- External connections
- Security policies
- Compliance requirements
4. Approve
Approve only agents that meet organizational requirements.
Scope access to the smallest appropriate audience.
5. Deploy
Install or publish the agent for approved users or groups.
Use pinning when appropriate to improve discoverability.
6. Monitor
Review:
- Usage
- Agents at risk
- Exceptions
- Ownership
- Security findings
- Permission changes
- User feedback
7. Remediate
Correct issues, restrict access, assign ownership, or block the agent.
8. Retire
Uninstall or delete agents that are no longer needed, while preserving required audit and investigation information.
Common Exam Distinctions
Agent Registry versus Agent overview
- Agent overview: High-level metrics, trends, and governance actions.
- Agent Registry: Detailed inventory and administrative actions.
Publish versus install
- Publish: Makes an agent available through the organization’s agent store.
- Install: Deploys an agent for all users or selected users and groups.
Block versus delete
- Block: Prevents use while retaining the agent.
- Delete: Removes the agent and associated files where supported.
Agent versus agent instance
- Agent: The available agent definition.
- Agent instance: A user-created or deployed instance of that agent.
Visibility versus permission
Seeing an agent in the catalog does not mean the user has access to all data or tools used by the agent.
Pinning versus securing
Pinning controls discoverability and distribution. It does not replace identity, data, network, or application security controls.
Key Takeaways
For the SC-500 exam, remember:
- Microsoft 365 admin center provides centralized governance for agents.
- The Agent Registry is the primary inventory and management experience.
- The Agent overview provides usage and governance summaries.
- Agent requests support approval, publication, and rejection workflows.
- Administrators can install, uninstall, block, unblock, pin, and delete agents.
- Ownership is essential for accountability and lifecycle management.
- Agents at risk and ownerless agents should be investigated promptly.
- Agent instances may require separate management from the parent agent.
- Agent settings control allowed agent types, sharing, user access, templates, and management rules.
- AI Administrator and Global Administrator have broad tenant-wide agent-management authority.
- Least privilege should be used when assigning administrative roles.
- Agent governance must consider data, tools, permissions, external publishers, auditing, and retirement.
Practice Exam Questions
Question 1
Which Microsoft 365 admin center feature provides a centralized inventory of agents available to an organization?
A. Agent Registry
B. Microsoft Purview Data Map
C. Microsoft Sentinel workbook
D. Azure Resource Graph
Correct answer: A
Explanation: The Agent Registry provides a centralized view of agents available to the organization and supports actions such as reviewing details, installing, blocking, pinning, and assigning ownership.
Question 2
An organization wants to review pending agent submissions before making them available to users. Which area should the administrator use?
A. Agent analytics
B. Agent Requests
C. Microsoft Entra Connect
D. Azure Policy
Correct answer: B
Explanation: Agent Requests provides workflows for reviewing, publishing, or rejecting pending agent submissions and updates.
Question 3
What is the primary purpose of assigning an owner to an agent?
A. To increase the agent’s model accuracy
B. To make the agent available to every user
C. To establish accountability for maintenance, security, and lifecycle management
D. To bypass the need for administrator approval
Correct answer: C
Explanation: An owner is responsible for maintaining the agent, reviewing its permissions and data sources, responding to issues, and retiring it when appropriate.
Question 4
An administrator wants to prevent users from using a risky agent while preserving the agent’s inventory record for investigation. Which action should the administrator take?
A. Pin the agent
B. Delete the agent
C. Publish the agent
D. Block the agent
Correct answer: D
Explanation: Blocking prevents use while retaining the agent in the inventory. Deleting removes the agent and associated files where supported.
Question 5
Which setting controls whether users can access agents built by external publishers?
A. Allowed agent types
B. Agent feedback sharing
C. Agent ranking
D. Agent ownership
Correct answer: A
Explanation: Allowed agent types determines which categories of agents users can view and install, including Microsoft-built, organization-built, and externally published agents.
Question 6
An organization wants to allow an agent only for a pilot group before deploying it broadly. Which control is most appropriate?
A. Delete the agent
B. Configure User access for specific users or groups
C. Disable all Microsoft agents
D. Remove the agent owner
Correct answer: B
Explanation: User access can be scoped to specific users or groups, making it suitable for pilot deployments and controlled rollouts.
Question 7
What is the difference between an agent and an agent instance?
A. An agent is a security alert, while an instance is a recommendation
B. An agent is a user, while an instance is a group
C. An agent is the available definition, while an instance is a created or deployed version of that agent
D. An agent is a database, while an instance is a storage account
Correct answer: C
Explanation: The agent is the published or available agent definition. An instance is created from that agent and may require separate review or management.
Question 8
Which role provides broad tenant-wide authority to manage agents in the Microsoft 365 admin center while following the principle of least privilege?
A. AI Administrator
B. Reports Reader
C. Security Reader
D. Global Reader
Correct answer: A
Explanation: AI Administrator provides broad agent-management authority. Reports Reader, Security Reader, and Global Reader generally provide visibility but not the same management capabilities.
Question 9
An organization wants to automatically identify ownerless agents without usage and block them in bulk. Which capability should it use?
A. Agent pinning
B. Agent management rules
C. Agent feedback sharing
D. Agent Registry export
Correct answer: B
Explanation: Agent management rules can identify agents that meet defined conditions and apply supported governance actions in bulk, including blocking ownerless agents without usage.
Question 10
Which statement about pinning an agent is correct?
A. Pinning grants the agent access to all organizational data
B. Pinning disables all security policies for the agent
C. Pinning controls discoverability and distribution but does not replace security controls
D. Pinning permanently prevents the agent from being deleted
Correct answer: C
Explanation: Pinning makes an agent more visible in Microsoft 365 Copilot for selected users or groups. It does not replace permissions, identity controls, data protection, network security, or compliance policies.
Go to the SC-500 Exam Prep Hub main page
