“We just rolled out Copilot to the whole org. Can you help me use sensitivity labels and data loss prevention policies to keep our data out of it.”
Does Your Organization Have AI Trust Issues?
You might. And you’re definitely not alone.
But before we dive in, a little background on me and how we got on this topic.
I’ve been living inside the Microsoft ecosystem for 15+ years — and I mean that literally. I didn’t start as an advisor. I started as an engineer, hands on keyboard, actually deploying the stuff I now help organizations think through strategically. That background matters to me, because there’s a big difference between someone who’s read about how Purview works and someone who’s spent a weekend troubleshooting why a DLP policy is blocking the wrong things at 11pm. I’ve done both.
These days I spend most of my time helping organizations cut through the noise around Microsoft 365, security, and AI — not to sell them on the next shiny thing, but to help them figure out what actually solves the problem in front of them. Lately that’s meant a lot of conversations about how to properly roll out AI — what to actually consider, what’s worth your attention, and what’s just FUD. I have a genuine obsession with making technical concepts accessible to every audience in the room, whether that’s a CISO, a CFO, or an IT admin who just wants a straight answer. If I can explain a zero-trust architecture with a hotel key card analogy and watch it click for someone who’s been confused for six months — that’s the best part of the job. That’s why I write.
There’s a lot packed into this post, so let’s get into it!
Here’s the tell: your org rolled out Copilot — or Claude, or both — because you didn’t want to be the one that missed the train. The business case was solid. Leadership was bought in. The license was purchased.
And somewhere in that same planning cycle, the security team started building sensitivity label taxonomies, DLP exclusion policies, and Copilot site-level overrides to make sure the AI couldn’t actually touch most of your data.
Same meeting. Sometimes the same sentence.
You bought the ticket, boarded the train, and spent the entire ride with your luggage handcuffed to your wrist wondering if the conductor was going to steal your stuff.
That’s not an AI governance problem. That’s a trust problem wearing the costume of one.
And the more labels and policies you add on top of it, the more you’re decorating the problem instead of solving it.
This post is for everyone in that situation — from the CISO building the governance framework, to the CTO trying to understand why the rollout is taking so long, to the business leader wondering why the productivity tool they approved six months ago still barely works. If any of that sounds familiar, read on.
📋 What This Post Covers
A lot has been written about AI governance from a purely technical angle. This post takes a different approach. Here’s what we’ll work through:
The contradiction — why rolling out AI while simultaneously locking down your data is a signal worth paying attention to, and what it’s actually telling you about your security posture.
The three trust questions — most AI governance conversations collapse into one of three unresolved concerns. Identifying which one you’re actually dealing with changes what you should do next.
The hotel analogy — a plain-language framework for understanding how AI interacts with your permissions model, and why the AI didn’t create your data exposure problem.
The evidence — what MFA adoption data tells us about which security controls actually prevent the most damage, and why the same logic applies to AI governance.
The uncomfortable truth about access reviews — why the most valuable AI security work is the least exciting, and why organizations keep skipping it.
Agents — why the permissions problem that was urgent at the user level becomes critical when autonomous agents enter the picture.
Real scenarios — common situations where the instinct to reach for DLP is misguided, and a few where it’s exactly the right call.
DLP and labeling, used correctly — what these tools are actually designed for, when they’re the right answer, and the one tool that resolves the tension cleanly.
The right order of operations — a practical sequence for getting from where most organizations are today to a place where AI can be enabled with genuine confidence.
If you’re a technical leader, you’ll find specifics you can act on. If you’re a business or executive leader, the framework here will help you understand what your teams are actually working on — and why the answer to “why is this taking so long” is probably more interesting than you think.
🔑 The Trust Problem Has Three Layers
When I dig into why organizations are simultaneously deploying AI and restricting it, the answer usually traces back to one of three unresolved questions. Sometimes all three.
Do you trust the platform?
Meaning: do you trust that Microsoft and Anthropic are actually honoring their documented data commitments?
This is the most common stated concern and the most resolvable one. Microsoft’s Data Protection Addendum explicitly states that M365 Copilot does not use customer data to train foundation models. Anthropic has made equivalent contractual commitments for Claude Enterprise and API customers. These aren’t marketing claims — they’re enforceable contractual terms in documents your legal team can actually read.
If you haven’t read them and you’re building DLP policies based on assumed vendor risk, that’s not a security posture. That’s a decision made from uncertainty. Read the contracts. Evaluate them on their actual terms. If gaps remain after that, close them directly with the vendor.
Do you trust your users?
Meaning: do you believe your employees will exercise good judgment with AI tools?
For most organizations, the honest answer is yes — with appropriate training and policy in place. If the answer is genuinely no, then the work starts with culture and acceptable use policy, not technology controls. No sensitivity label fixes an organizational trust deficit.
Do you trust your M365 permissions model?
This is the question almost no one gets to. And it’s the one that actually matters.
🏨 The Hotel Your Tenant Has Been Running for Ten Years
Here’s the analogy that clicks for most people I work with.
When you check into a hotel, your key card is scoped to exactly what you need: your room, the gym, the business center if your rate includes it. Not every floor. Not the back office. Access is deliberately provisioned to match your role. That’s least-privilege access — and it’s what your M365 permissions should reflect.
The pool is open to everyone. You know not to bring your valuables there. The access model communicates the trust level without anyone having to say it out loud.
Now think about what’s actually happened in your M365 tenant over the last ten years. SharePoint sites provisioned for projects that ended in 2021 — still live, still accessible to the original team members who’ve since changed roles or left. OneDrive folders shared broadly “just for now” that never got cleaned up. Distribution lists that became the default audience for things they were never meant to hold. A guest account from a vendor engagement that wrapped up eighteen months ago.
None of this required malicious intent. It accumulated through convenience, time pressure, and the absence of a review cadence. And as long as finding a document required someone to know where to look and navigate there manually, the exposure was manageable. Slow. Human-filtered.
AI removed the friction.
What Copilot does, at its foundation, is act as an extraordinarily capable search and synthesis engine operating entirely within the authenticated user’s existing permissions. It doesn’t elevate privileges. It doesn’t bypass your access controls. It reads what the user can read, traverses what the user can traverse, and surfaces what the user could have found themselves — just faster, more thoroughly, and without getting bored three folders deep.
When someone asks Copilot to “find everything related to our Q3 pricing strategy,” it returns answers from emails, SharePoint, Teams conversations, and OneDrive — across every location the user has permission to access. That stale project site from 2021. That “anyone in the org” shared folder. That guest account that’s technically still active.
The AI didn’t create the exposure. It made the exposure impossible to ignore.
🔐 We Already Know Access Controls Work. MFA Proved It.
If you need evidence that authorization controls outperform content policies as a security investment, look at what the industry has learned from multi-factor authentication.
Microsoft’s research puts MFA’s effectiveness at blocking account compromise attacks at over 99 percent. CISA lists it as the single highest-impact security control most organizations can implement. Not endpoint detection. Not DLP policies. Not content labeling. A control that governs whether you’re authorized to access something at all.
The pattern is consistent: the security controls that prevent the most damage operate at the layer of access and authorization — not at the layer of content inspection after the fact.
The parallel to AI governance is direct. Sensitivity labels and DLP policies are content-layer controls. They’re valuable — but they’re most effective when they sit on top of a permission model that actually reflects organizational intent. Deploy them as a substitute for permission hygiene and you’ve built a sophisticated alarm system in a building where half the doors are propped open.
For the C-suite reader: this is why AI rollouts stall. It’s not the AI. It’s that the AI works exactly as designed — searching everything the user can access — and the security team realizes mid-rollout that the access model was never clean enough to be comfortable with that. The response is usually more policy. The correct response is to address the root cause.
This is why the right order of operations matters. Foundation first, governance layer second. That sequencing is how this actually works.
😬 Access Reviews Are Boring. That’s Why They Don’t Get Done. That’s the Problem.
Here’s the part nobody wants to put in the project plan.
The work that actually resolves this — reviewing permissions, auditing group memberships, cleaning up stale sharing links, removing expired guest accounts, scoping down app registrations, establishing group lifecycle policies — is genuinely tedious. It doesn’t have a product demo. It doesn’t generate a launch announcement. It doesn’t show up in QBRs as a success metric.
For the executive reader, here’s why this matters to you directly: when your CISO says the AI rollout needs more time, this is frequently what they’re describing — not a technical limitation of the AI itself, and not excessive caution. They’ve looked at the access model and they’re not comfortable enabling a powerful search tool on top of a decade of unreviewed permissions. They’re right to be cautious. And the way to go faster is not to push harder on the AI deployment. It’s to resource the access review.
So organizations reach instead for the things that look like security progress: sensitivity label taxonomies, elaborate DLP policy frameworks, Copilot site-level exclusion lists, Conditional Access policies layered five deep. These are all real tools. But when they’re deployed as a substitute for permission hygiene rather than on top of a clean permission model, they become compliance theater.
The security dashboard looks good. The actual problem sits untouched underneath. And you’re still in the contradiction — AI deployed, data locked down, productivity benefit evaporating.
Time spent on access reviews is more valuable than time spent building DLP policies and sensitivity label taxonomies. By a significant margin. Do that work first.
🤖 Then Came Agents. And We’re About to Make the Same Mistake Faster.
If the permissions problem was urgent at the level of individual users with AI assistants, agents make it critical.
We’re past the era of AI as a search interface. Autonomous agents — systems that act on behalf of users and organizations without requiring a human in the loop for every action — are proliferating fast. And the provisioning reality for agents today looks a lot like the provisioning reality for M365 sites in 2015: broad access granted quickly, review cadence nonexistent, sprawl accumulating before anyone notices.
App registrations get created under time pressure by developers and vendors who are thinking about functionality, not least privilege. Graph API permissions get requested at maximum scope because it’s easier, and because the person doing the setup won’t be the one dealing with the blast radius if something goes wrong.
MCP servers — the connectors that give AI agents access to data sources and tools — can be stood up in minutes. Locally. In a container. Without formal security review. With credentials that carry far more access than the specific task actually requires.
A user is constrained by human bandwidth: they can only click so fast, read so much, act on so many things in a workday. An agent at machine speed, with broad permissions and an open mandate, has no such throttle. The blast radius of a misconfigured permission or an overly broad prompt is significantly larger.
The principle of least privilege has never mattered more. It has also rarely been less consistently applied.
🏷️ DLP and Labels: Powerful Tools. Frequently Misapplied.
Let’s work through some of the most common scenarios we hear — because the instinct to reach for DLP and sensitivity labels is often genuine, even when it’s pointed in the wrong direction.
“We need to keep PII out of Copilot.”
Why? If the wrong people have access to PII, that’s a permissions problem. Fix the access. If only the right people have access to it — your HR team, your benefits administrator, whoever is authorized — then Copilot surfacing that data to those people is identical to those people opening the file themselves. You’re not creating a new exposure. You’re giving authorized users a faster way to do what they were already authorized to do. The answer here isn’t a DLP policy. It’s an access review.
“We need to keep HIPAA data away from AI.”
Same logic. Clinical staff authorized to view PHI using Copilot to summarize patient records is no different than those staff reading the chart manually. Copilot doesn’t send that data anywhere new — it surfaces it to the person who already has rights to see it, within the same M365 boundary covered by your vendor data commitments. If the concern is that the wrong people might have access to PHI, that’s not a Copilot problem. That’s a permissions problem that existed before Copilot arrived.
“We need to keep customer contracts out of AI.”
If only your legal team can access customer contracts, Copilot will only surface them to your legal team. What’s the specific exposure you’re solving for? If the answer is “I’m not sure the right people are the only ones with access” — that’s your permissions model telling you something. Go fix it.
Now, there is one scenario here where a DLP policy is the right call: if a specific customer contract contains a clause that explicitly prohibits the data from being processed by a third-party AI system, that’s an externally imposed constraint that permissions alone can’t enforce. In that case, a DLP policy scoped to that specific content is exactly the right tool. The key word is specific — a contractual obligation on particular content, not a blanket restriction driven by general discomfort.
“But what about data moving around? Files get shared, emailed, downloaded.”
Now we’re getting somewhere. This is a real and legitimate concern — and it’s exactly what sensitivity labels were designed for. But here’s where the specific tool matters.
A standard sensitivity label without encryption (a non-encrypted label in Microsoft Purview Information Protection) is just metadata. It tells Copilot and DLP policies how to treat a file, but the protection only exists inside the systems that honor the label. The moment that file leaves your tenant — emailed to a partner, downloaded to a personal device, uploaded somewhere else — the label is there but the enforcement isn’t.
An encrypted sensitivity label (using Microsoft Purview’s Rights Management encryption, sometimes called Azure Information Protection) works differently. The encryption is tied to identity. If a user is authorized to decrypt the label, they can use the file — including in Copilot. If they’re not, they can’t — regardless of where the file ends up. The permissions travel with the document.
This means an authorized attorney can use Copilot to work with an encrypted contract, while an unauthorized user in the same org can’t surface it at all, and an external recipient who downloads it can’t open it without the right identity. No DLP policy required to manage Copilot access — the identity-based encryption handles it automatically.
The encrypted label is the bridge between “get your permissions right” and “govern data that moves” — without creating the contradiction of blocking authorized users from their own AI tool.
So when is a DLP policy actually the right call?
When the constraint comes from outside your organization — not from a perceived internal risk that proper permissions would already solve.
The clearest examples:
- A customer or partner contract that explicitly prohibits AI processing of that specific data
- Regulatory frameworks that restrict AI processing of certain data types in certain jurisdictions
- NDAs or agreements with explicit AI processing clauses
The pattern is consistent: when an external party — a regulator, a customer, a contracting authority — has placed a processing boundary on your data, DLP is the right enforcement mechanism. When the restriction exists because you’re generally uncomfortable with what AI might find internally, that discomfort is pointing at your access model, not at a DLP policy gap.
The problem isn’t the tools. It’s the sequence — and the reason.
🗺️ The Right Order of Operations
None of this is exhaustive, but this is the sequence that actually pays off.
- Know what you have. SharePoint Data Access Governance reports. OneDrive sharing reports for long-tenured and recently departed employees. Purview Content Explorer to understand where sensitive data actually lives before you start governing it. App registration inventory via Entra — review Graph API scopes, identify anything broader than necessary.
- Find the overlap. The highest-risk surface is where sensitive data and broad access intersect. A SharePoint site with financial projections accessible to “Everyone except external users” is a materially different risk than one scoped to the finance team. Find that intersection. That’s where you start.
- Do the work. Entra ID Access Reviews for groups with broad or privileged access. Guest account review and expiration. Sharing link cleanup — remove or expire “anyone” and org-wide links that have accumulated. App permission scoping to least privilege. Group lifecycle policies that prevent the next five years of sprawl from rebuilding itself.
- Make it recurring. Quarterly reviews for high-risk groups and sensitive-data sites. Annual reviews for the broader tenant. Automated lifecycle policies. Access review is not a one-time project. It’s a cadence.
- Now layer the governance. With a defensible permission model in place, use encrypted sensitivity labels for data that needs to travel with its protections. Deploy DLP policies only for externally imposed processing restrictions you’ve specifically identified. Purposeful. Specific. On top of a foundation that holds.
- Enable AI broadly. At this point you know what users can see, what agents are permitted to do, and what can and cannot leave your environment. That’s a security posture. Deploy accordingly.
🚀 Final Thought
The organizations that will deploy AI well aren’t the ones that locked it down hardest. They’re the ones that recognized AI adoption for what it actually is: the most compelling business case anyone has ever made for taking data governance seriously.
For the C-suite: the reason AI feels slow is usually not the AI. It’s that your security team looked under the hood and found something they weren’t comfortable with. The right response is to resource the access review, not to push around it. Organizations that do the foundational work first will deploy with genuine confidence — and the AI will actually work the way it was supposed to when you approved the license.
For the technical leader: the unglamorous work is the work. Audit the key cards. Deactivate the ones that should have expired years ago. Establish the cadence that keeps it clean going forward. Then enable the AI on a foundation that actually holds — not one that requires an elaborate content policy framework to compensate for access controls that were never right in the first place.
The question was never whether to trust the AI. It was always whether to trust your own access model. Now you have to answer it.
Questions about where to start, how to structure the access review, or what the right DLP scope looks like for your environment — this is the work. Happy to talk through it.
