Data Protection with Microsoft Purview for Agents

Identity answers who an agent is. Access control answers what it may reach. Neither answers what happens to the actual data once an agent has it in hand. That is the job of Microsoft Purview, and this article walks through its four jobs for agents, including two easy-to-miss gaps worth knowing before you rely on labels alone.

1 · Sensitivity labels: inherited, with one important gap

Many organisations already tag documents with a sensitivity label — a marker such as “Confidential” or “Internal Only” that describes how sensitive the content is and what protections should follow it. The good news is that agents inherit and honour these existing labels automatically: an agent reading a confidential document respects the same label a person would see.

But there is a genuine gap worth knowing. If a sensitivity label is configured for encryption, that encryption must explicitly grant the agent instance view and extract usage rights before the agent can actually read the encrypted content. A broad grant such as “add all users and groups in your organization” or “add any authenticated user” is not sufficient on its own — the agent needs to be named, or covered by a scope that genuinely includes it, with those specific rights.

2 · The second gap: newly created content

A second, related gap: content an agent creates — a new summary, a report drafted from several source documents — does not automatically inherit the sensitivity label of the documents it was built from. As a result, that new content is not automatically labelled or encrypted, even if every source document carried a strict “Confidential” label.

This matters because it is exactly the kind of leak that is easy to miss: the source is protected, but the agent’s own output, distilled from that protected source, can slip out unlabelled. Organisations relying on labels for protection need a deliberate process for labelling agent-generated content, not an assumption that inheritance happens by itself.

3 · Data loss prevention: stopping the leak

Data loss prevention, usually shortened to DLP, is the system that identifies sensitive items across Microsoft 365 services and endpoints, monitors them, and helps protect against their leakage. It uses deep content inspection and contextual analysis, meaning it looks at the actual content and its context, not just a filename or a simple keyword match, to recognise things like financial records, health information, or intellectual property.

For agents, DLP can block them from accessing and sharing sensitive content outright. And it extends beyond agents to the humans working alongside them: on Windows computers onboarded to Purview, endpoint DLP can warn or block a person from pasting sensitive content, such as a credit-card number, into a third-party generative AI site accessed through a browser. The same discipline that protects data moving through Microsoft’s own agents also covers a person routing that data to an outside AI tool by hand.

4 · Data security posture management

Data security posture management, often paired with “AI observability,” provides deep, ongoing visibility into how agents are actually interacting with data across the organisation. Rather than a one-time check at setup, it is a continuous view: which agents are touching sensitive data, how often, and in what pattern.

In the Purview portal, this translates into concrete tools: a list of the organisation’s agent inventory, signals that help prioritise which agents to investigate first, and the ability to drill into a specific agent’s context and its interactions with sensitive data, complete with remediation recommendations. Posture management is what turns “we labelled things once” into “we can see how data is actually flowing through agents right now.”

5 · Insider risk management, extended to agents

Insider risk management is the discipline of watching for risky behaviour from people who already have legitimate access — not outside attackers, but insiders whose actions look concerning. Microsoft extends this same discipline to agents: detecting anomalous or risky agent activity, not just anomalous human activity.

This matters because an agent is, in a real sense, an insider — it holds legitimate access, granted on purpose. Extending insider risk management to agents means the same behavioural watchfulness applied to a person with concerning access patterns now also applies to an agent whose pattern of touching data starts to look unusual.

6 · Compliance manager, extended to agents

Compliance manager is the tool organisations use to assess, manage, and demonstrate that they meet regulatory and policy requirements. Extending it to agents means an organisation can evaluate whether its agents comply with the same standards it already holds its people and systems to, and produce evidence of that compliance when asked.

Practically, this closes a gap that would otherwise be easy to overlook: an organisation might be able to prove its employees follow data-handling rules while having no equivalent proof for the agents now handling the same data. Compliance manager extended to agents means that proof exists for both.