🧠 AB-650 Course · Module 8 of 9 · Domain 3 🔥 New
Agent 365 & Agents Administration
AB-650 Exam Alignment
AB-650
Domain 3 — Administer Agent 365 and agents (completely new in AB-650): manage agent identities using Microsoft Entra Agent ID including agent lifecycle workflows; secure agent access using access packages and Conditional Access for agents; manage agent owners and agent settings; discover and manage Microsoft and third-party agents in the agent registry; publish, reject, install, block, and upload custom agents; manage tools available in Agent 365.
- Know that every agent in Agent 365 has a corresponding service principal in Microsoft Entra ID managed through Entra Agent ID
- Understand the difference between agent states in the registry: Available, Installed (user), Installed (admin-deployed), Blocked, Pending review
- Know that Conditional Access policies can target agent service principals to control when and how agents can access M365 resources
- Understand access packages (Entra Identity Governance) as the mechanism for granting users the right to install and use specific agents
Exam Tip: Agent 365 is the most unique content in AB-650 vs ALL previous Microsoft 365 certifications. Every question about agent registry management, Entra Agent ID, and agent Conditional Access is entirely new. Focus on the agent lifecycle: Register → Review → Publish/Block → Install → Monitor. This lifecycle maps directly to what AB-650 will test.
Module 8 covers the entirely new Agent 365 administration domain — the most distinctive content in AB-650 that does not exist in any previous Microsoft 365 certification. Agent 365 is Microsoft’s enterprise management layer for AI agents. As organisations deploy Copilot Studio agents, third-party agents, and Microsoft-built agents, administrators need tools to govern which agents users can access, control what data agents can reach, and manage agent identities through the same identity infrastructure used for human users.
🤖 Microsoft Entra Agent ID NEW IN AB-650
Microsoft Entra Agent ID is the identity management framework for AI agents. Every agent registered in Agent 365 is assigned a service principal in Microsoft Entra ID — giving it a managed identity that can be governed, audited, and controlled with the same tools used for application and human identities.
| Agent ID Concept | What It Is | Why It Matters for AB-650 |
|---|---|---|
| Agent service principal | An Entra ID object representing the agent — similar to a service principal for an enterprise application | Agents can be targeted by Conditional Access policies, access reviews, and audit logs just like applications |
| Agent owner | A user or group designated as responsible for the agent — receives alerts about the agent’s activity and is accountable for its use | Every agent should have an owner — agents without owners are flagged in the Agent 365 registry as ungoverned |
| Agent lifecycle states | Register → Pending review → Published/Blocked → Installed → Revoked | AB-650 tests the admin’s ability to move agents through these states in the registry |
| Agent permissions | Like app permissions, agents request access to M365 data (SharePoint, Exchange, Teams) — admins grant or deny consent | Review requested permissions before publishing an agent — agents should follow least-privilege principle |
M365 Admin Center › Copilot › Agents | Entra Admin Center › Applications › Agent ID
Copilot
Readiness
Settings
🤖 Agents
Agent registry
All agents
Microsoft agents
Third-party agents
Custom agents
Pending review
Agent Registry — All agents (24 agents)
| Agent Name | Publisher | Type | Status |
|---|---|---|---|
| SharePoint Agent | Microsoft | Built-in | ● Installed |
| ServiceNow Agent | ServiceNow | Third-party | ● Published |
| HR Onboarding Agent | Contoso IT | Custom | ● Pending review |
| CompetitorResearch | Unknown | Third-party | ● Blocked |
ⓘ Agents pending review must be approved or rejected by an admin before users can install them. Blocked agents cannot be installed by any user.
🔒 Secure Agent Access — Access Packages & Conditional Access
| Control Mechanism | What It Does | When to Use |
|---|---|---|
| Access Packages (Entitlement Management) | Bundle an agent installation right with other resources (SharePoint access, Teams membership). Users request the package, manager approves, and agent access + supporting resources are granted together automatically. | When agent access requires corresponding data access to be meaningful — e.g. “HR Advisor Agent” package includes the agent + access to HR SharePoint site |
| Agent Conditional Access | Apply Conditional Access policies targeted at agent service principals in Entra ID. Control what conditions must be met for an agent to access M365 resources — time of day, network location, risk level. | When agents should only operate within specific parameters — e.g. restrict agents to corporate network only, or require enhanced authentication for agents accessing financial data |
| Agent permissions consent | When a new agent requests permission to access M365 data (SharePoint, Exchange, Teams Graph API), an admin must grant tenant-wide consent before the agent can operate | Review carefully before granting — permissions should follow least privilege. Revoke unnecessary permissions via Entra Admin Center → Applications → Agent ID → [Agent] → Permissions |
📊 Agent Registry Administration
| Action | What It Does | Admin Location |
|---|---|---|
| Publish an agent | Makes a pending or uploaded agent available for users to install from the Agent 365 catalogue. Published agents appear in the catalogue for all licensed users. | M365 Admin Center → Copilot → Agents → [Select agent] → Publish |
| Block an agent | Prevents any user in the tenant from installing the agent. Existing installations are disabled. Use for agents that violate security policy or are not approved. | M365 Admin Center → Copilot → Agents → [Select agent] → Block |
| Admin deploy (install for all users) | Installs an agent for all users in the tenant or for specific groups — users see it in their Agent 365 without needing to manually install | M365 Admin Center → Copilot → Agents → [Select agent] → Deploy to users |
| Upload a custom agent | Upload a custom agent package (.zip containing agent manifest) built in Copilot Studio or via Teams app packaging | M365 Admin Center → Copilot → Agents → Upload agent |
| Reject a pending agent | Declines an agent submitted for review — it does not appear in the catalogue and cannot be installed. The agent developer is notified. | M365 Admin Center → Copilot → Agents → Pending review → [Select] → Reject |
🔥 Agent 365 Tools Management
Agents in Agent 365 can have access to tools — capabilities that allow the agent to take actions beyond just answering questions. Tools include: web search (agent can search the public web), file reading (agent can read files the user has access to), code interpreter (agent can run code), and custom API connectors. Administrators can manage which tools are available to agents tenant-wide via M365 Admin Center → Copilot → Agents → Tools settings. Restricting tools limits what agents can do — e.g. disabling web search for agents ensures they only use internal M365 data.
Microsoft Graph PowerShell — Agent ID & Service Principal Management
Connect-MgGraph -Scopes 'Application.Read.All','Application.ReadWrite.All' # List all agent service principals registered via Entra Agent ID Get-MgServicePrincipal -Filter "tags/any(t:t eq 'Agent365')" | Select-Object DisplayName,AppId,AccountEnabled | Format-Table -AutoSize # Get owners of a specific agent service principal Get-MgServicePrincipalOwner -ServicePrincipalId [AgentSPId] | Select-Object DisplayName,UserPrincipalName | Format-Table -AutoSize # Add an owner to the agent New-MgServicePrincipalOwnerByRef -ServicePrincipalId [AgentSPId] -BodyParameter @{'@odata.id' = "https://graph.microsoft.com/v1.0/users/$($UserId)"} # Get all permissions granted to an agent Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId [AgentSPId] | Select-Object PrincipalDisplayName,ResourceDisplayName,AppRoleId | Format-Table -AutoSize # Disable an agent service principal (block the agent globally) Update-MgServicePrincipal -ServicePrincipalId [AgentSPId] -AccountEnabled $false # Review CA policies targeting agent app IDs Get-MgIdentityConditionalAccessPolicy | Where-Object {$_.Conditions.Applications.IncludeApplications -contains [AgentAppId]} | Select-Object DisplayName,State | Format-Table -AutoSize
💡 Best Practices
- Assign an owner to every agent before publishing — agent owners receive notifications about unusual activity and are accountable if the agent causes a compliance issue
- Review all agent permission requests carefully before granting consent — agents requesting access to all SharePoint sites or all user calendars should be scrutinised before approval
- Default to “Pending review” for all new agent submissions — configure the Agent 365 registry to require admin approval before any new agent is visible to users
- Use access packages for agents that require corresponding data access — bundle the agent installation right with the minimum necessary SharePoint or Teams access
- Block unknown or unapproved agents immediately when they appear in the registry — third-party agents can appear via Microsoft AppSource integrations and should be reviewed before being available to users
- Apply Conditional Access to agent service principals to restrict when agents can access sensitive M365 resources — e.g. allow finance data agents to operate only during business hours from corporate network
🎓 Interview Q&A
Q: What is Microsoft Entra Agent ID and how does it relate to managing AI agents in Agent 365?
Microsoft Entra Agent ID is the identity management framework that assigns every AI agent registered in Agent 365 a corresponding service principal in Microsoft Entra ID. This means each agent has a managed identity — just like enterprise applications — that can be governed, audited, and controlled with existing Entra ID tools. Administrators can: (1) view agent identities alongside human and application identities in Entra Admin Center; (2) assign owners who are accountable for each agent; (3) review and manage the permissions (app role assignments) each agent has been granted; (4) target agents with Conditional Access policies to control when and how they access M365 resources; (5) review agent sign-in logs in Entra ID. Entra Agent ID makes agent governance consistent with how organisations already manage app and human identity.
Q: What is the difference between blocking an agent and rejecting an agent in the Agent 365 registry?
Blocking an agent applies to agents that are already published or installed — blocking prevents any new user from installing it and disables it for users who already have it installed. Use blocking when a previously approved agent is found to violate policy or pose a security risk. Rejecting a pending agent declines it before it is ever published — the agent never appears in the user catalogue and cannot be installed. Rejection applies to new agents submitted for review (e.g. from Copilot Studio publishers or third-party sources) that don’t meet the organisation’s requirements. The agent developer is notified of the rejection. Think of it this way: blocking = stop a live agent; rejecting = decline a new applicant.
Q: Why would you use an access package from Entra Identity Governance to manage agent access instead of simply publishing the agent to all users?
Publishing an agent to all users makes it available to everyone with an Agent 365 licence — appropriate for low-sensitivity general-purpose agents. An access package is used when: (1) the agent accesses sensitive data and only specific business roles should use it (e.g. HR Advisor agent should only go to HR staff); (2) the agent access must be bundled with corresponding data permissions (SharePoint site access, Teams channel membership) that the user also needs; (3) the access requires manager approval and periodic review via access reviews; (4) the access should expire after a defined period (e.g. project-based agent access for 90 days). Access packages provide a governed, auditable, time-bounded mechanism for agent access that simple publishing cannot achieve.
🎯 AB-650 Mock Test
Module 8 — Agent 365 & Agents Administration
Question 1 of 5
An organisation discovers that a third-party agent called “DataMiner Pro” has appeared in the Agent 365 registry and is requesting permission to read all SharePoint sites in the tenant. No admin has reviewed this agent. What should the administrator do first?
✅ Correct: C. When an unreviewed agent appears requesting broad permissions (all SharePoint sites), the correct first step is to block it to prevent any user from installing it while the security team investigates. Then review: who published this agent, what permissions does it request, is it from a trusted source, does it meet the organisation’s agent governance policy? Only after a thorough review should the agent be approved, published with reduced permissions, or permanently blocked. Granting consent (A) first is dangerous — the agent could immediately access all SharePoint data. CA restriction (B) helps governance but shouldn’t replace the initial block while reviewing an unknown agent.
Question 2 of 5
A Copilot Studio developer has built an HR Onboarding agent and submitted it to the Agent 365 registry. The compliance team wants the agent reviewed and approved by IT security before any user can install it. Which Agent 365 configuration ensures all new agent submissions require admin review?
✅ Correct: D. The Agent 365 registry can be configured to route all new agent submissions to a Pending review state by default, requiring an administrator to explicitly publish or reject each agent before it becomes available to users. This is the correct governance control for the scenario. RSS (A) limits SharePoint search scope for Copilot, not agent approval workflows. DLP (B) protects data but doesn’t gate agent publishing. Conditional Access (C) controls resource access but doesn’t implement an approval workflow for agent publishing.
Question 3 of 5
The IT security team wants the “Finance Advisor Agent” to only be available to Finance department employees, who also need access to the Finance SharePoint site and Finance Teams channel to use the agent effectively. Which approach handles all three access requirements with an approval workflow?
✅ Correct: A. Access packages in Entra Identity Governance are specifically designed to bundle multiple related resources (agent installation, SharePoint site access, Teams membership) into a single governed request. Users request the package, a manager approves, and all three access grants are automatically provisioned together. Access packages also support time-bound access and periodic access reviews. A dynamic group + admin deploy (C) handles the agent but not the SharePoint and Teams access as a coordinated bundle. Publishing to all users (B) removes the restriction. SharePoint permissions (D) handle site access but not agent installation or Teams membership.
Question 4 of 5
An administrator needs to ensure that a custom agent cannot be installed or used if the service principal associated with the agent is disabled in Entra ID. Which Agent 365 concept makes this possible?
✅ Correct: B. Microsoft Entra Agent ID assigns every agent a service principal in Entra ID. Since agents must authenticate via their service principal to access M365 resources, disabling the service principal (via
Update-MgServicePrincipal -AccountEnabled $false or through the Entra Admin Center) prevents the agent from obtaining tokens and accessing any M365 data — effectively disabling it at the identity layer. This is a deeper control than the registry status (A — which controls user visibility), permission revocation (C — which limits data access but doesn’t prevent authentication), or CA block (D — which is also valid but requires explicit policy targeting the agent’s app ID).Question 5 of 5
A security administrator wants a high-sensitivity financial data agent to only access M365 resources when connecting from within the corporate network (trusted IP range). Which feature achieves this specific control?
✅ Correct: D. Agent Conditional Access extends standard Conditional Access to agent service principals. Create a CA policy that: (1) targets the financial agent’s service principal (application); (2) adds a Named Location condition requiring the corporate IP range (trusted network); (3) sets the grant control to block if the location condition is not met. This ensures the agent can only authenticate and access M365 resources when operating from within the approved network. There is no “corporate network only” deployment scope in the Agent 365 registry (C). DLP (A) protects data but doesn’t enforce network-based authentication controls. SharePoint IP-based access (B) is a SharePoint-level control that doesn’t govern agent authentication broadly.
🔒
This module is lockedComplete Module 7 and pass its mock test to unlock this module.