Data Security & AI Report - May 2026
Every AI agent is a new employee with no badge. Here’s how to change that.
Table of Contents
Data Is What Fuels Agents How agents change the threat surface by making data the active ingredient
Identity Is What Constrains Agents Why agents need a badge system to be enforceable, and where that gets complicated
Tool Use Is What Amplifies Agents How one misconfigured agent becomes a chain of unintended consequences
Closing
Curated Resources and References Curated resources from the security community, ordered from foundational frameworks to agent-specific tools
In April I worked the security booth at Microsoft AI Tour Netherlands. Across one day I fielded questions from security architects, compliance leads, IT administrators and executives. Everyone showed up in learning mode. The shared feeling was simple: we are figuring out this AI thing together.
The ground underneath us is moving fast. Twenty-nine percent of employees have already turned to unsanctioned AI agents for work tasks, and most organisations have no unified way to see those agents, let alone govern them. But the more important shift is not the proliferation. It is what agents consume. Every previous wave of enterprise software was operated by people. Agents are different. They consume data, reason over it, and act on it at machine speed. They return answers to users, invoke tools, and call other agents. Whatever you call the layer above, the substrate is the same. Data is what fuels agents.
Securing your data is the unlock for securing your agents, but that’s not the end of the story. Microsoft Agent 365, generally available as of May 1, 2026, is what I am betting addresses the rest: a control plane for agents built on the infrastructure most organisations already run. This report is my case for why the data foundation has to come first, and how Agent 365 is designed to extend from it.
Data Is What Fuels Agents
Enterprise security has always been about protecting data. But the assumption underneath that work, that people are the primary actors, is no longer safe.
Agents change the actor. They do not wait for a person to issue a prompt. They run workflows, invoke tools, and coordinate with other agents autonomously. An agent retrieves documents, writes code, calls external services, and hands results to another agent downstream. It does this at a speed and scale no human can monitor manually.
Agents operate in three modes.
In agent-to-human, an agent returns a result or recommendation directly to a person.
In agent-to-tool, an agent invokes an external service, API, or data source.
In agent-to-agent, one agent orchestrates or delegates to another.
Each mode creates a different exposure profile. Every mode involves data. An agent reasoning over a document is consuming data. An agent generating a summary is creating data. An agent calling a server or passing results to another agent is moving data through a chain you may never see.
This is why "we need to secure our AI systems" misses the point. An agent is not just a new application sitting above your data. It is a new kind of worker, opening the same documents your people open, sending the same emails, calling the same APIs, but at a speed and scale no traditional audit log was built to follow.
Identity Is What Constrains Agents
If data is what agents consume, identity is what determines how much they are allowed to consume.
Think about how a building works. You can write the most thorough policy about who enters which room, what files can be taken out, and which floors are off-limits. None of it is enforceable without a badge system. The badge is what attaches the policy to a specific person. No badge, no enforcement.
The same logic applies to agents. A policy that says “agents handling customer data must use a specific sensitivity label” only works if the agent has a verifiable identity that the policy can attach to.
A customer with over 100,000 employees put a sharper version of this argument to me recently. Their position: if their Microsoft Purview deployment is solid, meaning their data security policies for AI are mature, do they really need Agent 365 on top? The instinct is right. Data security is the foundation. But the position has a coverage gap most organisations will hit faster than they expect.
Here is where that gap lives. Microsoft Purview is the policy layer for data: what is sensitive, what should not leave, what gets logged. Microsoft Entra is the badge layer: who someone is and what they are allowed to do. For agents built and published inside Microsoft's Copilot ecosystem, Purview already covers agent-to-human conversations. Both sides have badges.
But agents do more than talk to humans. They invoke tools, and they coordinate with other agents. Those are the interactions where the existing badge system stops covering things. For agent-to-tool and agent-to-agent interactions, every type of agent, wherever it was built, needs a verifiable identity that the policy layer can recognise. That is what Agent 365 provides: each agent gets a Microsoft Entra Agent ID, the same kind of badge a person or device gets in an enterprise IT environment.
Without that badge, organisations end up building the agent identity layer themselves. That is workable for a handful of agents. But Jensen Huang projects 100 AI agents for every person, or 75,000 workers alongside 7.5 million agents at Nvidia within a decade. At that ratio, maintaining a DIY identity layer outpaces any IT team’s bandwidth. The interactions that scale fastest, agent-to-tool and agent-to-agent, are exactly the ones the existing badge system was never built to handle.
The customer's instinct was correct: Purview is the foundation. But Purview enforces policy through identity. An agent without an identity is invisible to your access controls, your DLP rules, and your audit logs.
Tool Use Is What Amplifies Agents
An agent without tools is mostly a clever conversation. An agent with tools is a worker that can act on the world: pull files, call APIs, write code to systems, hand work to other agents. That difference is the reason agents are interesting. It is also the reason they are hard to secure.
Think of it as the difference between an employee who can talk and an employee who can also sign purchase orders. The first can expose information. The second can act on it. Once an agent is allowed to invoke tools, every interaction it has becomes a potential chain of unintended consequences. Pull a document, summarise it, send the summary to a partner system, trigger a workflow that updates a record. That is one prompt and four downstream actions, each touching a different surface. None of which required a human to approve.
Tool use turns agent risk into chain risk. A small misconfiguration on a single agent propagates quickly. A real example: agents configured with maker credentials, where the tool runs with the permissions of the person who built the agent rather than the person using it, can quietly escalate privilege every time they execute. One permission mistake, multiplied across every tool the agent invokes, multiplied again across every agent it hands work to. Security teams can hunt for this configuration in Microsoft Defender using Advanced Hunting, but only if they know to look.
The reach of those chains keeps expanding. Agents do not stay neatly inside one enterprise cloud stack. They invoke MCP servers, the emerging standard for how agents discover and call tools, that may sit outside any boundary your IT team currently monitors. They reach into AWS Bedrock and Google Cloud’s Gemini Enterprise Agent Platform, custom internal services, and third-party platforms. Agent 365’s registry sync pulls agents from those environments into a common inventory. The threat surface is no longer the agent. It is everything the agent touches, and everything those things touch.
That includes the device it runs on. A poorly governed endpoint is a springboard into everything the agent can reach from it. OpenClaw, a local agent that runs directly on user devices, is a concrete example: the endpoint is not the edge of the problem. For an agent, it is a door. Agent 365 now includes discovery and management for local agents running on endpoint devices for exactly this reason.
You cannot secure this once and call it done. New tools get wired up. New vulnerabilities surface in agents, endpoints, and cloud resources that did not exist when the policies were written. The chain keeps growing. You cannot secure what you stop looking at.
Closing
Data fuels agents, identity constrains them, and tool use amplifies them. Most security tooling was built to answer a simpler question: who accessed what, from where, and under which conditions. Agents break that model because they operate across all of those layers simultaneously. That is why a control plane emerges. Not because agents are “AI,” but because organisations need a single place to assign identity, apply policy, and monitor actions across large numbers of non-human actors.
The work that follows from those three forces, classifying data well, extending identity to non-human actors, making the chain of actions visible, will pay back over the next several years regardless of which control plane you run. Agent 365 is the most coherent attempt I have seen to do that on top of infrastructure most enterprises already operate. But the deeper point is that the work would matter even if the product did not exist.
The last twenty years of enterprise security were shaped by cloud software and mobile work. The next decade will be shaped by non-human actors operating autonomously across those same systems. Organisations that treat agents as just another productivity feature will struggle to govern them. The ones that understand agents as identity-bearing operational actors will build the foundations that scale.
Curated Resources and References
If data security is the unlock, these are the people, teams, and references I keep coming back to.
Start with the foundation
Merill Fernando, David Hoerster, and the Microsoft Zero Trust team: Zero Trust Assessment & Workshop. Worth understanding as two distinct tools.
The Zero Trust Assessment is an open-source, automated tool that runs against your Microsoft tenant (Entra, Intune, Purview), tests hundreds of security configuration items, and tells you exactly where your baseline is strong and where it needs work.
The Zero Trust Workshop is the planning framework that sits alongside it, covering seven pillars end-to-end. The reason I am flagging this now is that a new AI pillar has just been added, specifically for securing agents and MCP servers, making this directly relevant to everything in this report. David Hoerster’s explainer on how the workshop itself works is worth your time.
The comprehensive planning guide is where to start; Merill Fernando’s explainer video there is the clearest walkthrough of how to use it.
Gartner: The Impact of Generative AI on Data Loss Prevention (webinar). Gartner independently validates the case that generative AI is reshaping DLP requirements. Notably, Microsoft Purview is the only vendor tool they mention explicitly, and the segment where they demo using ChatGPT to help create custom Sensitive Information Types in Microsoft Purview is particularly good. If you want external validation for why agent-aware DLP matters, start here.
Tools for Operationalising Data Security
Jacob Sheridan: RBACMap.com. An interactive visualisation of more than 270 Microsoft 365 admin roles across Purview, Entra, Exchange, Intune, SharePoint, and Defender. An essential reference for understanding who can do what, especially as Agent 365 adds new role-based governance dimensions.
Maxim Bombardier: Microsoft Purview Referential Architecture Diagrams. A set of architecture diagrams for Microsoft Purview that I have found genuinely useful when explaining the impact of this stack of tools to colleagues and customers.
Sarah Zinshane: Custom Reports for Microsoft Purview. Practical templates and walkthroughs for building custom reporting on top of Purview. Worth bookmarking. Strong reporting remains one of the most common asks I hear from large enterprise customers once their data security deployments mature.
Maxim Bombardier — Deploy scalable, ring-fenced Purview operations with administrative units — A second piece worth flagging from Maxim, on how to use administrative units to scale Purview operations without losing tight scoping. Especially relevant for large organisations layering Agent 365 on top of an existing Purview deployment.
Ellen van Meurs, Jan Willem Roks, and the Hack the Hoax team — S2 Episode 5: Microsoft 365 Copilot and sensitive information (Dutch language) — Jan Willem and Ellen are joined by Meagan Klaij and Kerem Küçük from Microsoft to dismantle the most persistent myths around Copilot and how it handles sensitive information. As agents take on more of the work that Copilot started, the data handling questions this episode covers only get more pressing. A good listen for anyone thinking about how sensitivity and data protection policies hold up when AI is in the loop.
Agent-specific resources
Microsoft: Getting started with Agent 365. The official starting points: the Microsoft Agent 365 product page, Microsoft Learn documentation, and the Agent 365 blog on the Microsoft Community Hub, all reachable from aka.ms/AgentShowcase. If you are a Microsoft 365 admin, go to admin.microsoft.com. If you are already in the Frontier program, click Try now on the Agent overview page. If not, navigate to Copilot, then Settings, then User access, and select Copilot Frontier to enable access for your groups.
Microsoft: What’s new in Agent 365: May 2026. The official capabilities update accompanying GA, including DSPM AI Observability, Insider Risk Management for agents, Defender agent security posture management, and Advanced Hunting for agents. Worth reading alongside this report.
Seth Steenken and Mike Swantek: Data Agent Governance and Security Accelerator. Seth and Mike walked me through this in Seattle. It is a code template that automates DLP, sensitivity labels, audit logging, and threat detection across Microsoft 365 Copilot, Foundry, and Fabric. Anyone who has used Azd CLI could run this in one step
It wires up Purview DSPM for AI and Defender for AI into a single deployable governance pattern with audit evidence export built in. The right tool for security and compliance teams who need to onboard AI workloads at scale without configuring everything manually.
Developers and DevOps engineers, go straight to the GitHub repo.