Agents are currently a hot topic, and on everybody’s plate. The question I get asked the most: where are they all coming from, and how can it be that we haven’t even really started with the topic yet and already have over 200 agents in our tenant? Unfortunately, that question isn’t that easy to answer, because Microsoft considers multiple objects to be “agents”.
This article shows the full journey of an agent, but focuses on the last step: real-time protection with Defender. It’s part of a blog series I want to complete over the coming months, where I’ll write about each step in the life of an agent in much more detail.
An agent that can read your data, call your tools, and act on natural-language instructions is a genuinely useful thing. It’s also a new attack surface, and one that behaves nothing like a user or a server. Now, Defender extends into the agent runtime, with threat detection and real-time protection for agents managed through Agent 365.
Before getting into the Defender part, it’s worth walking the whole path an agent takes through a tenant, because each stage handles a different problem.
Step 1: The agent gets created
Agents enter your tenant from a lot of directions. Some are built in-house with Copilot Studio or Microsoft Foundry. Some are declarative agents put together in the Microsoft 365 Copilot Agent Builder by someone in the business. Others are acquired ready-made from the Agent Store and Microsoft Marketplace, or built on entirely non-Microsoft platforms.
This variety is the root of most of the governance problem. It is not that agents are hard to secure. It is that they arrive faster than anyone is tracking them, and the ones nobody registered are exactly the ones you would want to look at first.
Step 2: Agent 365 manages it
Agent 365 is the control plane that catches all of this. The registry inventories every agent regardless of where it came from, and discovery leans on Defender and Intune signals to surface the shadow AI nobody declared. Alongside the inventory you get usage and behaviour telemetry, the agent map showing what connects to what, and onboarding with IT oversight.
Worth being precise about one thing: the registry is an inventory, not a catalogue you shop from. Acquisition happens in the Agent Store and Marketplace. Agent 365 is what governs agents once they are running.
Step 3: Entra Agent ID gives it an identity
Managing something you can see still requires deciding what it is allowed to do, and that is the identity layer. Entra Agent ID gives each agent a real identity (and a unique object ID) in the tenant. Blueprints for applying consistent policy at scale, and a sponsor, the human who is accountable for that agent and who gets contacted when it misbehaves.
Because these are proper Entra identities, the controls you already run apply to them: Conditional Access policies targeting agents, ID Protection risk detections, access packages, lifecycle workflows, audit logging. You can basically use a lot of your beloved Entra-features for your agents.
Which brings us to the gap. Identity governs what an agent may do. It does not tell you what the agent is actually doing, right now, in the middle of a task, or stop it when a legitimate agent with legitimate permissions is manipulated into doing something harmful. That is the runtime problem, and it is Defender’s job.
Step 4: Protecting it
Defender continuously monitors agents managed through Agent 365, analyzing telemetry, tool usage and execution patterns across the agent lifecycle. The detections cover the threats specific to this domain:
- Jailbreak attempts and cross-prompt injection (XPIA)
- Malicious content propagation
- Secrets and credential leakage
- Evasion techniques
- Suspicious user access to agents
- Unauthorised access to sensitive information
For agents built with Copilot Studio and Foundry, Defender goes a level deeper and evaluates the model prompts and responses themselves, rather than only the surrounding activity.
Everything surfaces as near-real-time alerts in Defender XDR, so the investigation experience is the one your SOC already uses — the same incident view, the same Advanced Hunting, the same workflows. Detection tells you what happened. Real-time protection stops it happening, and this is the piece that went generally available for Agent 365 tooling servers in late July 2026.
Defender integrates directly with Work IQ MCP and custom MCP servers. When an agent invokes a registered tool or receives a tool response, Defender evaluates that interaction against your configured policies before it executes, and blocks it inline if it is judged risky. The agent’s developer does not have to implement any of this: no custom security logic, no SDK calls in the agent code. It happens in the execution flow.
Inspecting tool responses is the part I find most valuable. Malicious instructions can be embedded in what a tool returns — a web page, a repository, an external data source — and an agent that consumes that output without validation will happily act on attacker-controlled instructions in its next step. Catching it at that boundary closes off a whole category of attack.
One scoping caveat: real-time protection applies to agents using tools supported in Work IQ MCP. Agents relying on unsupported tools, or not integrating with MCP at all, fall outside it. Detection still covers them; inline blocking does not.
Let’s get this going
Roughly, in order:
- An Agent 365 license: You need either standalone A365 license or it’s included in E7.
- Roles: Security Administrator for the Defender and Entra side, Power Platform Administrator for the Power Platform side.
- Security for AI agents enabled in Defender: In Defender, Settings, Security for AI, Get Started -> Turn on Agent 365 (on by default when you assign the license) and the M365 Connector (check that all options are ticked). That was easy. On the Copilot Studio part, we’ll focus just below.
Almost done — and I can contact each Power Platform admin directly via Teams.
Click on Copilot Studio, Enable Real-Time Protection and save that URL for later.
- Move over to the Power Platform Admin Center: https://admin.powerplatform.microsoft.com
- Go to Security, Threat detection, Microsoft Defender – Copilot Studio Agents, Enable Microsoft Defender – For all Copilot Studio Agents in the tenant
- Go to Manage and see all your environments. Select one or multiple and click on Set up below.
- Activate Allow Copilot Studio to share data with a threat detection partner. Under Endpoint link, paste in the saved URL from Defender:
- Move over to the Entra Admin Center, App Registrations, new Registration. Give it a name and create it.
- Certificates & Secrets, Federated Credentials, Add Credential. Select Other issuer. Under Issuer, copy in: https://login.microsoftonline.com/{tenantId}/v2.0 -> replace {tenantID} with your real Tenant ID (can be found in Entra Main Page)
- For the value it gets a bit complicated. Go to the Microsoft Learn page: Enable external threat detection and protection for Copilot Studio custom agents (preview) – Microsoft Copilot Studio | Microsoft Learn
and copy that Powershell Script from step 5. Open a Powershell ISE, put in your Tenant ID and that URL you saved:
- Run that script. It will output two values: The tenant ID and URL in base 64. Leave that window open.
- Now take this and put in your values here:
/eid1/c/pub/t/{base 64 encoded tenantId}/a/m1WPnYRZpEaQKq1Cceg–g/{base 64 encoded endpoint} - Go back to the Entra Admin Center and paste it in under Value. Give it a name and click on Add.
- Go to the App registration overview and copy the Application ID. Go back to the Power Platform Admin center, paste it in under Azure Entra App ID and save:
- Head back to Defender, paste the Application ID there too and (hopefully) Copilot Studio shows as connected:
- Under Realtime protection, create a real-time protection rule for WorkIQ and Custom MCP servers.
- Defender for Endpoint in active mode (also the -AiAgentProtection) for local agents running on endpoints (Defender for Endpoint Plan 2 is needed!)
Two things to know going in: some capabilities currently route through Defender for Cloud Apps onboarding, which Microsoft has flagged as temporary until it moves into the Agent 365 experience proper. And prompt evidence collection: including the prompt snippet that triggered a detection as evidence in the alert: is on by default. Useful for investigations, but worth a conversation with whoever owns data protection at your organization before you roll it out broadly.
Hunting and investigation
Beyond the alerts, agent activity lands in Advanced Hunting, with tables such as AIAgentsInfo available for queries. Defender records agent activities, risky behaviours and blocked actions, which gives you the raw material for detection engineering, threat hunting and compliance reporting rather than just an alert queue.
For anyone who has investigated an identity incident in Defender, the shape of this is familiar: alert, incident, root cause, blast radius. The novelty is what sits at the centre of the graph.
Conclusion
Each layer here answers a different question, and skipping one leaves a gap the others cannot cover. The Agent Store answers where does the agent come from. Agent 365 answers what agents do we have. Entra Agent ID answers what is this agent allowed to do. Defender answers what is it doing right now, and should we stop it.
If you are starting from zero, do it in that order. Inventory first: that count usually surprises people. Then identities and sponsors so every agent has an owner and least-privilege access. Then turn on Defender, because runtime protection.
The encouraging part is that none of this requires a new operating model. It is the same platform, the same admin centers, the same SOC workflows, extended to a new kind of identity. Agents are new. Governing them, thankfully, does not have to be.
Links
