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 — external cloud platforms | Preview now | Automatically discover, inventory, and import agents from external platforms into the Agent 365 registry for centralised visibility and governance. Announced at GA for AWS Bedrock and Google Cloud; per Microsoft Learn now covers four platforms — see the detail below. Basic lifecycle governance (start, stop, delete) via each platform's APIs is available. |
| 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)
AI agents are commonly built and hosted outside Microsoft. Registry sync lets an admin securely connect those external environments and pull their agents into the Agent 365 registry for centralised inventory, visibility, and basic lifecycle governance — without leaving the Microsoft 365 admin center. You authenticate once per environment, then sync agents on demand (scheduled sync is coming in a future release).
Supported platforms (per Microsoft Learn):
AWS Bedrock and Google Cloud (Gemini Enterprise Agent Platform, formerly Vertex AI) were the GA-day platforms; Salesforce Agentforce and Databricks Genie are also listed as supported on Microsoft Learn. Microsoft product teams are actively expanding platform coverage.
Set-up: M365 admin center → Agents → All Agents → in the Registry sync web part select Manage → + Connect a platform → name the connection, pick the platform and region, choose auto-import, enter and validate credentials, save. Each platform needs read/list (and delete, for lifecycle) permissions on its own side — e.g. an AWS IAM user with bedrock:ListAgents/GetAgent, a Google service account with the Vertex AI reasoningEngines permissions, a Salesforce connected app with client-credentials OAuth, or a Databricks service principal with workspace admin.
Each connection stores long-lived credentials to a third-party cloud (AWS access keys, GCP service-account keys, Salesforce consumer secrets, Databricks client secrets). Scope them to the minimum agent-read/list/delete permissions above, rotate them, and treat the Registry sync connection list as a privileged inventory. From July 1, 2026 registry sync is also the replacement discovery path for third-party cloud agents that were previously found via Defender for Cloud connectors — configure it before the cutover to avoid a visibility gap.
Source: Microsoft Learn — Registry sync in the Microsoft 365 agent registry (preview). Note: registry sync (external cloud platforms) is distinct from the June 2026 addition of local agents to the registry — see the June 2026 update below.
Source: "What's new in Agent 365 — June 2026", Microsoft Community Hub (Alex Pozin, Samer Baroudi, Brendan Powers · published Jul 8, 2026). This month's wave centres on local agents — shadow AI running directly on user devices — plus faster onboarding and stronger programmatic governance.
| Capability | Status | Detail |
|---|---|---|
| Local agents in the Agent 365 registry | Public Preview | Shadow local agents detected across the environment now surface in the registry — a unified view of each agent's publisher, detected device count, and last scanned date. A per-agent details pane lists every endpoint where the agent has been observed, with device name, model, and operating system. Lets teams pinpoint which shadow agents users run, scope the footprint by device, and accelerate investigations. (Distinct from external-cloud registry sync, which imports agents from Bedrock/Vertex/Agentforce/Genie.) |
| Purview Audit for local & developer agents | Expanding | Purview Audit in Agent 365 adds coverage for GitHub Copilot CLI, Claude Code, OpenAI Codex, and OpenClaw. Captures human-to-agent, agent-to-agent, and agent-to-tool interactions with contextual metadata on access, actions, and activity — closing audit gaps as agent usage becomes distributed. |
| Defender security for local agents | Public Preview | Since the June 2 release, Defender discovery of local agents and MCP servers spans managed Windows and macOS devices, now supporting more than 35 known agent types (preview). Adds exposure risk for local agents — identify and prioritise the riskiest agents by configuration, permissions, and exposure, with remediation recommendations. On-device runtime protection (public preview) covers Claude Code, GitHub Copilot CLI, GitHub Copilot app, Codex CLI, OpenClaw and similar Node-based claws, using agent-native event inspection plus on-device network-based runtime inspection: it can audit or block prompt-injection instructions and raises Defender XDR alerts. Purview integration audits or blocks prompts and tool calls in real time to prevent exfiltration per DLP policy. Advanced hunting correlates local-agent activity with endpoint telemetry. |
| Microsoft Execution Containers (MXC) for local agents | Public Preview | MXC now lets IT require local agents to run inside a hardened Windows container — an isolated runtime that reduces exposure from unmanaged execution while standardising protections across the fleet. Combines isolation with centralised policy enforcement. See the Build 2026 MXC section below for the fuller architecture. |
| Capability | Status | Detail |
|---|---|---|
| Agent 365 skills — accelerated onboarding | New | Removes the onboarding "last mile" where builders previously had to manually wire up identity, observability, governance, and secure access to Microsoft 365 data. With Agent 365 skills, developers use natural language directly within their coding environment to request outcomes ("add observability", "integrate this tool") and the platform automatically applies and validates the required configuration — turning a multi-step setup into a guided, outcome-driven flow. See the six-skill breakdown and guard-rail model below. |
| Expanded Microsoft Graph API — Agent Package Management | GA (v1.0) | Two foundational package-management APIs moved from beta to Microsoft Graph v1.0: List packages (GET /copilot/admin/catalog/packages) for a full agent inventory, and Get package details (GET /copilot/admin/catalog/packages/{id}) for per-agent config, ownership, and deployment metadata. These return agents (apps and add-ins are excluded). New: read-only access via Global Reader and AI Reader roles, and application (app-only) permissions for unattended automation. Broader Graph surface also supports inventory retrieval, auditing metadata, and management actions — block, unblock, reassign ownership — for integrating agent governance into existing toolchains. |
| Entra ID Governance for ecosystem partner agents | New | Entra ID Governance for agent entitlements now extends to ecosystem partner agents integrated through the Agent 365 SDK — so entitlement management (scoped permissions, ownership accountability, time-bound access) applies consistently across internally-built and third-party agents. Governs partner agents through access packages, lifecycle workflows, and least-privilege, reducing over-provisioning. |
Source: "Agent 365 Skills: Bring your agents into Microsoft Agent 365 in minutes", Microsoft Community Hub (aarthisk · Jun 22, 2026). Repository: github.com/microsoft/agent365-skills.
Agent 365 Skills are a set of natural-language onboarding skills that run inside the coding assistant a developer already uses — Claude Code, GitHub Copilot CLI, or VS Code agent mode. Instead of reading Microsoft Learn pages and running order-sensitive CLI commands, the developer describes an outcome ("add observability", "wire up WorkIQ Mail and Calendar", "test this agent locally") and the skill applies and validates the change. Every skill follows the same five-beat loop: describe → detect → ask → apply → validate — it detects the project stack, asks only the questions it must, applies the required manifest/config changes, and confirms the build still passes before the session ends.
| Skill | What it does |
|---|---|
a365-setup | Installs the Agent 365 CLI, validates Azure prerequisites, detects the agent stack, and routes to the right onboarding path — in one guided flow. |
make-a365-agent | Registers a Blueprint for agents that need observability or catalog visibility without the full messaging layer. |
instrument-observability | Wires OpenTelemetry and the Agent 365 tracing exporter so agent spans appear in Defender, Purview, and the M365 admin center. Supports OBO, Agentic-User, and S2S authentication modes. |
add-workiq-tools | Connects Work Intelligence (WorkIQ) MCP servers — Mail, Calendar, Word, and more — so the agent can read and act on Microsoft 365 data. |
make-ai-teammate | Adds Messaging and Notifications so the agent can receive messages over Teams, email, and @mentions. |
test-local | Launches the agent alongside AgentsPlayground for local smoke testing — no cloud deployment required. |
Run only the skills an agent needs, or use the make skills to execute all required steps. The project stack is auto-detected — no hand-mapping.
Agent 365 Skills are dev-time code that modifies a project, so their safety properties are worth understanding when you assess supply-chain and dev-environment risk:
Two practical implications: (1) the skills are distributed via GitHub — installed with gh skill add microsoft/agent365-skills — so treat the source repo and version as you would any privileged dev dependency. (2) The instrument-observability skill's three auth modes (OBO = on-behalf-of the signed-in user, Agentic-User = the agent's own Entra identity, S2S = service-to-service) are the same token-flow decisions you govern elsewhere — the skill surfaces the choice, but the security consequence (delegated vs. app-only reach into M365 data) is unchanged. See the Identity page for the underlying credential model.
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.
Source: "Make any agent enterprise-ready with the Agent 365 SDK", Microsoft Community Hub (Aaron Bjork, co-authored by Jeremiah Follis · Jun 2, 2026).
Agents built on the Microsoft AI platform — Agent Builder, Copilot Studio, and Microsoft Foundry — get Agent 365 capabilities automatically, with zero additional developer effort. For agents built on external platforms or open-source frameworks (e.g. the OpenAI Agents SDK), the Agent 365 SDK is the path in: it delivers the same observability, governance, and security, and the Agent 365 CLI provisions the agent identity and registers the agent from day one. A back-office Foundry agent and a customer-facing OpenAI-SDK agent end up managed through the same identity model, observability signals, and policy engine.
| Pillar | Capability | What it does |
|---|---|---|
| Observability | Unified agent registry | Every agent registered through the SDK appears in one Agent 365 registry — ownership, usage, connected tools and knowledge sources, and assigned permissions. Additional signals also surface unmanaged local agents in the same control plane. |
| SOC visibility in Defender | SOC teams use Microsoft Defender telemetry to hunt across agent activity, identify vulnerabilities, and investigate risks across the entire agent fleet. | |
| Governance | Agent lifecycle management | Rules-based policies automatically expire inactive agents, flag ownerless agents, and block risky ones. |
| Onboarding & agent governance | Deploy agents to specific users or groups only after permissions, policies, and reviews are complete. Block, unblock, or remove agents on demand to control availability. | |
| Policy templates | Group existing policies from Entra, Purview, Defender, and SharePoint into reusable templates that apply automatically during agent approval or onboarding. | |
| Tool controls for agents | View, allow, or block tools across the tenant so agents only use approved tools — consistent governance without per-agent configuration. | |
| Security | Agent identity in Entra | The SDK generates an Entra agent identity so policies and role assignments apply to the agent the same way they apply to users. |
| Access control | Agents can be secured by Entra Conditional Access and Identity Protection for runtime protection as agent behaviour evolves. | |
| Threat detection in Defender | Agent activity surfaces in Defender alongside the rest of the estate, with alerts wired into the same incident pipeline the SOC already runs on. | |
| Threat blocking on tool invocation | When you register tools with Agent 365, calls to and responses from those tools are protected by Defender's runtime protection (the ATG path) — blocking high-risk tool calls and actions before they execute. |
For data-security controls, integrate Microsoft Purview APIs to add prompt-based DLP, Data Security Posture Management, Insider Risk Management, and compliance capabilities (eDiscovery, Communication Compliance, Audit, Data Lifecycle Management) — these are opt-in on top of the core observe/govern/secure capabilities.
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.
Microsoft 365 (per user — Agent 365 lives here) · Azure Defender plans (per resource and per tokens scanned — Foundry workload security lives here) · Sentinel (ingestion, retention, and the data lake tier — the deepest agent telemetry lives here). The most common budgeting error is assuming an M365 purchase covers Azure AI workloads or the Sentinel lake. It never does: Agent 365 writes into the data lake but does not include it.
This date has now passed. Before July 1, 2026, Agent 365 was 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 is no longer covered without Agent 365 (since July 1):
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.
The Agent Registry counts published catalogue titles (blind to locally installed agents). Defender's AI Agents page counts cloud agents on its Agents tab, with local agents on a second tab. AgentsInfo sees every platform including local, but needs Agent 365 for the cloud side and retains deleted agents in its snapshot window. Entra agent identities cover only agents holding a directory principal. Always say which screen a number came from — reconciling the four is the finding, not a data-quality bug. For scale context: Microsoft reports visibility of more than 500,000 agents in its own tenant (Customer Zero report, Aug 2026).
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 |
| Locally installed agents (coding CLIs, desktop AI) | ✓ AutomaticPlatform == "LocalAgents" |
⚠ Inventory + endpoint alerts | ✓ Defender for Endpoint | MDE Plan 2 (in E5) — no Agent 365 licence. Risk levels, risk indicators and recommendations need M365 E7, or Agent 365 + MDE P2 |
AgentsInfo: local agents populate on E5 / MDE P2 with no Agent 365 licence (verified in a live tenant, Aug 2026 — seven local agents with full metadata); the cloud-agent side is gated behind Agent 365. CloudAppEvents splits the same way: Copilot interaction verdict rows (JailbreakDetected, XPIA) arrive on E5, while the Agent 365 runtime action types — InvokeAgent, InferenceCall, ExecuteToolBySDK / ByGateway / ByMCPServer — do not exist in the tenant until Agent 365 instruments an agent. An empty result can be a licence boundary, not a data gap.
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 |
| Where it lands | UnifiedAgentObservability in the data lake tier only — full-fidelity spans (prompts, tool arguments, session reconstruction). The connector lists no Log Analytics tables and does not support data collection rules, so the lake tier is a prerequisite, not an optimisation |
| 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.
A second public-preview connector, Microsoft Agent Identities, ingests four identity asset tables into the Sentinel data lake — a connected graph you can trace from owner to identity to blueprint to permissions, and join directly to activity data:
| Table | Represents |
|---|---|
EntraAgentUsers | Human principals responsible for agents — owners, sponsors, administrators |
EntraAgentIdentities | The agent itself as a first-class identity — lifecycle and configuration |
EntraAgentIdentityBlueprints | How agents are constructed and what capabilities they are intended to have |
EntraAgentIdentityBlueprintPrincipals | The service principals tied to blueprints — permissions and execution boundaries |
Column schemas are not yet published on Microsoft Learn — guard columns with column_ifexists() and validate in-tenant before any detection rests on them. And the lake copy does not carry blueprint credential detail (secret and certificate counts) — that lives on the Graph application object, so credential audit remains an Entra exercise, not a Sentinel query.
Since July 2026 there are three distinct query surfaces for agent data: Log Analytics (workspace tables), Defender advanced hunting (via the advanced-hunting workbook connector — AgentsInfo, CloudAppEvents, BehaviorInfo are queried live, never ingested), and the Sentinel data lake (both connectors above). A workbook tile queries exactly one surface — the wrong surface fails rather than degrades. The Agent Telemetry Map on this site charts all of it interactively: seven creation paths, fourteen telemetry destinations, the licence gate on every table, and what each connection actually delivers.
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 |
| MXC for local agents — enforced isolation | June 2026 update: IT can now require local agents to run inside a hardened Windows container, reducing exposure from unmanaged execution while standardising protections across the fleet. Combines isolation with centralised policy enforcement. | Public Preview · June 2026 |
| 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. Since the June 2 release, discovery spans managed Windows and macOS devices and supports more than 35 known agent types (full list on MCP page). Adds exposure risk for local agents — prioritises the riskiest agents by configuration, permissions, and exposure with remediation recommendations. Three views: inventory, exposure map, Advanced Hunting. M365 admin center Shadow AI detection shows unmanaged agents + publishers across the tenant. | Preview · 35+ types |
| 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." On-device runtime protection now in public preview — supports Claude Code, GitHub Copilot CLI, GitHub Copilot app, Codex CLI, OpenClaw and similar Node-based claws via agent-native event inspection plus on-device network-based inspection. Purview integration audits/blocks prompts and tool calls in real time to prevent exfiltration per DLP policy. Coverage expanding. | Public 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.
The developer-side platform in full: capabilities, agent lifecycle, and what to enable for SecOps. (Merged from the former Foundry page.)
| Stage | Developer (Foundry Control Plane) | IT/Security (Agent 365) |
|---|---|---|
| Define | Inherit enterprise policies, set guardrails, configure evaluators | Define enterprise policies, set allowed templates |
| Build | Develop with SDK, run evals, integrate Content Safety, AI Red Teaming | — |
| Approve | Deploy agent to Agent 365 (triggers IT approval workflow) | Onboard agent, apply guardrails, enforce policies |
| Operate | Monitor performance, quality, cost, risk via Foundry dashboards | Monitor all deployed agents: usage, performance, risk |
| Govern | Continuous evaluation, tracing, debugging, A/B experimentation | Manage policies (access, data security, compliance), defend against threats |
Foundry Control Plane provides structured evaluation of agents before and after deployment. Evaluations run locally during development, in CI/CD on every commit, and in production against real user inputs.
| Category | Evaluators | What they measure |
|---|---|---|
| Quality | Groundedness · Coherence · Fluency · Relevance · Retrieval Score · Similarity · NLP Metrics (F1) | Is the agent response accurate, relevant, and well-formed? Does it faithfully use grounded sources? |
| Risk & Safety | Jailbreak Defect · Hate and Unfairness · Sexual · Violence · Self-Harm · Protected Material · Ungrounded Attributes · Code Vulnerability | Does the agent produce harmful, unsafe, or legally problematic outputs? Can it be manipulated? |
| Agent-Specific | Intent Resolution · Tool Call Accuracy · Task Adherence · Response Completeness | Does the agent correctly understand user intent, use tools accurately, and complete tasks as instructed? |
Test data: Generate adversarial and non-adversarial test datasets using the Foundry evaluation client library, or upload your own domain-specific prompts.
Evaluator: Metric instructions + Azure OpenAI model → scores each response with reasoning for human review.
CI/CD integration: Batch evaluation runs on every check-in and deployment. Production evaluations run against real user inputs using traces to debug issues.
A/B experimentation: Compare models, prompts, and workflows at scale before committing to a change.
The Foundry Control Plane includes a built-in AI Red Teaming Agent powered by PyRIT integration. Distinct from running PyRIT manually — the Foundry Red Teaming Agent is a managed, scheduled service that automatically probes your agents for content risks and security vulnerabilities as part of the development lifecycle.
| Capability | Detail |
|---|---|
| Automated content risk scans | Scheduled adversarial probing across harmful content categories, jailbreak attempts, and sensitive information extraction |
| Evaluate probing success | LLM-as-judge scoring on whether attacks succeeded — not just whether the attack ran |
| Reporting and logging | Structured findings linked to OWASP LLM Top 10 categories; exportable for compliance evidence |
| PyRIT integration | Built on the same Microsoft PyRIT framework — 53+ adversarial datasets, 70+ converters, 6 attack strategies |
| When to use | Pre-deployment (gate on result), post-deployment (continuous monitoring), after system prompt changes |
The Foundry Red Teaming Agent is a managed service — scheduled, governed, and integrated with Foundry observability. PyRIT standalone (Playbook 06) is a flexible research library you wrap yourself for custom CI/CD pipelines. For organisations using Foundry, the managed agent is the right starting point. For custom agents on other platforms, PyRIT standalone is the tool.
Azure AI Content Safety is integrated directly into the Foundry Control Plane, providing the same configurable content filters used by Microsoft's own Copilot products. Applied at both input (prompt) and output (response) layers.
User prompt → Content Safety evaluates → Modified/filtered prompt → Foundry model → Filtered response → App response. Purview data governance and Defender threat detection run alongside this pipeline — not instead of it.
Foundry Control Plane provides comprehensive tracing of every agent action — enabling debugging, performance optimisation, and accountability. All traces are stored and queryable, forming an audit trail of what the agent did and why.
| Layer | What is traced | Why it matters for security |
|---|---|---|
| Model inference | Every LLM call: model, tokens, latency, prompt, response | Detects unusual inference patterns, cost anomalies, model substitution |
| Tool invocations | Every tool/MCP call: name, parameters, result, duration | ATG blocks happen here; traces show what was attempted vs blocked |
| Memory operations | Reads/writes to agent memory (Dataverse) | Memory is a persistent data store — sensitive context accumulates over sessions |
| Agent-to-agent | Orchestrator calls to sub-agents in multi-agent workflows | Lateral movement risk; trust propagation between agents |
| User interactions | Session start/end, message counts, satisfaction signals | Behavioural baseline for ID Protection anomaly detection |
| Control | Detail |
|---|---|
| Managed VNet | AI hub and projects run within a managed virtual network. Private endpoints for all connected resources (Azure Storage, Key Vault, Container Registry, Foundry models). No public internet exposure for managed resources. |
| ExpressRoute / VPN | On-premises connectivity to Foundry via ExpressRoute or VPN Gateway to your Azure VNet. |
| Credential-less storage | Foundry supports credential-less access to Azure Storage and Foundry IQ using managed identity — no stored secrets, no rotation required. Generally available. |
| Customer-managed encryption | Add your own encryption layer on top of Microsoft-managed encryption. Customer-managed key (CMK) for Blob Storage, Foundry IQ, and Azure CosmosDB resources. |
| Entra Agent ID | Every Foundry agent is automatically provisioned with an Entra Agent Identity. CA for Agents, ID Protection, and lifecycle governance apply at the identity layer. |
The new Foundry projects model significantly simplifies the previous Hub → Project → Resource hierarchy that made setup and coding complex.
| Old: Hub + Projects | New: Foundry Projects | |
|---|---|---|
| Entry point | AI Hub → Projects → Multiple SDKs | Single Foundry Resource → Foundry SDK or API |
| Resources | Many different resources needed upfront | Multi-tenant services by default; attach dedicated resources optionally |
| SDK | Azure ML SDK, Azure OpenAI SDK, various others | Single Foundry SDK (or Azure OpenAI SDK for compatibility) |
| Optional attachments | All required | Azure OpenAI, AI Search, Storage, Fabric, Azure Monitor — attach as needed |
| Scale | Complex enterprise configuration required from start | Start simple, add enterprise controls as needed |
Microsoft Purview Data Security Investigations (Preview) is a three-stage workflow for investigating data security incidents involving AI — enabling security teams to find impacted data, analyse risks, and coordinate remediation without moving data between tools.
| Stage | What you do | Key capability |
|---|---|---|
| 1 — Identify | Find incident-relevant data across the M365 estate | Search documents, emails, Copilot prompts/responses, and Teams messages. Launch directly from a Purview IRM case or a Defender XDR incident — pre-scoped to relevant data. |
| 2 — Investigate | Analyse impacted data for security risks | AI-powered content categorisation, severity assessment, vector search (find all content related to a subject based on context and meaning, not just keywords), key risk identification. |
| 3 — Mitigate | Coordinate remediation across teams | View data/user/activity correlations, create a mitigation plan, add reviewers from partner teams securely, use incident learnings to improve security practices. |
Advanced Hunting (AgentsInfo, CloudAppEvents) gives you metadata and telemetry. Purview Data Security Investigations gives you the actual content — prompt text, response text, document content, emails — with AI-powered analysis to understand what sensitive data was exposed and to whom. The two tools are complementary: use Advanced Hunting to detect the incident, Purview DSI to investigate what was actually in the data.
The AI Baseline assessment in Microsoft Compliance Manager provides an out-of-the-box trust assessment that automatically evaluates your AI deployment against global AI regulations (EU AI Act, NIST AI RMF) and surfaces gaps with recommended remediation actions.
Agent 365 provides a managed MCP tooling gateway that integrates certified tools for a consistent developer and governance experience. These tools are available to agents built with any SDK — Foundry, Copilot Studio, LangChain, or custom.
| Category | MCP Tool (Work IQ naming) | Key capabilities | Typical use |
|---|---|---|---|
| Search & AI | Work IQ Copilot (was: Copilot Search) | Chat, multi-turn conversations, grounding with files | Knowledge retrieval |
| Business Data | Dataverse | Dynamics 365 CRUD operations, domain actions | Business workflows |
| Communication | Work IQ Calendar · Work IQ Teams (was: Outlook/Teams MCP) | Messaging, meetings, channel operations | Collaboration |
| Content & Files | Work IQ SharePoint Lists · Work IQ SharePoint & OneDrive (Frontier) | Upload, search, metadata management, lists | Content management |
| Identity | User Profile | Manager reports, profile lookup, org chart | Organisational context |
| Documents | Microsoft Word | Create/read documents, comments | Document workflows |
⚠️ Note: Microsoft is renaming MCP servers to Work IQ branding. Existing connections using previous names (e.g. Microsoft Teams MCP Server) remain supported. For new connections, use the Work IQ named servers. Source: Microsoft Learn — Work IQ MCP overview.
Central admin control: Admins manage MCP servers via Microsoft 365 admin center — blocking a server blocks it for all users and agents.
Scoped permissions: Each MCP server = one app permission requiring admin consent during onboarding.
Observability: Full tool call tracing — tool invoked, parameters, execution outcome.
Security: Rate limits, payload checks, security scans on all MCP traffic.
Admin tasks: View activated MCP servers, allow/block servers, apply scoped permissions.
Source: Agent 365 Training Day 3 — Module 5
| Step | Action | Detail |
|---|---|---|
| 1 | Enable Internet Access traffic forwarding | Global Secure Access → Traffic forwarding → Enable Internet Access profile. Routes internet traffic through GSA client for inspection. |
| 2 | Assign users and groups | Assign the Internet Access profile to target users/groups. Can scope to specific users for phased rollout or POC before tenant-wide deployment. |
| 3 | Install the GSA client | Deploy Global Secure Access client to user devices. Verify in Connections view: Status should show connected, Channels configured. |
| 4 | Access Shadow AI discovery | Global Secure Access portal → App discovery → Use Generative AI apps filter. See detected AI applications with usage statistics and risk scores. |