Do Purview labels and DLP protect PII before a Fabric Copilot reads it?
They protect access to it, not the value itself, and that gap is worth spelling out.
A Purview sensitivity label is metadata. Microsoft says so plainly: labels are stored in clear text in the metadata of files and emails, and the label travels with the content as metadata no matter where it gets saved. The label describes the item. The credit card number underneath it is still a credit card number.
DLP for Microsoft 365 Copilot is the enforcement arm. Point the Content contains > Sensitivity labels condition at something and it excludes matching items from processing. Per Microsoft, the content of the item isn't processed by Copilot or used in the response, though the item can still show up in the citations. It is a detect-and-block gate that transforms nothing and removes nothing. And every Copilot prompt runs in the security context of the user who typed it, so an authorized user, and Copilot acting as them, can pull the raw value unless a rule specifically kicks that item out.
So the honest answer: labels and DLP gate reads, and they can encrypt or block whole items, but they leave the raw PII exactly where it was.
What a Fabric data agent can actually read
A Fabric data agent is generally available, read-only, and runs under the requesting user's credentials and permissions on a least-privilege basis, and it respects Purview governance on the underlying sources, DLP and access restriction policies included. That same documentation notes DLP for Fabric Data Warehouse is generally available, while access restriction policies for the Fabric KQL Database, SQL Database, and Data Warehouse were in preview at the time of writing, though Microsoft has put restrict-access policies on a stated GA path rolling out through late 2026. Microsoft ships fast in this area, so re-check the exact GA versus preview status before you bet a control on it, because that preview label is time-bound. When the same data gets surfaced through Copilot in Fabric, those Purview policies still apply.
Microsoft's own guidance warns that sensitive assets might be inaccessible to the agent, which can produce incomplete answers. Look at what that quietly assumes. The raw identifiers live in OneLake, and the control only decides whether the agent can reach the asset. Block the asset and you block the answer. Allow the asset and the agent reads the real values. There is no version of this where the agent gives a useful answer without the raw PII being present. The Purview-over-Fabric model is Entra identity plus label-based and authorization-based policy sitting on top of data that lives, in clear form, in OneLake.
Label metadata versus tokenizing at ingest: the mechanism difference
A label and a token do different things to a value. A label is metadata added on top of a value that stays exactly where it is. Tokenizing takes the value out and drops a stand-in token where it used to sit. Everything downstream follows from that difference.
When you tokenize PII at ingest, the raw identifier never lands in OneLake to begin with. It gets swapped for a token, and the real value stays in a customer-controlled vault backed by your own KMS or HSM. The agent queries governed data and gets back tokens. It can still join customer_9f83 across the warehouse, because deterministic tokens preserve joins. It cannot read the person's name, because the name isn't there. Need the raw value later for some legitimate downstream flow? You resolve the token through the vault under its own authorization, outside the agent's blast radius.
Microsoft's closest native answer here is dynamic data masking in Fabric Warehouse, plus OneLake column-level and row-level security. Worth knowing, worth using, but understand the mechanism. DDM masks the value at read time for unprivileged callers while the raw value stays in place. It is reversible, in-place masking, so anyone with the underlying permission, or an agent running as them, still resolves the real value out of OneLake. Same shape of gap as a label, just applied at the column instead of the item.
So labels, DLP, and native masking change who may read the identifier, while tokenization changes whether the identifier exists in the plane the agent can reach.
One honest caveat on tokens, because I hate specs that oversell. Deterministic tokens preserve equality joins, not LIKE or substring matching. Partial-match queries against tokenized columns won't behave the way they do on cleartext. That is a design tradeoff, not a bug, and you plan around it.
Key custody decides the whole thing. If the token keys sit with the same cloud tenant as the data, you've moved the problem rather than solved it. Customer-held keys are what let you crypto-shred: destroy the key, and every token derived from it becomes permanently unresolvable, which happens to be a very clean answer to an erasure request.
The threat model: goal hijack and EchoLeak
Why does this matter more for an agent than for a dashboard? Because agents can be steered and a dashboard cannot.
The OWASP Top 10 for Agentic Applications treats agent goal hijack as a top-tier risk, formally coded Agent Goal Hijack (ASI01) in the December 2025 list (the 2026 edition). It folds classic prompt injection, long the top LLM risk as LLM01, together with excessive autonomy into an agent-specific category, where a single manipulated input redirects the agent's goals, planning, and multi-step tool use instead of just corrupting one reply. For the exact ordering and category names, pull them straight from the OWASP page rather than trusting any summary, including this one.
The canonical demo is EchoLeak, CVE-2025-32711, a critical (CVSS 9.3) zero-click indirect prompt injection in Microsoft 365 Copilot that its discoverers at Aim Labs classed as an LLM Scope Violation. A single crafted email tricked Copilot into exfiltrating data from its own context, with no click required. The category matters: it was a proof-of-concept under responsible disclosure, not a breach in the wild. According to that Aim Labs writeup, the team built the proof-of-concept in January 2025, reported it to Microsoft, and Microsoft patched it server-side in May 2025, with the same writeup noting no evidence of real-world exploitation. There is also an arXiv preprint (later published at the AAAI Fall Symposium Series 2025) documenting it as a zero-click prompt-injection exploit demonstrated in a production LLM system. Demonstrated, to be clear, not caught in the wild.
EchoLeak hit M365 Copilot broadly rather than Fabric specifically, and I haven't seen a documented in-the-wild PII exfiltration tied to Fabric data agents. The point is the pattern, not a Fabric body count. If an agent's goals can be hijacked, the only data that stays safe is data it cannot read in raw form. A labeled but present credit card is still readable by an authorized agent that has been hijacked, whereas a token hands that agent nothing worth exfiltrating.
Why the MCP boundary is the right place to enforce this
More Fabric and Copilot work is moving through tool calls, and the Model Context Protocol is how a lot of it gets wired. MCP defines Hosts, Clients, and Servers exposing Resources, Prompts, and Tools over JSON-RPC 2.0. Credit where it is due: the spec is refreshingly honest about its own limits. It states outright that MCP itself cannot enforce security principles at the protocol level, and that implementors SHOULD build consent and authorization flows and implement appropriate access controls and data protections. The MCP security best practices doc goes further on indirect prompt injection and confused-deputy risks.
That means the protocol will not save you on its own. Governance has to live at the boundary, either at ingest before data reaches OneLake, or at the MCP boundary where the agent asks for data. That is exactly where per-call authorization belongs, so each tool call gets checked against live entitlements and can be revoked mid-session, instead of trusting a token that was minted twenty minutes ago and hasn't been questioned since.
Fabric PII governance best practices for AI agents
This is an engineering threat model, not a compliance checklist, so treat it as a starting frame rather than exhaustive advice. With that said, here is what I would actually do.
- Keep labels and DLP. They're good at classification, discovery, encryption, and blocking whole assets. Don't rip them out. They just aren't a data-removal control, so stop treating them like one.
- Tokenize the high-risk identifiers at ingest. Names, national IDs, card numbers, emails, account numbers. Do it before the data lands in OneLake so the agent plane never holds the raw value.
- Hold your own keys. Customer-controlled KMS or HSM. Without that, crypto-shred and real erasure are theater.
- Authorize per tool call, not per session. Bind each MCP call to current entitlements and support mid-session revocation.
- Log every call into a tamper-evident chain. You want to prove what the agent read, not just assert it. This is also where your Article 12 logging story lives.
- Pick your enforcement point on purpose. At ingest, at the MCP boundary, or both. Don't assume the model or the protocol will do it for you, because neither one will.
Govern what agents can reach, not only what they will do
Most agent security spends its budget on behavior: guardrails, output filters, refusal training. Useful stuff, but it is all guessing at intent. The cheaper and more durable move is to shrink what the agent can reach in the first place.
That is the plane DataShield works in. Its Ontology applies join-preserving tokenization at ingest, so a hijacked agent turns up tokens instead of raw PII. Authorization happens per tool call with mid-session revocation, and every call gets sealed into a tamper-evident audit chain you can check yourself at /verify. One honest limit, stated plainly: DataShield doesn't carry a SOC 2 attestation yet, and it isn't a masking policy bolted onto Copilot or a prompt proxy parked in front of the model. It governs the data plane, at ingest or at the MCP boundary.
Because Fabric leans hard Microsoft-native, Entra identity, Purview governance, tight Copilot and agent integration, the authorization layer is already strong. The gap isn't who can read. The gap is that the raw identifier is still sitting there, and you close it by removing the value rather than relabeling it. If you want the numbers behind that tradeoff for your own data, the quote worksheet is where to start.
Watch: related explainers
How Purview DLP gates Copilot prompts, plus the injection risk it does not remove.
Frequently asked questions
Do Purview sensitivity labels remove PII from OneLake?
No. A sensitivity label is metadata stored in clear text alongside the item, and per Microsoft it stays with the content as metadata no matter where it's saved. It can trigger encryption or access control, but the underlying raw identifier stays in OneLake in clear form.
Can a Fabric data agent read raw PII if the data has a sensitivity label on it?
Yes, if the querying user is authorized and no DLP exclusion or access-restriction policy blocks that specific asset. Fabric data agents run under the requesting user's permissions, so the agent retrieves the raw value unless a control blocks the whole asset, which also blocks the answer.
What is the difference between a sensitivity label and tokenization?
A label is metadata attached to a value that stays in place. Tokenization at ingest replaces the value with a join-preserving token and keeps the real data in a customer-controlled vault. In short, labels govern who may read the identifier, while tokenization governs whether the identifier is even present where the agent can reach it.
Does Purview DLP stop prompt-injection attacks like EchoLeak?
Not directly. DLP for M365 Copilot is a block-and-exclude gate on which items get processed. EchoLeak (CVE-2025-32711, CVSS 9.3 Critical) was a zero-click indirect prompt injection demonstrated as a proof-of-concept and later patched by Microsoft, with its discoverers at Aim Labs noting no evidence of real-world exploitation. The durable defense against a hijacked agent is making the sensitive value a token, so there is nothing raw to exfiltrate.
Where should I govern PII for Fabric agents, at ingest or at the MCP boundary?
Ideally both. Tokenize high-risk identifiers at ingest so they never land in OneLake in clear form, and enforce per-call authorization at the MCP boundary. The MCP spec states the protocol cannot enforce security itself, so implementors have to add access controls and data protections at the boundary.