How Microsoft Agent 365 works
Agents can now have their own identity, email, OneDrive and Teams accounts, and collaborate just like coworkers. Microsoft Agent 365 lets you onboard agents, give them the policies and knowledge they need, and let them work in parallel with you to handle tasks like procurement, approvals, research, and updates using the same Microsoft 365 tools you already rely on. As your use of agents grows, keep full visibility and control. See what they've worked on and understand their impact across your organization as an agent manager. If you're in IT, you have full visibility and control over access permissions and agent relationships. You can manage all agents from a single unified control plane with the same tools you use now to manage users. Jeremy Chapman, Microsoft 365 Director, shares how you can adopt autonomous agents at scale across your organization. Agents that work alongside you. Assign tasks and get full visibility into what they have worked on using Microsoft 365 tools like Teams and OneDrive. See it here with Microsoft Agent 365. Automate workflows. Agents access your data and tools to execute complex tasks. Take a look at Microsoft Agent 365. Understand agent impact. Map their actions, connections, and interactions in Microsoft 365 workflows. Get started using Agent 365. QUICK LINKS: 00:00 — Microsoft Agent 365 01:04 — Agent capabilities 02:48 — Visualize the agent’s impact 03:23 — How it works 04:48 — Agent 365 control plane 07:31 — Zero in on risks 08:18 — Agent map 09:10 — Wrap up Unfamiliar with Microsoft Mechanics? As Microsoft’s official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft. Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries Talk with other IT Pros, join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog Watch or listen from anywhere, subscribe to our podcast: https://microsoftmechanics.libsyn.com/podcast Keep getting this insider knowledge, join us on social: Follow us on Twitter: https://twitter.com/MSFTMechanics Share knowledge on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/ Enjoy us on Instagram: https://www.instagram.com/msftmechanics/ Loosen up with us on TikTok: https://www.tiktok.com/@msftmechanics Video Transcript: -What if an AI agent was truly autonomous, working independently alongside you, with its own email and OneDrive account, capable of joining Teams meetings and conversations to get work done? It means, as a user, you can onboard and manage agents with a unique identity, the right information access, and skills to work on your behalf. These agents can perform the tasks that you define, working autonomously and work with you using the same managed apps and services in Microsoft 365 that you use. And as an IT admin, you have granular control over what agents can do, and knowledge sources they can access. Along with end-to-end visibility into agents in your environment, no matter where they’re created. In fact, with the Agent 365 control plane, we’re extending the same familiar administrative surfaces that you use now to manage people for full visibility, control, and management of agents, while introducing new capabilities. -So, first, let’s start by looking at what Agent 365 can do from a business user’s perspective. In this case, a coworker has created a procurement agent. And our IT team has approved it, and made it available in our company’s agent store. Now, as a procurement manager, I can find the agent and also set it up with just a couple of clicks. Then once it’s up and running, it contacts me in Teams and asks what I’d like it to do and which tasks to perform. As a procurement agent, it recommends that I give it supplier policies, approved supplier lists, and a procurement playbook. So I’ll do that here with my Teams policy guidelines and just type, use this policy guide for your actions. And then / reference my Zava procurement file. -Now the agent has what it needs to start working. For interoperability with me, other people, and other agents, it has its own suite of Microsoft 365 apps and a unique account to work on its own. In fact, as an order request comes in from a customer for new laptops, the agent reasons over that request using the instructions I provided. And it can also use contextual business information across Microsoft 365 with Work IQ to find these suppliers, their SLAs, pricing from recent orders, and related documents. Based on the fulfillment time, it even recommends a supplier and asks me if it should proceed. Once I confirm, it creates the purchase order for the laptops and logs that into our purchasing tracker Excel spreadsheet in SharePoint. And right from the comments, like I would at mention any coworker, here I’ve at mentioned the procurement agent for status updates. Agent 365 also makes it easier to visualize the agent’s connections, activities, and impact. -As a business user, you can see details about the agent, who it’s managed by, its skills, and what it works on in the agent card. You can also see where it fits in the organization, and who it frequently interacts with. Then in the agent activity view, you’ll find its recent sessions with details on actions performed. And clicking into any session activity expands on what was done, the information that was used, and the steps performed to complete its tasks. This is a fully autonomous agent with everything it needs to be effective. In fact, let’s break down the mechanics of how the agent was able to do what it did when it used the Agent 365 control plane. -The first behind the scenes, once created, the IT approved agent is assigned its own identity in Microsoft Entra and granted access to specific knowledge sources. It’s provided with its own email, calendar, OneDrive, and Teams account, and other services in Microsoft 365. Importantly, it’s also connected to Work IQ, which provides the agent with additional context that’s specific to the jobs it’s performing and the activities by people and other agents around it. But has what it needs to interop with you in the tools that you use every day to get work done. -Importantly, because it runs on the Agent 365 control plane, it works according to your organization’s security and compliance requirements. For example, least privilege access control ensures that the agent can only access defined content, and nothing more. Also, access can be blocked in real-time based on Conditional Access policies that you have in place. Integrated data security prevents data loss, adhering to your protection policies as it works. And there are also safeguards to keep the agent resilient to targeted attacks. That’s how agents can be onboarded and how they work. Next, as an IT admin, Agent 365 gives you more visibility and control to manage the breadth of agents in your environment, let me show you. -The Agent 365 control plane in the Microsoft 365 admin center provides an overview of all agents in your organization, with a breakdown by publisher and platform. You can also see whether they were built internally using Copilot Studio, Microsoft Foundry, non-Microsoft platforms, and more. As well as how they’re being used. Below that are recommended top actions to take control, so that you can prioritize your time. Next, to see all of your agents in one place, there’s a complete registry, which pulls in details for security risks, activities, and agent performance into one view. Each agent has comprehensive details. In addition to configuration options, like the data and tools it can access. Information stores it can read from, provisioned compute, graph connectors, tools, and knowledge sources. Then security and compliance provides all of the details for enabled policies with that agent across Microsoft Purview, Microsoft Entra, and Defender. -Next, in permissions, it goes a step further to display which memberships it has across groups and teams, applications it can access, the SharePoint sites it can use. And detailed permissions across graph API calls. Finally, activity displays information about the agent usage, exceptions and active users. And before agents are available for people to use, as an admin, you’re in full control of validating and approving which agents will appear in your organization’s agent store, here’s how. -From requests, you can review agents submitted for approval. For example, drilling into this product backlog agent, you can check its configurations, the data it can access, security and compliance protections. And the detailed permissions requested. If everything checks out, you can approve and activate the agent. Then select the right users and groups to access it. In this case, I’ll just keep Mona Kane as the requester. From there, I can apply uniform guardrail policies using customizable templates, like this one, to restrict content sharing. These policy templates leverage Microsoft Entra for access controls, Microsoft Purview to secure data. As well as SharePoint policies, like this one, to enforce specific restrictions on external sharing at the agent level. -Then I can just review and accept the permissions for the agent, and finally confirm to grant access to its requester. Next, for your running agents, as we saw in the Agent 365 overview, the service automatically and continuously evaluates potential agent risk to alert you of any actions to take. Here, I can zero in on agents with risks. For example, I can see that this comms agent has two risks identified. And when I dig in to see why, it looks like this agent has abnormal sign-in frequency, and was accessed by a user flagged as risky. It’s possible that their account was compromised. And in these cases, Microsoft Entra Conditional Access will automatically block risky agents from accessing resources. And as an admin, you can also block the agent right from here. So it’ll be disabled immediately for current users, and won’t be discoverable for new users. -Those were single agent operations, but as more agents enter your agent ecosystem with connections to other agents, tools, and knowledge sources, you can see these relationships using the Agent Map. This helps you visually map all agents in your environment across platforms. Importantly, you can see agent connections and multi-agent workflows. Then quickly spot alerts, like this one, for high exception rates. Then drill into view its details, and also take necessary actions. And while today I focused on the experience in the Microsoft 365 admin center, the Agent 365 control plane extends to role-specific views for agents in Microsoft Entra for agent identity and access management, Microsoft Purview for data security protections. And Microsoft Defender for threat detection, investigation, and response. -And that’s how the new Agent 365 gives you a single control plane to manage agents within the same familiar admin experiences that you’re using today. To get started, from the Microsoft 365 admin center, make sure the Frontier Program is enabled for early access to new AI capabilities. Keep watching Microsoft Mechanics for the latest updates, and thanks for watching.Agent 365 | Identity & Access Controls in Entra
Surface agents across AWS Bedrock, Google Vertex, Databricks, and Salesforce in one registry, assign Entra Agent IDs via CLI or SDK, and enforce least-privilege access through Conditional Access policies and Agent Blueprints, all without rebuilding your existing identity infrastructure. Lock down agent activity with sign-in logs that capture every authentication attempt, policy hit, and failure. Govern agents as first-class identities alongside your users, apps, and devices, and draw a hard line between managed and unmanaged AI in your organization. Vince Smith, Microsoft Entra Principal Product Manager, shares how to establish full visibility, access control, and lifecycle governance for AI agents using Microsoft Entra and Agent 365. Transform unmanaged agents into a managed agent identity. CA policy enforcement, lifecycle controls, & full audit trail—start with Agent ID in Microsoft Entra. One Agent blueprint. Multiple agent identities. Use Agent blueprints in Microsoft Entra to enforce least-privilege access for agent identities at scale. Start here. Lock down agent activity in Microsoft Entra. Get full audit visibility into every sign-in, Conditional Access decision, and failure reason. See how it works. QUICK LINKS: 00:00 — Visibility and control with Agent 365 01:39 — Multi-platform registry sync 02:29 — Assign Agent ID 04:14 — Agent Blueprints 05:24 — Conditional Access for agents 06:24 — Sign-in logs audit trail 07:03 — Unblock the agent 07:54 — Wrap up Link References Check out https://aka.ms/EntraforAgents Unfamiliar with Microsoft Mechanics? As Microsoft’s official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft. Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries Talk with other IT Pros, join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog Watch or listen from anywhere, subscribe to our podcast: https://microsoftmechanics.libsyn.com/podcast Keep getting this insider knowledge, join us on social: Follow us on Twitter: https://twitter.com/MSFTMechanics Share knowledge on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/ Enjoy us on Instagram: https://www.instagram.com/msftmechanics/ Loosen up with us on TikTok: https://www.tiktok.com/@msftmechanics Video Transcript: -Ensuring agents don’t operate unchecked in your environment means making sure their access to data and apps, along with other agents and resources, is appropriately scoped, and no more than necessary, so they’re never overprivileged. Agent 365 gives IT and security teams a unified control plane for agent activity. They can work together using the tools they already work in every day to see which agents are in use, understand the risk, and act before issues escalate. Today, in part 3 of this Agent 365 series, we look at how, as an identity admin using Microsoft Entra, you can establish the critical foundation to prevent agents from being both overprivileged or running without the right level of visibility. -This all starts with Agent 365, which gives you visibility into your agents, control over what they can access, and governance across the entire lifecycle. As a developer, you can use the Agent 365 CLI and SDK to create and integrate an Agent ID into your agent. This ensures your agents can be managed across their lifecycle, with continuous risk evaluation and least privileged conditional access controls in Microsoft Entra, ensuring that agents can only connect to and act on the resources they truly need, for as long as they need, no more, no less. -Just like with your users and apps today, with Agent ID, agents become explicitly manageable and governable, including conditional access policies and access packages. And by assigning an Entra identity to your agents, you establish a clear boundary between managed and unmanaged AI, which makes it much easier to detect which agents need to be brought under control. Let’s start in the Microsoft 365 Admin Center to see this in action. As an IT admin, you can access Agent 365 controls to view your agents, find unmanaged AI in use, and configure tools and settings. I’m in the Agent 365 overview page, where I can find top-level insights and metrics, as well as common actions. In fact, the Registry sync controls let me configure these options, so let’s take a look. And you can see that we’ve already configured sync for AWS Bedrock and Google Vertex, which gives us visibility into agents running on those platforms. -Just to show you what’s behind this and your options, I’ll click Connect a platform. And under External platforms, we can see Bedrock and Vertex here, along with Databricks Genie and Salesforce AgentForce. The respective agents will peer in the agent registry once I sync from these platforms. That said, while we were able to see the agents from those platforms running in our environment, without respective Agent IDs, we won’t have visibility into exactly what those agents are accessing. In fact, here we can see that all of our Amazon Bedrock agents are currently unmanaged. And when I click in, we can see a few details about the agent creation date and publisher, but not much else. So we know these agents exist, but again, without an Agent ID, we don’t know exactly what these agents are accessing to be able to apply the right controls for their needs. -Practically speaking, our first step here is to work with the unmanaged agent creators to get their agents an Entra ID. This is where, as a developer creating and updating agents, we can use the agent 365 CLI and SDK to create an assign and Agent ID, which also includes an Agent Blueprint. I’ve used a simple prompt here to generate the code and enter configuration needed. The cool thing about Agent Blueprints is that permissions granted on the blueprint can be inherited by all agent IDs using that blueprint, and I’ll explain more about this in a moment. And because this is standard OAuth, it is interoperable across agent platforms. In fact, the agent we’re updating is the one I showed earlier that’s running on AWS Bedrock. And once the agent is republished to Agent 365, it’s ready for management. -In fact, going back to the agent registry in Agent 365, viewing the details of the agent, we can move over to the right and expand this field for identity information. We can see it has an Agent ID along with a Blueprint ID, which wasn’t there when we looked at the unmanaged agent card before. And scrolling back up and opening the Security tab, I can see that the agent already has default protections applied from Microsoft Purview and Entra, including sensitive data protections and compliance evaluation as part of the Agent 365 platform. Because the agent is an object in our directory, provided we are entitled with the right management permissions, we can grant the appropriate level of access and get visibility into its details and activities. -I’ll start by first looking at what resources the developer has configured for the agent to access. In the agent identities page, we can see our agent. Importantly, this agent now has an agent sponsor assigned. This is the person responsible for the agent, and can be the agent builder themselves or someone they designate. And viewing its access and granted permissions, we can see a list of the requested permissions the agent has configured. Notice that the grant source is inherited from the parent, which is our Agent Blueprint. A blueprint is the template for a class of agents. It holds the credentials that associated agents use for authentication. The credentials can be managed in Entra, or federated outside of Entra, or even system managed, such as with an Azure Managed Identity. It also provides a way to define identity and permissions for agents at scale. -Here we see in this case, the agent’s permissions aren’t set directly on the agent itself. They come from its parent blueprint. The first permission for Agent365.Observability is a default to capture agent telemetry. And under that, you’ll see Microsoft Graph permissions to read groups, users, and mail. Under Developer settings in the Manifest, we can view and optionally edit the details as JSON that we saw earlier in the code. -As an Entra admin, I can control who is able to consent to the agent’s permissions, which gives me both security and scale, but I also want defense in depth. In our organization, as a blanket control, we have conditional access policies to block access to all unverified agents. Under conditional access, when I click into the AWS Bedrock policy, you’ll notice that this policy targets all agent identities and blocks their access to Entra-managed resources by default. To give our now verified agent access, we’ll need to exclude it from this conditional access block policy. -Before we do that, I’ll show you this policy in action from the agent testing experience in Amazon Bedrock. I’ll have the agent perform a simple look up for a user account in our tenant. And you’ll see that it’s blocked from retrieving the user information. In fact, if I move over to this agent’s logs, I can see all the invalid grant errors. And expanding on the first one and then scrolling down to the error description, it gives more specific detail about the conditional access block and what happened. -Now, if I move back to Microsoft Entra and look at the sign-in logs, we can see all of the sign-in activities for this agent. I’ll expand the same request we just saw in the Bedrock portal and move into this specific instance. And you’ll see the failure reason is exactly what the agent developers saw in Bedrock. In fact, digging into this Conditional Access tab, we can see the corresponding policies listed that apply to this agent, along with AWS Bedrock policy on top and the corresponding failure result. Now let’s look at how we can unblock this agent. As a Microsoft Entra administrator, once we verify that this agent’s identity is established and its permissions are appropriate, we can exclude it from our conditional access block policy to allow it access. -Back in our conditional access policy settings, under Assignments, I can set up an exclude condition. Then I search for my agent by its name. Here I’m typing, “widget.” There it is. Now I’ll select it and confirm, then I just need to save my policy. That’s it. With our exclusion setup, the agent will be able to perform its operation with least privileged access and Entra. So let’s test it out. Back in the Amazon Bedrock portal, I’ll run the same prompt that failed last time, our account look up. And as you can see, this time it works, and it was able to access and display the account information for this user from our tenant. -There we have it. That’s how easy it is to integrate Entra Agent ID into your agents and bring them under management. Agent 365 with identity and access controls in Microsoft Entra provides IT and security teams the management and visibility to assess and respond to agent risks. This lets you efficiently integrate agents into your existing systems and infrastructure as first-class identities, alongside existing users, applications, and devices. To learn more, check out aka.ms/EntraforAgents. Keep checking back to Microsoft Mechanics for the latest tech updates, and thanks for watching.Agent 365 | Security Operations in Defender
Triage high-severity alerts as IT in the Microsoft 365 admin center, then pivot into the full incident graph as a SOC analyst in Microsoft Defender. Block malicious tool invocations the instant they fire and catch jailbreak attempts on Copilot Studio agents before they take hold. Trace a compromised user back to suspicious agent activity, then trigger Microsoft Entra conditional access to revoke the session and force a password reset straight from the incident. Hunt overpermissioned agents with pre-built advanced hunting templates — including one that exposes every agent running MCP tools on the maker’s standing credentials — and pull risky builds from the Agent Store using the Agent Registry. Spencer Berg, AI & Security Product Manager, shares how to turn agent risk signals into coordinated remediation across Defender, Entra, and the Microsoft 365 admin center. One agent. Two security views. IT admins triage critical alerts in the M365 admin center. SOC analysts dig into the full incident graph in Microsoft Defender. Try Agent 365. Real-time agent defense. Microsoft Defender blocks malicious tool calls mid-execution and flags persistent jailbreak attempts on Copilot Studio agents the moment they happen. Watch it in action. Pull a risky AI agent from the Agent Store. Open the Agent Registry in the Microsoft 365 admin center, block the agent, and cut access for current users until the maker resubmits a safer build. See it here. QUICK LINKS: 00:00 — Stay in control with Agent 365 00:40 — Gain visibility with unified control plane 01:48 — Unified IT & SOC agent view 02:54 — Real-time blocking and jailbreak detection 04:08 — Auto-revoke via Entra conditional access 04:32 — Prevent future incidents 05:28 — Advanced hunting for AI agents 06:43 — Block risky agents 07:15 — Wrap up Link References Check out https://aka.ms/Agent365SecOps Unfamiliar with Microsoft Mechanics? As Microsoft’s official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft. Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries Talk with other IT Pros, join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog Watch or listen from anywhere, subscribe to our podcast: https://microsoftmechanics.libsyn.com/podcast Keep getting this insider knowledge, join us on social: Follow us on Twitter: https://twitter.com/MSFTMechanics Share knowledge on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/ Enjoy us on Instagram: https://www.instagram.com/msftmechanics/ Loosen up with us on TikTok: https://www.tiktok.com/@msftmechanics Video Transcripts: -What if your next Sev 1 security incident isn’t a compromised user, but instead an autonomous agent, chaining actions across systems you didn’t even know it could reach? In the agentic era, SOC teams aren’t just defending endpoints or identities. They’re defending a machine-speed execution layer that collapses boundaries and turns small gaps into full attack paths. When agents act on their own while logged in as a user, on-behalf-of activity becomes user impersonation. They can access and interact with Teams, email, other internal apps, and your users’ devices. This blurs the lines between human and agent activity. So how do you gain visibility into these activities and stay in control? It starts with the fundamentals of agent defense, knowing what’s running, controlling what it can access, and seeing what it’s doing in real time. Agent 365 brings all these defense areas together through a unified control plane. -The Microsoft 365 admin center provides centralized inventory and governance of agents and tools. Entra establishes strong identity with least-privilege access and clear ownership. Defender delivers runtime protection and deep observability with end-to-end activity tracing and detection. And Purview enforces data protection and posture by monitoring how agents interact with sensitive information. Together, these capabilities create a shared, consistent view so security and IT can manage agent risk as one system, not in silos. Today, in the second episode of this series, we build on that foundation and dive deeper from the SOC perspective in Microsoft Defender, showing how unified agent visibility enables faster detection, stronger investigations, and coordinated response with IT before agent-driven risk escalates. -Starting off as an IT admin in the Microsoft 365 admin center, I can see agents which have risks associated with them. The agent risks tab in the registry has identified several agents that need my attention based on security risk signals surfaced here. And drilling into any of these agents exposes the security & compliance page, where the IT admin will see only unresolved alerts with high and critical severity from Defender. Switching perspectives, as a SOC analyst on the Zava security team, the Microsoft Defender portal is my go-to-solution for threat protection, including posture management and investigations. I also need detailed security information for the agents that run in our environment. -I can view the same agent within Defender with a security lens with related incidents and alerts. I mentioned before that an IT admin can see the big picture and even view unresolved alerts from critical incidents within their experience, but as a SOC analyst, I need the granular details to dig deeper into the incident. I can see all the lower priority and resolved incidents that provide more context on the activity of this agent. Microsoft Defender continuously monitors AI agent activity in real time. It can block malicious tool invocation attempts as they happen, and alert security teams that there have been attempts to jailbreak AI agents. -Let’s click into the critical incident to investigate further. In the details, I can see that this has been identified as a collection incident involving one user. It also includes the information that our SOC team needs. I can look at the incident description to see that the agent is connected to a tool that sends emails, which was blocked, thankfully. Let’s open the incident page to investigate further. -Now we can see a detailed explanation of what happened, who was involved, and additional context. Alerts related to the agent are combined into a more detailed incident view, including persistent jailbreak attempts on a Copilot Studio agent and an AI agent tool invocation by the same user, which was blocked by Microsoft Defender. The alert also provides recommended actions to remediate it. It shows all events related to our user, Griffin, where the agent tried to invoke the same email tool multiple times within a short period, each with details on the date, time, and the user’s IP address. Optionally, we could investigate the user further using advanced hunting to view additional activity across a longer period. -That said, for this incident, I have enough information to suspect that it’s potentially stolen credentials and is carrying out suspicious activity. I can then click on the user to view their details and confirm that they have been compromised. Defender can automatically trigger our Entra conditional access policy to revoke Griffin’s access and require them to reset their password. This would now show that their account has been compromised and let us resolve the incident without further impact. -And I can also prevent future incidents with this agent. For that, I’ll use advanced hunting to get more information and context. I’ll click on the agent within the incident graph to find out more about the purpose of the agent, its number of associated incidents and alerts, as well as other tools it’s connected to. Running this query gives me the most up-to-date information about this agent. I can see detailed attributes like the agent’s name and creation date, who last modified it, and when. It also shows its action triggers, which actually invokes the agent to run, and any connected or child agents it interacts with. -Now, tying this back to our earlier attack, we saw that Defender’s real-time protection blocked a tool invocation for the tool that sends emails. That’s already good news, but as the investigator, I want to know what else this agent can do and how risky it is. I’ll open Agent Tool Details and I can see that, in addition to sending emails, this agent also has access to an MCP server as a knowledge source. MCP servers often expose a broad set of actions. These are mostly used for read access, but sometimes write access too. Often, as a workaround for future permissions issues, developers or makers give write access even in cases where the agent only needs read access. That’s what we call overpermissioning, and it goes against the principle of least privilege. In turn, it introduces a lot more risk if the agent is ever compromised. But I don’t want to stop with just one agent. Let’s find out if other agents in my organization are exposing risks related to overpermissioning. -Here, I have a collection of pre-built queries designed specifically for AI agents, making it easy to spot misconfigurations, excessive permissions, and other risky setups across my environment. This specific template gives me a view into agents with MCP tools configured using the maker’s credentials. That’s not good. With these permissions, the MCP server tools can be accessed using the standing permissions of the agent maker. This can lead to privilege escalation and data exposure. The advanced hunting results show that multiple agents have access to MCP servers with maker privileges, which put them at high risk. -Now we have the information we need to notify each creator that changes are necessary to scope their agent’s permissions so that they can be used safely. From there, our Microsoft 365 administrator can prevent the current agents from being used until new versions are ready. To do that, as the IT admin, I’m signed into the Microsoft 365 admin center, and in the Agent Registry. There’s our Customer Billing Agent, and I’ll click into its details. I can take action from here and block it from being used, then confirm. That’s going to remove it from the Agent Store for new users, and prevent current users from accessing it. -Then, once a newer, safer version of the agent is ready, the maker can resubmit it for publishing approval. With Agent 365 using Microsoft Defender, you can strengthen agent security posture and protect against threats. This helps you proactively identify and mitigate risks before attacks occur. -To learn more, check out aka.ms/Agent365SecOps. And in the next episode of this series, we’ll explore Agent 365 with Microsoft Entra to prevent agent sprawl, unclear ownership, and weak lifecycle management. Keep watching Microsoft Mechanics for the latest AI and security updates. Thanks for watching.Agent 365 | Your Security & Compliance Controls
Block agent access to labeled files at runtime, stop sensitive data from leaving in agent-drafted emails, and catch agents that cross conduct lines using the same Microsoft Purview controls you already run for users. Map every risky agent action in Insider Risk Management, drill into Activity Explorer for interaction-level detail, and pull regulator-ready forensics from Purview Audit. Shilpa Ranganathan, Microsoft Purview Partner Group Squad Leader, shares how IT and data security teams can govern agent behavior on a single Agent 365 control plane built into the Microsoft tools that you're already using today. Block labeled files from agent access in real time. No policy bypass, no data leak. See how it works using Microsoft Purview as part of Agent 365. Same policies, now extended to agents. Purview DLP catches sensitive content and blocks the send. Watch it in action. Map the full chain of risky agent actions in one view. Insider Risk Management in Purview sequences sensitive file access & DLP blocks. See how it works. QUICK LINKS: 00:00 — Agent security, compliance, & IT 01:13 — IT & data security teams using Agent 365 02:22 — Visibility with Microsoft Purview 03:14 — End user perspective 04:05 — DLP on Agent-Initiated Messages 04:23 — Communication Compliance for Agent Behavior 04:50 — Data Security admin in the Purview portal 06:04 — Policy violations 06:39 — Purview Audit 07:06 — Microsoft 365 admin center 07:44 — Wrap up Link References Check out https://aka.ms/Agent365DataSecurity Unfamiliar with Microsoft Mechanics? As Microsoft’s official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft. Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries Talk with other IT Pros, join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog Watch or listen from anywhere, subscribe to our podcast: https://microsoftmechanics.libsyn.com/podcast Keep getting this insider knowledge, join us on social: Follow us on Twitter: https://twitter.com/MSFTMechanics Share knowledge on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/ Enjoy us on Instagram: https://www.instagram.com/msftmechanics/ Loosen up with us on TikTok: https://www.tiktok.com/@msftmechanics Video Transcript: -How do you make sure agents don’t run unchecked across your environment? It starts with the right level of observability across security, compliance, and IT, insights that’s tailored to each team’s domain expertise, yet shared across teams, so issues can be identified early and addressed quickly when something goes wrong. This is where Agent 365 comes in to bring together security and IT teams so they can stay in control through a unified control plane, built to work with the Microsoft tools you already use. -Whether you’re viewing agents along with their configurations and high-level activities in the Microsoft 365 Admin Center, understanding agent activities and protecting sensitive information with Microsoft Purview, managing agent identities and permissions to apps, data, and resources with Microsoft Entra, or investigating and responding to incidents in Microsoft Defender, Agent 365 provides a common source of truth for agent activity, enabling teams to assess and respond to risks from their own domain expertise using the tools and workflows they know best. Today is the first episode in a series where we go deeper on using Agent 365 across your organization, starting with protecting your sensitive data. For example, if data isn’t properly classified and protected, AI, which uses powerful semantic search, can quickly surface information that was once hard to find, leading to data loss. -At the same time, it can potentially share it with the wrong people, and related other risks can escalate quickly. Microsoft Purview now extends the controls you have for users in your organization to agents so they stay aligned with your organization’s data security and compliance requirements. Let me show you how IT and data security teams can work together using Agent 365. Starting in Agent 365 in the Microsoft 365 Admin Center. As an IT admin, I can see a comprehensive list of agents in our organization. I can manage agent deployment requests to review the details for agent configurations and even leverage built-in security defaults for Agent 365 to quickly establish policy controls. -That said, as agents are used inside of your organization, Microsoft Purview, as part of the Agent 365 control plane, provides more granular controls with deeper visibility over data security. This includes rich AI observability, protection, and compliance. Right from Microsoft Purview, I can see agents running in my organization with the same left-to-right agent visibility we saw in the Microsoft 365 Admin Center. From Data Security Posture Management, or DSPM, for short, I can find key agent metrics and what’s important for data security, like which agents are active and their risk levels, whether they’re interacting with sensitive data, in which ways, along with interaction trends. I can also see if their activities are protected with sufficient policy coverage. -Let me show you an example of how this level of oversight and protection works, starting from the end user perspective. This is a custom, in-house-developed Zava supplier agent. It’s designed to review and summarize purchase orders for clients. Here, a member of the procurement team asks the agent to review a few linked purchase orders PDF files and check for delays and impacts. The reasoning agent gets to work almost immediately, providing a summary for the linked files. It then attempts to access a contract file to figure out the contractual impacts of any delays. -Now, because the contract has a label that the agent is not allowed to process, it stops and says that it cannot access the information contained in that file. This is Microsoft Purview enforcing least-privilege access in real time. Next, our same user asks the agent to email the summary to an external supplier. The agent tries, but Purview spots sensitive data in the message. In fact, if we move to Outlook and open the message, we can see that our sensitive information policies have blocked the email from being sent. Back in Teams, we can see that the same user is attempting to use the agent to draft an email that promises an exclusive gift incentive to fast track the PO approval. The agent stops again. It recognizes the request crosses ethical and compliance lines and explains why to our user. -Importantly, behind the scenes, Purview logs all activity as it happens and flags the interaction for review. In fact, let’s switch perspectives to the data security admin in the Purview portal after these activities have taken place. I’m back in DSPM under AI Observability with a view of my running agents. And on top of my list, Purview has flagged the supplier agent as high risk. Let’s drill into it. For that, I’m in insider risk management view for this activity. It maps out the sequence of events that our user and agent attempted to carry out, starting with sensitive file access in SharePoint, including the contract I mentioned. -Then the DLP policy block, which stopped the email summary from being sent to the external supplier. And, finally, the unethical behavior block when a user attempted to offer a gift in exchange for faster contract approval. All these activities raise the risk level of the agent, and each action is clearly outlined. To get more detailed context about the agent’s behavior, I can view the activity timeline, which links me directly into Activity Explorer in DSPM to see other interactions with this agent. It looks like there’s a mix of benign activity at the bottom of the list, and the higher risk activities for our user are at the top. All prompts and responses are evaluated against compliance policies and classifiers, and any matches are surfaced using the same investigation and remediation workflows you already use today. -In fact, you can find the details for agent policy violations across solutions in Microsoft Purview. For example, if your focus is on communication compliance, you can find the details for the agent interaction that was flagged as unethical. In this case, it matched the gifts and entertainment condition. And clicking in, you can see related matches for other sources too. And Purview Audit also captures every agent interaction, which you’ll find using an audit search. -Here we’ve searched across agent interactions that occurred between February 1st and March 1st for our agent, and you can see the exportable details for each interaction, including IP, user, agent, record, and activity details. So when a regulator asks: “How did this happen?” You can trace it instantly using Purview Audit. Of course, with Agent 365 at the foundation, everything is connected and integrated across the control plane. So now as an IT admin working in the Microsoft 365 Admin Center, I can see the agents running in our environment filtered by high risk, and there’s our supplier agent. In its details, under Security and Compliance, I can see it has performed a few risky activities. This is all signal that has been pulled in from Microsoft Purview as part of Agent 365. -From here, I can tune the agent configurations, including its permissions, or even block it all together from use. AI agents move fast, and without the right level of visibility and guardrails in place, they can easily access data they shouldn’t overshare, and even work against your company’s ethics. Agent 365 with Microsoft Purview keeps your agents in line, spots trouble before it happens, and makes sure that actions are recorded. -To learn more, check out aka.ms/Agent365DataSecurity. In the next episode of the series, we’ll explore Agent 365 with Microsoft Defender to investigate and respond to security incidents involving agentic activity. Subscribe to Microsoft Mechanics if you haven’t already, and thanks for watching.
