Microsoft Agent 365: Roles, Registry, Logging and a Hardening Baseline

Agents now act inside Microsoft 365 mailboxes, Teams chats and SharePoint sites with their own identities and permissions, and most tenants have no single place that shows which agents exist, who owns them or what they can reach. Microsoft Agent 365 is Microsoft's control plane for that problem: an agent registry in the Microsoft 365 admin center, joined to Microsoft Entra for identity, Microsoft Purview for data protection and Microsoft Defender for threat detection. This guide explains how its identity and access model works, which admin roles control it, how its integrations and connected platforms handle credentials, what to log and hunt, and a hardening baseline with rollout steps. It is for Microsoft 365 administrators, identity teams and security operations. The Entra identity layer itself (agent identities, blueprints, Conditional Access for agents) is covered in depth in the Microsoft Entra Agent ID Guide; this page covers the Agent 365 governance layer on top of it. Product facts were checked against Microsoft Learn on 8 November 2026.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Agent 365 is generally available for the commercial segment since 1 May 2026, licensed per user, either standalone or inside Microsoft 365 E7; several parts (connected platform observability, local agents, shadow AI, Defender threat detection, MCP server requests) are still in preview.
• The registry is the inventory, Entra is the identity. Agents get identities in Microsoft Entra Agent ID, and the Agent 365 registry adds ownership, lifecycle actions, templates and tool governance on top.
• AI Administrator is the governance role to delegate, with Global Administrator reserved for emergencies and readers for monitoring; AI Administrators cannot change Conditional Access or access package policies.
• Connected platforms and MCP servers create new non-human credentials. Each external platform connection uses credentials that a platform administrator issues and rotates, and each approved MCP server needs Entra permission consent.
• Detection depends on observability being switched on. Defender hunting tables and Purview audit only see agents that emit Agent 365 observability data, so check coverage before trusting an empty alert queue.

How identity and access work in Microsoft Agent 365

Microsoft describes Agent 365 in three pillars: observe, govern and secure. Its own guidance states that "Identity isn't an add-on to Agent 365. It's the foundation." The layers fit together as follows.

• Two access patterns: Microsoft distinguishes interactive agents, which "acquire tokens that carry both user and agent context", from autonomous agents, which "authenticate independently using their blueprint's credentials". Interactive agents can never exceed the signed-in user; autonomous agents hold standing permissions of their own and deserve the tighter review.
• Agent instances are treated like users in Purview: files must be explicitly shared with the agent instance, and a label that encrypts content must grant the agent VIEW and EXTRACT usage rights. Content newly created by an agent does not inherit labels from its source items, so agent output can leave a labelled document unlabelled.
• Tenant settings set the envelope: under Agents, Settings, admins choose which agent types users may install (built by Microsoft, by your organisation, by external publishers), who can share agents organisation-wide (applies to Copilot Studio Lite agents), and which users can access agents at all. User access defaults to All users.
• Templates apply policy at activation: the Default Template applies Microsoft's Entra, Purview and SharePoint controls, assigns the Agent 365 licence and is locked; custom templates add your own policies, such as restricting external content sharing.

Availability: Microsoft lists Agent 365 at $15 per user per month standalone and as part of Microsoft 365 E7 (announced 1 May 2026), states it "works best with Microsoft E5", and requires at least one user with a qualifying Agent 365 licence to enable it. Entra security features for agents have their own licence prerequisites, summarised in the Entra Agent ID guide. Confirm current terms on the Agent 365 service description before budgeting.

Admin roles and privileged access

Agent management in the Microsoft 365 admin center uses Entra directory roles. Microsoft's role table:

• Tenant-wide versus product roles: Global Administrator and AI Administrator have tenant-wide authority over agents; product roles such as Power Platform Administrator govern only inside their product, so a Copilot Studio agent can be changed from two places.
• Separation of duties is built in: AI Administrators cannot configure Conditional Access or Entra access package policies; those need a more privileged identity role. Keep it that way: the person who approves an agent should not also write the policy that constrains it.
• Consent is the privileged act: approving an MCP server requires tenant-wide consent to the Entra permissions it declares, which only AI Administrator and Global Administrator can grant. Treat each approval like an admin consent to an enterprise application.
• Foundry infrastructure: starting and stopping Foundry agents requires the Azure AI Owner role, outside the Microsoft 365 role model.
• Just in time: make AI Administrator eligible rather than permanently assigned through Privileged Identity Management, with approval and a short activation window. See the Privileged Identity Management (PIM) Guide.

Integrations, API tokens and service accounts

Connected platforms

Agent 365 can synchronise agents built on other platforms into the registry under Agents, All Agents, Connected platforms. At the time of checking the documented sources were (alphabetically) Amazon Bedrock, Anthropic Claude Managed Agents, Databricks Genie, Google Vertex AI, Oracle Generative AI Agents, Salesforce Agentforce and Snowflake Cortex. Synchronisation is manual, and collecting activity data from these platforms is part of the Frontier preview programme.

• Credential ownership: Microsoft splits the work between the Agent 365 AI administrator, who creates the connection, and the platform administrator, who creates the source credentials, grants permissions and owns credential rotation. The Amazon Bedrock connection, for example, takes an access key ID and secret access key.
• Least privilege: the connection is designed to be read-only. Microsoft's Bedrock page lists list and get permissions for synchronisation and log or storage read permissions for activity, and says not to grant delete permissions unless you want admins to be able to remove agents from Agent 365.
• Rotation gap: no rotation procedure is documented; invalid credentials simply fail validation. Put each connection credential in your secrets inventory with an owner and expiry, prefer short-lived or federated credentials on the source platform where it supports them, and test the update path before the first rotation. See the AI Agent Credential Lifecycle and Rotation Guide.
• Deletion drift: an agent deleted on the source platform is not guaranteed to disappear from the registry; remove it manually and record why.

Plugins, skills and MCP servers

• Publisher scope: under Agents, Settings, Agent and plugin access, choose which publisher categories users can reach: Microsoft, your organisation, certified external publishers.
• MCP server requests (preview): developer-registered remote MCP servers appear under Agents, Tools, Requests with their declared tools. Approval is followed by consent to the Entra permissions the server requires; the server can take up to 30 minutes to appear in Copilot Studio environments.
• Tool-level control (rolling out): for supported servers, enable read-only tools and keep write, delete or payment tools off, enforced at runtime by the Agent 365 Tooling Gateway. Where a server's tools cannot be listed individually, block the whole server. Blocking an MCP server also blocks dependent plugins and connectors.

See the MCP Gateway and MCP Server Governance Guide and the MCP Server Trust Assessment for what to check before approval.

Logging and detection

Defender's preview detections cover jailbreak attempts, indirect prompt injection (XPIA), malicious content propagation, secret and credential leakage, evasion, LLM reconnaissance and suspicious user or IP access. Coverage has preconditions: Copilot Studio, Microsoft Foundry and Agent Builder agents emit observability by default, other platforms need the Agent 365 SDK, only published Foundry agents are supported, and local endpoint agents need Defender for Endpoint in active mode. Prompt evidence (snippets of the triggering prompt) is attached to alerts by default; decide deliberately whether your SOC should see prompt content and restrict access accordingly.

Hunts worth building: MCP server approvals and consent grants outside a change window; new agents with no owner; tool invocations of write or delete tools by agents classed as read-only; agents synchronised from a connected platform that do not match the source inventory; autonomous agents accessing resources outside their blueprint's purpose.

Metrics:

• Percentage of registry agents with a named owner and sponsor (target 100%).
• Percentage of agents emitting observability data, by platform.
• Count of standing AI Administrator and Global Administrator assignments (target: zero standing AI Administrator).
• Median time from agent request to approval or rejection, and number of approved MCP servers with write tools enabled.
• Connected platform credentials older than your rotation policy.

Hardening baseline

1. Inventory first: before changing settings, export the registry and agent map, connect the platforms where your organisation builds agents, and reconcile against Defender's agent inventory. See the AI agent registry guide.
2. Restrict the envelope: set User access to specific groups for a pilot, disable agent types you do not allow (often external publishers at first), and restrict organisation-wide sharing to named groups.
3. Use templates: keep the Default Template for most agents and build a custom template for agents that handle sensitive data, with external sharing restricted.
4. Assign ownership: resolve ownerless agents with Assign new owner. Groups cannot be owners, so name at least two people for shared agents; you cannot remove the last owner.
5. Lock down roles: AI Administrator eligible through PIM, Global Administrator for break-glass only, readers for audit and SOC.
6. Govern tools: approve MCP servers through the requests queue only after a trust assessment, enable tool-level restrictions where supported, and block servers that cannot be scoped.
7. Apply Entra policy: Conditional Access for agent identities and agent risk, ID Protection for risky agents, lifecycle workflows and access packages so access expires. See the Conditional Access Guide.
8. Apply Purview policy: add agent instances or a group of them to DLP, insider risk (Risky AI usage template) and retention policies; DLP blocks are invisible to agents, so owners must monitor them.
9. Turn on detection: enable security for AI agents in Defender with the Microsoft 365 app connector, onboard local agents through Defender for Endpoint, and agree who may see prompt evidence.
10. Test and roll back: pilot each restriction on one department; block is reversible with Unblock, and deleted agents can be restored for 30 days before permanent deletion, so prefer block and soft delete during the pilot.

Decision guidance: small tenants using only Microsoft-built and Copilot Studio agents can start with the Default Template, Microsoft and organisation publishers only, and Defender detection. Large or regulated tenants with agents on several clouds should connect those platforms, separate the AI Administrator from the identity policy owner, and require a documented purpose and expiry for every autonomous agent. If Power Platform Firewall is in active enforcement mode, admin actions on agents in that environment fail, so plan for audit-only mode or the Power Platform API.

The OWASP Top 10 for LLM Applications 2025 risk LLM06 Excessive Agency is the closest threat framing for the tool restrictions above; see the OWASP LLM Top 10 LLM06 Excessive Agency Guide.

Common misconfigurations

• Leaving user access at All users before templates, publisher restrictions and DLP are in place, so the first wave of agents arrives ungoverned.
• Standing AI Administrator assignments for builders and helpdesk staff, which hands tenant-wide consent for MCP server permissions to people who should only request it.
• Approving MCP servers with every tool enabled, including write and delete tools the agent's purpose does not need, or approving a server that cannot be scoped instead of blocking it.
• Treating connected platform keys as configuration rather than credentials: long-lived access keys with no owner, no expiry and permissions beyond read.
• Assuming the alert queue is complete when some agents emit no observability data, unpublished Foundry agents are unsupported and Copilot Studio real-time blocks are not yet recorded.
• Ignoring the consent path around agents: an agent's sign-in setting can be used to present OAuth consent phishing from a trusted domain. Restrict user consent, limit application administrator roles and monitor agent creation and changes.

Practitioner checklist

• Confirm licensing, which features are GA and which are preview in your tenant, and record the date checked.
• Export the registry, connect platforms where agents are built, and reconcile with Defender's agent inventory.
• Set user access, allowed agent types and sharing to pilot groups before broad enablement.
• Give every agent at least two named owners and a sponsor; fix ownerless agents.
• Make AI Administrator eligible through PIM; keep Global Administrator for break-glass.
• Approve MCP servers only after a trust assessment, with tool-level restrictions or a full block.
• Register connected platform credentials as non-human identities with owner, scope and rotation date.
• Apply Conditional Access, ID Protection and lifecycle workflows to agent identities.
• Add agents to Purview DLP, insider risk and retention policies; check label usage rights.
• Enable Defender security for AI agents, measure observability coverage and build the hunts above.

Standards and references

• Microsoft Learn: Microsoft Agent 365 overview
• Microsoft Learn: Agent management roles and permissions
• Microsoft Learn: Governance and lifecycle actions for agents
• Microsoft Learn: Manage plugins, skills and MCP servers
• Microsoft Learn: Detect and investigate threats to AI agents
• Microsoft Learn: Use Microsoft Purview for data security and compliance with Agent 365
• Microsoft Tech Community: Microsoft 365 E7 and Agent 365 are now generally available
• OWASP: Top 10 for LLM Applications 2025

Related NHI Mgmt Group resources: Microsoft Entra Agent ID Guide · Securing Microsoft Copilot Studio Agents Guide · Microsoft 365 Copilot Security Deep Dive · AI agent registry · Shadow AI Discovery Guide