Zero TrustData SecurityZTDFMicrosoft PurviewArchitecture

Microsoft Purview Sensitivity Labels and ZTDF Diverge When the Label Stops Carrying Policy

June 22, 2026

Microsoft Purview's sensitivity labels are a useful and increasingly common building block in enterprise data governance. The label travels with the file across SharePoint, OneDrive, Teams, and Exchange. The label appears in document headers and in DLP policy decisions. The label can encrypt the file with Microsoft Information Protection (MIP) and bind a usage policy to the encrypted content. For workloads that live entirely inside Microsoft 365 and the broader Microsoft Purview ecosystem, the model is operationally clean.

The model has a boundary, and the boundary is where Zero Trust Data Format diverges from sensitivity labels in a way that matters for architecture and procurement. A sensitivity label is metadata that points at a policy. The policy lives in the Purview service. The cryptographic enforcement, when MIP is engaged, lives in the Azure Rights Management service, which evaluates the policy against the requesting principal's identity at the moment of access. The principal identity has to be reachable to the Purview policy service for the model to enforce.

ZTDF binds the policy to the object cryptographically. The object carries the policy and a wrapped key. The policy enforcement point can be operated by any party that the object's policy authorizes, and the evaluation does not require the enforcement point to be reachable to a single tenant's policy service. The differences are not small, and the differences are what governs the question every architect eventually faces. What survives when the file crosses a trust boundary the original tenant does not control.

What sensitivity labels enforce, and where

Sensitivity labels in Microsoft Purview enforce the policy the issuing tenant configures. A file labeled Confidential, with the corresponding MIP policy applied, encrypts at rest and at transport. A read attempt by an authorized user inside the issuing tenant evaluates the user's identity against the policy and decrypts the file. A read attempt by an authorized user inside a partner tenant requires a federation, a guest invitation, or a cross-tenant access policy that the issuing tenant has configured.

A read attempt outside any Microsoft tenant, or by a principal whose identity does not resolve through the issuing tenant's Azure AD, does not enforce. The encryption holds. The label travels. The policy decision does not run because the policy decision point is not reachable. The behavior is correct. It is the boundary the model was designed against. The file outside the tenant boundary is a ciphertext blob whose policy decision the issuing tenant retains.

For workloads that stay inside the Microsoft 365 estate, this is exactly the behavior the program wanted. The file is encrypted, the policy is enforced, and the audit chain runs through the Microsoft 365 unified audit log. The architecture works.

Where the model diverges from ZTDF

The divergence appears at three operational moments. First, when the file leaves the tenant intentionally. A partner contract, a coalition share, a regulatory disclosure, or a vendor handoff requires the file to be read by a principal the issuing tenant does not natively authenticate. The Purview model handles this through cross-tenant access settings, B2B collaboration, and external sharing policies. Each is a configurable extension of the issuing tenant's identity boundary. The extension works at the scale of partner integrations the tenant configures and breaks at the scale of partner integrations the tenant does not.

ZTDF handles the same case through the object's policy. The policy names the attribute set the requesting principal must satisfy, not the tenant the principal belongs to. The policy enforcement point evaluates the attribute set at the moment of access. The attribute set can be issued by any party that participates in a common attribute provider, and the policy enforcement point can be operated by any party the object's policy authorizes. The cross-boundary case is the design center of the model rather than an extension of it.

Second, when the file leaves the tenant unintentionally. A breach, a misconfigured export, a compromised account, or a renderer-layer exfiltration produces a file that is no longer reachable to the issuing tenant's policy decision point. The Purview model leaves the file encrypted, which preserves confidentiality. The policy decision over a future legitimate read against the exfiltrated file cannot run, which means the issuing tenant's lineage record over reads against the exfiltrated copies does not exist.

ZTDF handles the same case through the policy enforcement point that the object's policy designates. The exfiltrated object remains ciphertext. A future read attempt against the exfiltrated copy reaches a policy enforcement point that the object's policy named. The policy decision runs. The lineage record produces. The issuing party gains a chain-of-custody evidence stream over the exfiltrated copies that the Purview model does not produce.

Third, when the file enters an AI or agent workflow. A foundation model, a retrieval augmented generation system, or an autonomous agent reads files at machine tempo on behalf of principals the system identifies through delegated credentials. The Purview model evaluates the delegating user's identity, not the calling tool, the agent's host context, or the operation scope. A compromised tool or a hijacked agent's session reaches the file at the principal's authorization level.

ZTDF binds the policy decision to the richer attribute set the agent threat model requires. The policy can require principal-and-tool-and-host attributes to satisfy. A compromised tool whose host attribute does not match fails closed at the policy enforcement point. The agent's session is authenticated. The agent's read does not unwrap. The architectural distinction matches the threat model the Anthropic Zero Trust for AI Agents framework names as the Optimized tier.

When each model is the right choice

The choice is not exclusive. Programs that run substantially inside Microsoft 365 and need sensitivity labeling for in-tenant DLP, classification, and policy management converge on Purview sensitivity labels. The model is mature, the operator population is large, and the integration with the Microsoft estate is the design center. Programs that need policy enforcement that survives the tenant boundary, the breach surface, or the agent threat model converge on ZTDF. The model is designed against the cases where the in-tenant model's enforcement boundary ends.

The composition pattern that works in enterprise environments is to use Purview sensitivity labels for in-tenant classification and policy management, and to wrap the underlying object in ZTDF for cross-boundary enforcement. The label travels for in-tenant DLP. The ZTDF wrapping travels for cross-boundary release. The two layers compose at the file level, and each layer handles the threat model it is best suited to.

What this changes for procurement and architecture

A solicitation that names sensitivity labels as a data protection control names the in-tenant case. A solicitation that names ZTDF or IC-TDF names the cross-boundary case. A solicitation that names both, with composition between them, names the full surface that enterprise data governance now reaches across partner integrations, breach response, and AI workflows. The procurement language that converges on this composition is the procurement language that produces an architecture that survives the case the in-tenant model was not designed against.

Lattix Technologies binds policy to data objects through attribute-based access control at the policy enforcement point, post-quantum key encapsulation under ML-KEM-768 and ML-KEM-1024, and Merkle-tree lineage in tamper-evident audit storage. The architecture composes with Microsoft Purview sensitivity labels at the file level. The composition produces in-tenant DLP and cross-boundary enforcement from a single object representation. The architecture is procurable today against enterprise data governance programs operating across Microsoft 365 and the broader federated environment.

Sensitivity labels and ZTDF are not in tension. They are complementary, and they answer different questions. The question the architect has to answer is which question the program is actually trying to answer.

What sensitivity labels enforce, and where

Where the model diverges from ZTDF

When each model is the right choice

What this changes for procurement and architecture

References