Data Protection with Purview — Agent 365: Registry and Access

An agent can have the right identity, the right permissions, and still become a new path for sensitive data to escape. That is why data protection cannot stop at asking who the agent is or what it may access. Microsoft Purview adds the data layer: it labels sensitive information, applies loss-prevention policy, shows how agents interact with protected content, and helps an organization prove that agent activity meets its compliance obligations.

Where Purview fits in agent governance

Identity tells you which agent is acting. Access control tells you which systems and files it may reach. Microsoft Purview is concerned with the content itself: what kind of data the agent is handling, what protections are attached to that data, whether the data is being shared in risky ways, and whether those controls can be audited.

This distinction matters because agents do not merely retrieve information. They summarize, transform, combine, and route it. A support agent might read a customer record, draft a reply, and include a financial detail. A research agent might condense several confidential documents into one new memo. The security question is not only whether the agent was allowed to open the source material. It is also whether the sensitive meaning inside that material remains protected as it moves through the agent’s work.

For Microsoft agents, Purview provides four main data-protection capabilities: sensitivity labels, data loss prevention, data security posture management, and compliance-oriented oversight through insider risk management and Compliance Manager.

Purview guards the content itself through four complementary data controls.

Sensitivity labels travel with source content

A sensitivity label is a classification tag, such as Confidential or Internal Only, that describes how sensitive a document or item is and which protections should follow it. Many organizations already use these labels across Microsoft 365 content. Agents can inherit and honor those existing labels when they read labeled material.

That is the good news: an agent does not need a separate classification system for content that is already labeled. If a document is labeled Confidential, the agent sees and treats that content in the context of that label, just as a user-facing Microsoft 365 experience would.

The important boundary is that a label is not magic. It helps classify and govern data, but its effect depends on how the label is configured and how the agent’s output is handled. Two gaps deserve special attention before a team relies on sensitivity labels as its main agent control.

📌

Labels are inherited. Agents can honor existing sensitivity labels on source content, so organizations can reuse the classification work they have already done.

Encrypted labels need explicit agent rights

Some sensitivity labels do more than classify a file. They also encrypt it. Encryption is the control that prevents content from being opened or extracted unless the actor has the required usage rights.

For agents, this is where a subtle rule becomes operationally important. If a sensitivity label encrypts a document, the encryption policy must explicitly give the agent instance the rights it needs to view and extract the content. A broad grant such as all users and groups in the organization, or any authenticated user, is not enough by itself for the agent to read and use the encrypted material.

In practical terms, encrypted content may look accessible on paper because the agent has access to the file location. But the agent can still fail when it tries to process the protected content because the encryption rights do not cover that agent instance with the required view and extract permissions.

⚠️

Check before launch. Any encrypted label an agent must read should be tested for explicit agent view and extract rights, not only file-level access.

Encryption rights must name the agent instance or processing fails.

Agent-created content is a new protection problem

The second gap is about output. When an agent creates a new summary, answer, report, or draft from labeled source documents, that new content does not automatically inherit the sensitivity label of the sources it came from.

This is easy to underestimate because the output may contain the most sensitive parts of the source material in condensed form. A ten-page confidential report may become a one-page executive summary. If the new summary is unlabeled, the organization has protected the original while leaving the distilled version exposed.

The design lesson is simple: treat generated content as new content that needs its own labeling strategy. Depending on the workflow, that may mean user review, policy-driven labeling, template controls, restricted destinations, or other process controls. The key is not to assume that source labels automatically attach themselves to agent output.

Agent output does not inherit source labels and needs its own.

Data loss prevention stops sensitive content from leaking

Data loss prevention, often shortened to DLP, is the set of controls that identifies sensitive information, monitors how it is used, and helps prevent it from being shared in unsafe ways. In Microsoft Purview, DLP can inspect content across Microsoft 365 services and supported endpoints.

For agents, DLP is the guardrail that can block access to or sharing of sensitive material, such as financial records, health information, or intellectual property. It is not limited to simple keyword checks. It uses content inspection and context, so it can recognize protected data patterns and policy conditions more reliably than a basic text search.

This protection also matters around the agent. On Windows devices onboarded to Purview, endpoint DLP can warn or block a user who tries to paste sensitive content, such as a credit card number, into a third-party generative artificial intelligence site in a browser. That closes a common workaround: if the governed agent cannot send the data out, a person should not be able to casually paste the same data into an outside artificial intelligence tool.

Use DLP to inspect the content an agent handles, not only the file name or storage location.
Apply policies to sensitive categories such as financial data, health data, and intellectual property.
Extend controls to endpoints when users may move sensitive data into external artificial intelligence tools.

DLP escalates from watching use to alerting and blocking risky sharing.

Posture management turns policy into visibility

Data security posture management is the ongoing view of how data is actually being used. For agents, it answers practical questions: which agents are touching sensitive data, how often, in what pattern, and with what level of risk?

This is different from a one-time approval at deployment. Agent behavior changes as prompts change, tools change, users change, and new data becomes available. A posture view lets administrators see the agent inventory, prioritize which agents deserve investigation, drill into a specific agent’s context, review interactions with sensitive data, and use remediation recommendations.

This capability is especially valuable because agent risk is often about combinations. A single read of a confidential file may be normal. A sudden increase in sensitive data access, a new destination, or an unusual pattern of interaction may deserve attention. Posture management provides the operating picture needed to notice those changes.

Insider risk and compliance now include agents

Insider risk management looks for risky behavior by actors that already have legitimate access. Traditionally, that meant people: an employee, contractor, or administrator whose activity begins to look unusual or concerning. Microsoft extends that discipline to agents as well.

That extension is logical. An agent is not an outside attacker when it uses the access it was granted. It is an authorized actor. If its pattern of data access becomes anomalous or risky, the organization needs ways to detect and investigate that behavior just as it would for a person.

Compliance Manager addresses a related need: evidence. Organizations must often assess, manage, and demonstrate that they meet regulatory or internal policy requirements. Extending Compliance Manager to agents helps organizations evaluate whether agents meet the same obligations applied to people and systems, and produce evidence when auditors, regulators, or internal risk teams ask for it.

✅

Same standard. Agents that handle regulated data should be governed and evidenced under the same compliance expectations as the humans who handle it.

The decisions leaders and builders must make

Purview gives teams the controls, but it does not remove the need for design choices. Leaders and practitioners should decide which agents may process encrypted content, how those agents receive explicit usage rights, and how those rights are reviewed over time.

They should also decide how generated content will be labeled. If an agent drafts a report from confidential sources, who or what applies the label to the new report? Is the output blocked until labeled? Are some destinations prohibited? These are workflow decisions as much as security decisions.

Finally, teams should define what normal agent data behavior looks like. Without a baseline, every alert feels arbitrary. With a baseline, posture management, data loss prevention, insider risk signals, and compliance evidence become part of an operating model rather than a collection of disconnected tools.

Which agents need access to encrypted labeled content, and who approves the required rights?
How will new agent-generated content be labeled, protected, and reviewed?
Which DLP policies apply to agent workflows and to users working around those workflows?
What signals define risky or anomalous agent behavior?
What compliance evidence must be retained for agent activity?

Key takeaways

Purview protects the data an agent touches; it complements identity and access control rather than replacing them.
Agents can honor existing sensitivity labels, but encrypted labels require explicit agent view and extract rights.
Agent-generated output does not automatically inherit source labels, so new summaries and drafts need their own labeling plan.
Data loss prevention can block sensitive content from leaking through agents and can also protect endpoint actions such as pasting data into external artificial intelligence sites.
Data security posture management provides ongoing visibility into how agents interact with sensitive data.
Insider risk management and Compliance Manager extend oversight and evidence gathering to agents, not only people.

Glossary

Microsoft Purview: Microsoft Purview is Microsoft’s data security, governance, and compliance platform for classifying, protecting, monitoring, and auditing information.
Sensitivity label: A sensitivity label is a classification applied to content, such as Confidential or Internal Only, that can drive protection and handling rules.
Encryption: Encryption is a protection that makes content unreadable unless the actor has the required usage rights to open or extract it.
Usage rights: Usage rights define what an authorized actor may do with protected content, such as view it, edit it, or extract text from it.
Data loss prevention: Data loss prevention is a set of controls that detects sensitive information and helps stop it from being shared or used in unsafe ways.
Endpoint DLP: Endpoint DLP is data loss prevention applied on user devices, such as Windows computers, to monitor or block risky handling of sensitive data.
Data security posture management: Data security posture management is the ongoing assessment of where sensitive data is, how it is used, and which activities create risk.
Insider risk management: Insider risk management is the practice of detecting and investigating risky behavior by actors that already have legitimate access.
Compliance Manager: Compliance Manager is a tool for assessing, managing, and demonstrating compliance with regulatory and policy requirements.