AIAgentsInfo to the new unified AgentsInfo table per Microsoft Learn (schema changes notice, June 2026). Old table accessible until July 1, 2026. New schema is in Preview. See the full column mapping on playbooks.html if you encounter query issues.
The enterprise control plane for AI agents. Agent 365 doesn't build or host agents — it wraps agents you've already built in enterprise-grade identity, governance, observability, and security controls.
New capabilities announced at GA:
| Capability | Status | Detail |
|---|---|---|
| Registry sync — AWS Bedrock + Google Cloud | Preview now | Automatically discover and inventory agents on AWS Bedrock and Google Gemini Enterprise Agent Platform. Basic lifecycle governance (start, stop, delete) coming soon. |
| Defender agent context mapping | Preview June 2026 | Relationship map per agent: devices it runs on, MCP servers configured, associated identities, cloud resources reachable. Blast radius analysis and endpoint-based behaviour investigation. |
| Intune integration — policy controls + runtime blocking | Preview June 2026 | Policy-based controls and runtime blocking/alerting via Intune and Defender for agents on managed devices. |
Pricing: USD$15 per user per month. Each licence covers an individual who manages or sponsors agents, or uses agents to do work on their behalf. Also included in Microsoft 365 E7.
Source: Microsoft Security Blog — Agent 365 GA (May 1, 2026)
Agent 365 is not an agent builder or hosting platform. It is a management and security layer that sits above whatever platform your agents run on — Copilot Studio, Microsoft Foundry, LangChain, OpenAI Agents SDK, or anything else. Once an agent is onboarded to Agent 365, it gains enterprise-grade controls it didn't have before.
Platform == "Microsoft Agent 365"). Near-real-time threat detection, incident alerts, and investigation via Defender portal → Settings → Security for AI.Agent 365 works with agents built on any platform and hosted anywhere. This is not a Microsoft-only capability.
You add the Agent 365 SDK to your agent code. Once instrumented, the agent registers with Agent 365 regardless of where it runs — Azure, AWS, GCP, or your own infrastructure. The SDK handles the Entra identity registration, OpenTelemetry event emission, and ATG integration automatically. You don't rewrite your agent; you add a governance layer around it.
Agent 365 is not a closed Microsoft system. At GA, a growing ecosystem of external agents and frameworks are certified to integrate with Agent 365 — inheriting the same identity, governance, and security controls.
Source: Microsoft 365 Blog — Agent 365: The control plane for AI agents (Nov 2025)
New Purview capability announced alongside Agent 365 GA: visibility into how Copilot and AI apps interact with enterprise data, with retention and deletion policies for AI prompts and outputs. Addresses regulatory obligations as AI adoption scales. Distinct from DLP (blocks at point of use) — DLM governs what is retained after. Source: Microsoft Tech Community.
Until July 1, 2026, Agent 365 is optional — Defender for Cloud Apps, Purview, Sentinel, Security Dashboard for AI, and Entra Conditional Access all provide meaningful agent security coverage using existing licensing. From July 1, 2026, that changes. Per Microsoft's transition guide: "AI agent security capabilities for Copilot Studio and Foundry agents require a Microsoft Agent 365 license. These capabilities are no longer covered by existing Defender for Cloud Apps or Defender for Cloud licenses."
What's no longer covered after July 1 (requires Agent 365):
What still works without Agent 365 after July 1:
Budget action: if you have meaningful Copilot Studio or Microsoft Foundry agent deployment in your environment, license Agent 365 before July 1, 2026. The pricing cards below are the two options.
⚠️ Per-user, not per-agent. Governance scope doesn't automatically scale with agent count. An organisation with 50 licensed users but 500 deployed agents has a coverage gap. Plan accordingly.
💡 When E7 makes sense: If you're buying M365 Copilot + E5 + Entra Suite anyway, E7 likely costs less than the sum of parts. Run the numbers — the break-even depends on your existing licence baseline.
Once the July 1, 2026 transition completes, Agent 365 becomes the unified control plane for agent security across the Microsoft stack. The architectural picture is cleaner than today's overlapping coverage from Defender for Cloud Apps + Defender for Cloud + Purview signals.
| Capability | Today (until July 1) | From July 1, 2026 onwards |
|---|---|---|
| Copilot Studio agent security | Defender for Cloud Apps + Agent 365 (overlapping) | Agent 365 only (Defender for Cloud Apps no longer carries the AI overlay for these) |
| Foundry agent security posture | Defender for Cloud + Agent 365 (overlapping) | Agent 365 only (Defender for Cloud no longer carries it) |
| Third-party cloud agent discovery (AWS Bedrock, GCP Vertex AI) | Defender for Cloud connectors | Agent 365 Registry sync (configure before July 1 to maintain visibility) |
| Real-time protection block rules | Existing rules continue blocking | Block rules need redefining under Settings → Security for AI → Policies (new experience launches July 1) |
| Advanced Hunting | AIAgentsInfo table (works until July 1) | AgentsInfo (unified across all platforms — Copilot Studio, Foundry, M365 Copilot, third-party, endpoint-discovered) |
| Real-time protection alerts | Surface in existing alert tables | Move to BehaviorInfo table |
| Defender + Entra + Intune + Purview protections for local agents | Separate signals from each product | Delivered through MXC (Microsoft Execution Containers) — native Agent 365 + MXC integration enters Preview July 2026 |
Microsoft's positioning post-July 1: agent identity (via Entra Agent ID), runtime environment (Intune-controlled MXC for local agents, Foundry Agent Service for hosted, Windows 365 for Agents for managed Cloud PCs), data interactions observed (Purview), and threat monitoring (Defender) all converge through Agent 365 as the central plane. Same control surface regardless of where the agent runs — on a developer laptop, in Foundry, in Copilot Studio, in a partner cloud, or in a Windows 365 for Agents instance.
This isn't a marketing claim — it's reflected in concrete product mechanics. The new Agent 365 admin centre in M365 (entering Preview alongside the July 1 transition) is where you'll see your tenant's full agent inventory, governance state, security posture, and incident timeline from any agent platform.
If you're standing up an AI agent practice now, three things to plan for:
If you're not yet deploying Copilot Studio or Foundry agents at scale, the July 1 transition is less urgent — but the architectural picture for any future agent deployment is shaped by Agent 365 as the control plane. Defender + Purview + Entra + Intune still play their roles; Agent 365 stitches them together for agents specifically.
Agent visibility was previously split across the Entra admin center and the M365 admin center. Microsoft has converged the registry under Agent 365 as the single control plane. Each portal now has a distinct role:
| Portal | What you do here | Agent visibility | Role required |
|---|---|---|---|
Microsoft 365 admin centeradmin.microsoft.com → Agents → All agents |
Comprehensive agent inventory — discover and manage all agents in the organisation, monitor operational activity | ✓ ALL agents Including agents without Entra Agent ID |
AI Administrator or AI Reader (least-privilege) No licence required for inventory view |
Microsoft Entra admin centerentra.microsoft.com |
Agent identity and access management — blueprints, permissions, Conditional Access, identity governance, security signals | ⚠ Agents with Entra Agent ID only | Agent ID Administrator Entra Agent ID licence required for security controls |
The Entra admin center only shows agents that have a Microsoft Entra Agent ID. Agents without an identity — including most Classic Copilot Studio agents — are invisible there. For a complete picture, identity admins should use Agent 365 (M365 admin center) for inventory and the Entra admin center for identity governance controls.
| Role | What it gives you | Portal |
|---|---|---|
| AI Reader | Read-only view of all agents in the organisation. Recommended least-privilege role for inventory access. | M365 admin center (Agent 365) |
| AI Administrator | Full management of all agents in Agent 365 including governance controls. | M365 admin center (Agent 365) |
| Agent ID Administrator | Manage agent identities, blueprints, permissions, CA policies in Entra. Required for Blueprint write operations. | Entra admin center |
Viewing all agents in the M365 admin center (Agent 365) requires no specific product licence — just the AI Administrator or AI Reader role. Applying security and governance controls (Conditional Access, identity governance policies) requires the appropriate Entra Agent ID licence.
Agent 365 is GA on May 1, 2026. Before that date — and for some advanced preview features — access is via the Microsoft Frontier programme.
Coverage depth varies depending on how the agent was built and whether the Agent 365 SDK is integrated.
| Agent type | Discovery (AgentsInfo) | Threat detection | Real-time protection (ATG) | Requires |
|---|---|---|---|---|
| Copilot Studio agents | ✓ AutomaticPlatform == "Copilot Studio" |
✓ Extended alert set Audit logs sent by default |
✓ Available | Power Platform connector enabled in Defender |
| Agent 365 SDK agents | ✓Platform == "Microsoft Agent 365" |
✓ Near-real-time Requires M365 audit log routing |
✓ ATG | Agent 365 licence + SDK integration |
| Foundry / Bedrock / Vertex AI | ✓ UI inventory | ⚠ Limited — no SDK | ❌ Without SDK | Agent 365 SDK required for detection + ATG |
| Classic Copilot Studio agents | ✓ via PowerPlatform connector | ⚠ Basic only | ✓ Existing Defender RT | No Agent 365 needed — but no Entra Agent ID |
Source: Microsoft Security Blog — Agent 365 GA (May 1, 2026)
| Mode | Status | How it works | Example |
|---|---|---|---|
| Agents working on behalf of users Delegated access |
GA | Agent acts on behalf of a signed-in user using delegated permissions. Operates in response to user prompts. Uses the user's identity context. | An agent that helps an employee organise their inbox or summarise emails |
| Agents operating behind the scenes Own access / autonomous |
GA | Agent operates with its own credentials and permissions, without user context. Runs autonomously in the background on scheduled or event-triggered tasks. | An agent autonomously triaging support tickets or running nightly data reconciliation |
| Agents participating in team workflows Own access / collaborative |
Preview | Agent operates with its own access while participating in team channels, meetings, or shared workspaces. Interacts with multiple users and agents in collaborative contexts. | An agent added to a Teams channel that monitors project activity and responds to @mentions |
Users are installing local AI agents (OpenClaw, GitHub Copilot CLI, Claude Code) on their devices and adopting SaaS agents outside traditional governance. Agent 365 now addresses this with a new Shadow AI page in the M365 admin center.
What IT can do today (Frontier programme): See if OpenClaw agents are being used in the organisation, which devices they are running on, and enable two Intune security policies from the Shadow AI page:
| Policy | Intune policy created | What it does |
|---|---|---|
| Continuously detect managed devices | A365 - Monitor OpenClawDevice configuration · Properties catalog profile |
Creates a read-only Properties catalog profile using the new Local AI Agent Settings Catalog node. Runs via Intune Management Extension (IME) — inspects disk and memory on managed Windows devices. Safe to deploy — reads from device, does not configure it. Refreshes every 24 hours. |
| Block AI Agents from OpenClaw | A365 - Block OpenClawSecurity baseline policy |
Blocks common methods of running OpenClaw on managed devices via Intune security baseline policy. See rollback caveat below before enabling. |
| Property | What it captures |
|---|---|
Agent Name | Canonical identifier for the agent type (e.g. "OpenClaw") |
Agent Version | Version string of the installed agent |
Host Process | Parent process executing the agent — identifies the execution context |
Install Location | Filesystem path of the agent installation |
Install Scope | Per-user vs per-machine installation |
Install Scope Platform User ID | Windows SID of the installing user |
Install Scope User ID | Entra ID user identifier (UPN) of the installing user |
Local AI Agent Execution Context | Privilege/security context — user / elevated / SYSTEM. ⚠️ SYSTEM-level execution is high risk. |
Local AI Agent Execution Context field lets IT and security teams immediately identify which devices have agents running with elevated or SYSTEM-level privileges — a key risk signal for triage.
A365 - Block OpenClaw security policy directly in Intune. The Agent 365 portal does not expose a disable control.
Source: Windows IT Pro Blog — Windows 365 for Agents public preview (May 1, 2026)
Many enterprise applications have no APIs — critical work still happens through user interfaces where context, data, and intent are conveyed visually. To unlock their full potential, AI agents need to interact with applications the way people do: using a computer directly through clicks, typing, and navigation. Today most agents run on ad-hoc infrastructure — local machines, shared virtual machines, or unmanaged cloud environments — creating gaps in identity, policy enforcement, auditability, and control. This makes it difficult for IT teams to confidently scale agentic workloads beyond API- or MCP-based pilots.
Every employee in an organisation has an identity and works on a managed device — typically a Windows 365 Enterprise Cloud PC. Now, each AI agent also has its own identity (governed through Agent 365) and runs on a managed Cloud PC (provided by Windows 365 for Agents). It is the same trust model and the same IT controls — extended to AI.
| Dimension | Detail |
|---|---|
| What it is | A new class of Cloud PCs purpose-built for agentic workloads. Agents run in a fully managed Windows environment with identity, security, policy, and lifecycle management handled by IT. |
| Status | Public Preview · US only · May 1, 2026 |
| Three key benefits | ① Enterprise-grade identity and access controls for every agent · ② Unified device and policy management via Intune · ③ Global scalability with geo-level data residency for compliance |
| Prerequisites | Agent 365 licence + Intune licence + active Azure subscription (billing for Cloud PC compute is Azure pay-as-you-go, not included in Agent 365) |
| Relationship to Agent 365 | Agent 365 = control plane (what agents can do, governance, policies). Windows 365 for Agents = execution layer (where agents run securely). Together: move from visibility/governance to production-ready deployments. |
| Who it is for | IT administrators, security teams, digital workplace leaders, platform teams. Especially valuable for: legacy/UI-based app workflows with no API, human-in-the-loop scenarios, organisations needing geo-specific data residency. |
Microsoft IQ — the intelligence layer. Shared context across people, work, and the business. Helps AI understand what matters and make informed decisions. Agents use this to reason.
Windows 365 for Agents — the execution layer. Trusted, managed runtime for agents to get work done, especially for UI-based workflows.
Microsoft Azure — the foundation. Global cloud for secure, scalable AI. Hosts the Cloud PCs.
Agent 365 — the control plane. Governs agent behaviour end-to-end across all platforms.
Work IQ is the contextual intelligence engine that grounds Microsoft 365 Copilot and Agent 365–managed agents in real-time, shared context across the organisation. It enables personalised search, advanced reasoning, and deeper semantic understanding by connecting signals across the Microsoft 365 ecosystem and business systems. Announced at Microsoft AI Tour Paris (March 2026) as a standalone agentic building block. Source: Microsoft Learn — Work IQ MCP overview (Preview)
Prerequisite: Microsoft 365 Copilot licence required to use Work IQ MCP servers.
| Layer | What it does |
|---|---|
| Data | Unifies signals from files, emails, meetings, chats, and business systems across Microsoft 365 to capture how work happens across the organisation. |
| Memory | Builds persistent understanding of how people and teams work. Enables Agent 365–managed agents to stay aligned to priorities and remain consistent across tasks, apps, and sessions. |
| Inference | Brings together models, skills, and tools so agents can reason and take action using Work IQ MCP tools, while the Agent 365 control plane ensures those actions remain observable, governed, and compliant. |
Agents grounded via Work IQ inherit your organisation's data governance automatically. Sensitivity labels travel with the data — an agent cannot surface Confidential content to a user without the right permissions. Work IQ enforces this at the grounding layer, not just at output. This structural compliance makes Microsoft-native agents contextually superior and inherently more governable than ungoverned third-party alternatives using direct API calls.
The Agent Map is a dynamic visual in the Agent 365 portal showing which agents communicate with which resources, what access they use, and what risk signals are surfacing from Entra, ID Protection, Purview, and Defender — all in one view. Source: Devoteam — Microsoft AI Tour Paris (March 2026)
From the Agent Map, administrators can: block a flagged agent with a single click pending security review, approve or reject new agent deployment requests, see risk signals cross-referenced across identity and data signals, and identify orphaned agents with no current owner.
The most common real-world orphaned agent scenario is not Blueprint deletion (the Entra identity case) — it is employees who built agents in Copilot Studio and then left the organisation. Those agents continue running with the builder's original permissions, full access to the tools and data they were connected to, and no accountable owner. Microsoft does not detect or flag these automatically. The Agent 365 portal surfaces them in the Ownerless Agents view and the Agent Map.
Detection KQL:
AgentsInfo | summarize arg_max(Timestamp, *) by AgentId | where PublishedStatus == "Published" | where array_length(Owners) == 0 | project AgentName, CreatedDateTime, ToolsAuthenticationType
Agent 365 agents are stateful — powered by Dataverse, they retain memory across sessions. This allows agents to remember user preferences, project details, team roles, and conversation context from previous interactions.
The Dataverse memory store accumulates sensitive context over weeks or months of agent interactions — meeting summaries, project decisions, user preferences, escalation history. This persistent store needs the same governance controls as any other sensitive data repository: access controls, retention policies, and inclusion in Purview DLP scope. It is not automatically covered by existing M365 data governance policies.
Use Platform == "Microsoft Agent 365" to target Agent 365-registered agents specifically. See Playbook 01 Step 8 for the full query set.
// All A365 registered agents AgentsInfo | summarize arg_max(Timestamp, *) by AgentId | where LifecycleStatus != "Deleted" | project AgentId, AgentName, PublishedStatus, IsBlocked, AIModel, Instructions // Agents with no instructions — prompt injection risk AgentsInfo | summarize arg_max(Timestamp, *) by AgentId | where isempty(Instructions) or Instructions == "N/A" | project AgentId, AgentName, Instructions // Agents with MCP tools — expanded attack surface AgentsInfo | summarize arg_max(Timestamp, *) by AgentId | where isnotempty(Triggers) | extend Triggers = parse_json(Triggers) | mv-expand Trigger = Triggers | where Trigger.type == "RemoteMCPServer" | project AgentId, AgentName, Trigger.type
Microsoft has shipped an Agent 365 data connector for Microsoft Sentinel. It does something distinctive: ingests agent telemetry into the Sentinel data lake from three sources at once — Agent 365, Microsoft Foundry, and Copilot. For organisations running agents across multiple Microsoft platforms, this replaces what would otherwise be three separate connector configurations.
| Capability | Detail |
|---|---|
| Data sources unified | Agent 365 + Microsoft Foundry + Copilot — all in the Sentinel data lake |
| Telemetry types | Agent behaviour, tool usage, execution metrics, runtime events |
| Workflows enabled | Hunting (KQL + natural language via Sentinel MCP), graph relationships (agent-to-agent, agent-to-tool), MCP server interactions |
| Supported by | Microsoft Corporation (first-party connector) |
| Deployment | Sentinel → Content Hub → search "Agent 365" → install + configure data ingestion to the data lake |
The Agent 365 connector pairs naturally with the Microsoft Sentinel MCP server for natural-language querying of the unified data lake. SOC analysts can ask questions like "show me all Copilot agents that called external HTTP endpoints in the last week" without writing KQL. This is the model Microsoft is now pushing for AI-driven SOC operations on agent telemetry.
Per Microsoft's documentation: "Data from this connector is used to investigate AI agent behavior, tool usage, and execution in Microsoft Sentinel. If you have enabled these workflows, deactivating this connector will prevent those investigations from being performed." Hunting queries, graphs, and MCP investigations all depend on the connector being live — treat it as a first-class production dependency for SOC, not an optional add-on.
Microsoft has published dedicated Purview documentation for Microsoft Agent 365, formalising what's auditable and how Agent 365 instances appear in DSPM and the unified audit log.
Audit an agent instance as you would a user — all interactions appear in the unified audit log, including agent-to-human, human-to-agent, agent-to-tools, and agent-to-agent. Activity Explorer in DSPM (and DSPM for AI) shows agent activity under the AI activities tab, including prompts and responses where applicable. Sensitivity labels applied to data the agent accesses are captured in the audit record. Search via Agent 365 audit activities in the Purview portal.
At Build 2026 Microsoft announced native Windows integration with Agent 365 — providing a common foundation for observability, security, and governance of agents that run locally on Windows endpoints. This is the convergence of four governance pillars (identity, threat, device, data) at the runtime boundary for local agents, not just cloud agents.
| Component | What it provides | Status |
|---|---|---|
| Microsoft Execution Containers (MXC) SDK | Policy-driven execution layer. Developers declare what an agent can access (files, network, processes); containment boundaries enforced at runtime. Composable isolation — light when low-risk, full sandbox when sensitive. | Early Preview |
| Agent 365 + MXC native integration | Defender, Entra, Intune, and Purview protections delivered via MXC. Agents on Windows start secure and stay secure. The four pillars converge at the runtime boundary. | Preview · July 2026 |
| Native Intune integration | Intune sets policies that gate agent runtime execution — controlling how agents run, what permissions they have, what they can reach. Same Intune surface IT already uses for device and application management. | Preview |
| Defender local agent discovery | Defender for Endpoint discovers and profiles supported local AI agents on Defender-onboarded Windows endpoints. Each agent surfaces as a security asset (not just an OS process), defined by user + device + agent type. Five categories covered: CLI agents, Desktop apps, Agentic IDEs, VS Code extensions, Claw-based agents. 20+ specific tools today (full list on MCP page). Three views: inventory, exposure map, Advanced Hunting. M365 admin center Shadow AI detection shows unmanaged agents + publishers across the tenant. | Preview · June 2026 |
| Defender AI agent runtime protection | Inline prompt-injection detection at three hook points in the agent loop: user prompt, pre-tool call, post-tool response. Three modes: Block (stops action + notifies + alerts), Audit (continues + alerts — recommended starting mode), Disabled. Tamper-protected setting. Alert name: "Suspicious AI prompt injection." Currently supports Claude Code + GitHub Copilot CLI via their published hooks frameworks. Coverage expanding. | Preview · June 2026 |
| Defender advanced hunting + exposure graph for agents | Trace how agents are connected across the network. Investigate agent activity using the same endpoint telemetry security teams already use in Defender. | Preview coming soon |
Until Build 2026, Agent 365 governance was strongest for cloud-hosted agents (Copilot Studio, Foundry). Local agents on developer machines were observable through Purview's June 2026 endpoint-agents wave but governance was still split across multiple control planes. With native Windows + MXC integration, Agent 365 becomes a single control plane that spans cloud-hosted agents AND local agents. Same identity, same telemetry pipeline, same policy surface — whether the agent runs in Foundry, in OpenClaw on a developer laptop, or in Windows 365 for Agents in the cloud.
For architects: this is the moment Microsoft completes its "agent = first-class enterprise asset" model. An agent has an identity (Entra Agent ID), runs in a managed device/environment (Intune-controlled MXC, or Windows 365 for Agents, or Foundry hosted), has its data interactions observed (Purview), and is monitored for risk (Defender). Phase 4 (Runtime Protection) and Phase 5 (Monitoring & Detection) of the six-phase strategy converge on this stack for local agents specifically.
This section was previously a separate page. It covers the security differences between Copilot Studio and Microsoft Foundry — helping security architects understand which controls apply to each platform and where the gaps are.
The security controls, gaps, and runbooks are fundamentally different depending on which platform your agents run on. Start here to make sure you're looking at the right controls.
| Security Control | Copilot Studio | Microsoft Foundry |
|---|---|---|
| Entra Agent ID | ⚠️ Modern agents only — most existing deployments are Classic and excluded | ✅ Supported — agents are Entra identities by default |
| Conditional Access for Agents | ❌ Does NOT apply to Copilot Studio agents | ✅ Applies to Foundry agents (OAuth 2.0 Agent ID) ⚠️ Security Copilot: applies to Microsoft-built agents only. Custom/partner agents use "Connect with existing user account" — no Agent ID, CA for Agents does not apply. |
| ID Protection for Agents | ❌ Classic agents only — Modern agents supported | ✅ Supported |
| Identity Governance (lifecycle) | ⚠️ Modern agents only | ✅ Supported via Entra ID Governance |
| Defender real-time protection | ✅ Copilot Studio agents (Defender for Cloud Apps) | ✅ Defender for Cloud AI security posture |
| Sentinel analytics rules | ✅ AgentsInfo table queries | ✅ Azure Monitor + App Insights tables |
| Prompt Shield / Content Safety | ✅ Built-in via M365 Copilot layer | ✅ Content Safety SDK — opt-in per agent |
| DLP / Purview (policy layer) | ✅ DLP for M365 Copilot (GA March 31 2026) — covers Copilot experiences | ✅ Azure data governance applies |
| Browser-layer DLP | ✅ Edge for Business inline protection — inspects typed prompts to any GenAI app incl. shadow AI. Works on BYOD if signed into Edge for Business profile | ✅ Same — applies to any browser-based interaction |
| Network-layer DLP | ⚠️ Preview — Network Data Security via Global Secure Access. Covers unmanaged devices, desktop apps, API calls | ⚠️ Preview — same coverage |
| SharePoint oversharing controls (SAM) | ✅ SharePoint Advanced Management included with Copilot licence — RCD, Site Access Reviews, Content Assessment, RAC. Primary tool for Copilot data exposure remediation. | ⚠️ Not applicable at the same level — Foundry agents access data via explicit connections, not broad SharePoint indexing |
| Agentic data governance | ✅ DLP extends to agent-to-human, agent-to-tools, agent-to-agent. Sensitive files blocked from grounding data. Auto-enrolled for audit at creation | ✅ Same — agent instances enrolled as auditable entities |
| Inventory / discovery | ✅ Agent 365 + AgentsInfo table | ⚠️ Azure Resource Manager + Entra Agent ID — no unified agent-level inventory table equivalent |
| Logging — default state | ✅ Some data in AgentsInfo automatically | ⚠️ Nothing collected by default — all logging is opt-in |
| Red teaming | ⚠️ No native Copilot Studio red teaming tool | ✅ AI Red Teaming Agent in Microsoft Foundry |
| Supply chain scanning | ⚠️ Limited — connector risk is the main vector | ✅ Defender for Cloud CSPM, AI model scanning |
Security Copilot agents offer two identity options. Microsoft-built agents (Phishing Triage, Threat Intelligence Briefing, Vulnerability Remediation etc.) use a dedicated Entra Agent ID — CA for Agents and ID Protection apply. Custom and partner agents use "Connect with existing user account" — the agent runs using the configuring user's credentials, inheriting their full access and permissions.
Why this is worse than Copilot Studio maker credentials: Security Copilot users are typically high-privilege accounts — Security Admins, SOC engineers, Global Admins. A custom agent configured by a Global Admin silently extends Global Admin-level access to Sentinel incidents, Defender signals, Entra identity risk data, and threat intelligence — to every user who runs the agent. The blast radius of a compromised or misconfigured custom Security Copilot agent is significantly larger than a typical Copilot Studio agent.
Mitigation: Use a dedicated low-privilege service account for configuring custom Security Copilot agents. Audit who configures custom agents and what permissions their account holds. Establish an approval gate before production deployment.
Every Copilot Studio agent uses one of five authentication patterns. The pattern determines the risk level, what controls apply, and how you detect it.
ToolsAuthenticationType == "Integrated"
DeclaredTools.mode == "Maker"
HTTP Request + delegated token
HTTP to graph.microsoft.com + client creds
Entra ID Governance lifecycle required
Most existing Copilot Studio deployments are Classic agents. They authenticate as service principals or via OBO — not as modern Agent ID identities. This means CA for Agents, ID Protection for Agents, and Entra lifecycle governance do not apply. The entire Entra security product stack Microsoft markets for agent security only works with Modern agents.
Microsoft does not clearly document this distinction in its product marketing. Most security teams assume that purchasing Entra Agent ID or enabling CA for Agents covers their Copilot Studio estate. It does not — unless agents have been specifically created as Modern agents using the Agent ID framework. Field research confirms this is the default state of most enterprise Copilot Studio deployments.
| Layer | What it protects | Always active? | Error message |
|---|---|---|---|
| Responsible AI content filtering |
Conversational level — harmful content, jailbreak attempts, prompt injection in user input, copyright. Evaluates what is being discussed. | ✓ Always on — no config needed | "Content filtered due to Responsible AI restrictions" |
| Real-time threat protection (Defender for Cloud Apps) |
Action execution level — tool invocations, data access patterns, privilege escalation through tool chaining, data exfiltration. Evaluates what the agent is about to do. | ⚠️ Must be configured — off by default | "Blocked by threat protection" |
If Defender for Cloud Apps does not return a block decision within 1 second, the tool invocation proceeds regardless. Fast tool calls on high-latency connections may bypass real-time protection. Treat it as a strong detection and prevention control — not a guaranteed prevention guarantee.
Run these in Defender Advanced Hunting to get immediate visibility. Any result from Query 1 or 2 is a critical finding.
| Gap | Risk | Interim Mitigation |
|---|---|---|
| Classic agents outside Entra perimeter | ⚠️ Critical | Inventory via AgentsInfo; enforce end-user auth in Power Platform admin; manually recreate critical agents as Modern |
| Any user can change another agent's auth type to None | ⚠️ Critical | Deploy change-detection Sentinel Analytics Rule; restrict Copilot Studio access via Managed Environments |
| Maker credentials blast radius | ⚠️ High | Enforce end-user auth per agent; PAM hygiene on developers who build agents; audit via Query 3 above |
| Portal inventory count inconsistency | ⚠️ High | Trust AgentsInfo table as primary source; treat portal counts as approximate |
| Agent sprawl — no lifecycle enforcement | ⚠️ High | Assign owners to all agents; use access packages for time-bound permissions; quarterly AgentsInfo audit |
Microsoft Foundry uses a layered resource model that most teams bolt security onto after deployment — when the decisions that matter most are already harder to change.
Foundry generates telemetry across four distinct layers. The Activity Log is the only one that requires no configuration. Everything else is opt-in and off by default.
| Layer | What it captures | Default state | SecOps priority |
|---|---|---|---|
| Layer 1 · Activity Log | Resource CRUD, RBAC changes, key rotation, network config, model deployments | ✅ Automatic | ⭐⭐⭐ Essential — route to Sentinel |
| Layer 2a · Diagnostic Settings (Resource) | Audit (data plane access), RequestResponse (inference metadata — no prompt content), AzureOpenAIRequestUsage, Trace | ❌ Off by default — explicit opt-in per resource | ⭐⭐⭐ Enable Audit + RequestResponse for SecOps |
| Layer 2b · Diagnostic Settings (Project) | Audit (agent operations — runs, file uploads, evaluations), Trace, AllMetrics | ❌ Off by default — separate config per project | ⭐⭐⭐ Enable Audit per project — does NOT inherit from resource |
| Layer 3 · Application Insights | Full agent runtime traces, tool call chains, prompt + completion content (if enabled), exceptions, dependencies | ❌ Off by default — SDK connection per project | ⭐⭐ Enable for agent-level behavioural visibility |
| Identity · Entra ID logs | Non-interactive sign-ins, service principal sign-ins, agent lifecycle events | ❌ Tenant-level diagnostic setting — separate config | ⭐⭐⭐ Required — without this, agent auth plane is a blind spot |
1. Diagnostic Settings don't cascade. Settings configured at the Foundry resource level do NOT apply to projects. Every new project needs its own separate Diagnostic Settings configuration — or you accept the gap silently.
2. RequestResponse does not contain prompt content. By design. If investigation requires content-level visibility, Application Insights with content capture enabled is the only source — but enabling AZURE_TRACING_GEN_AI_CONTENT_RECORDING_ENABLED creates direct responsibility for storage, access controls, and retention of potentially sensitive data (PII, secrets, business data).
Copilot Studio content: field research by Derk van der Woude (Microsoft Security MVP) · Microsoft Entra security for AI overview (April 2026) · Microsoft Zero Trust Assessment Workshop AI section.
Microsoft Foundry logging: Cyphora.io — Microsoft Foundry Logging (April 2026) · Microsoft Learn documentation.