Microsoft Purview Can Govern Data. Your Copilot Still Needs Authorization at Retrieval

Microsoft Purview has earned its place in the enterprise stack. It classifies data across the estate, applies sensitivity labels, enforces DLP, and gives compliance teams the inventory and audit posture they need. If your organization runs on Microsoft 365, Purview is how you know what data you have and how sensitive it is. None of that is in question here.

The question is narrower and more uncomfortable. When an AI copilot retrieves knowledge to answer a question, who enforces whether that specific user may retrieve that specific document, at that moment? Classification tells you a document is confidential. It does not decide, per query, whether the person asking is entitled to it. That is a retrieval-authorization problem, not just a governance problem, and it lives in a part of the pipeline that governance tooling does not reach.

Where Purview is the right answer, and where it stops

Credit where it is due: for Microsoft 365 Copilot oversharing, Purview together with Microsoft's own controls is the right toolset, and Gateco does not address that surface. Purview's labels, restricted search, and oversharing reports are built for Microsoft's Copilot experience over Microsoft's content stores. If your AI story starts and ends inside Microsoft 365, that is where the work belongs.

The gap opens when your team builds its own copilot, RAG pipeline, or agent: an internal assistant over a vector database such as pgvector, Pinecone, Qdrant, Weaviate, or Azure AI Search. The moment documents are chunked, embedded, and written into a vector index, the labels and ACLs they carried in the source system do not travel with them. Retrieval now happens in infrastructure your governance tooling has never heard of, and the entitlement question has to be answered there.

Retrieval is a new decision point

Follow one query through a typical pipeline. A user asks a question. The application embeds it and asks the vector database for the nearest chunks. The database ranks by semantic similarity and returns the top k. Nowhere in that path did anything evaluate the requesting user's entitlements. Similarity is not entitlement: when someone asks about compensation bands, severance terms, or a customer's contract, the index returns the closest chunks, not the chunks that person is cleared to see. The decision "may this user see this content" is never made, because the architecture has no point where it could be made.

How permissions break on the way into the index

Two failure modes cover most real incidents. The first is permission flattening at ingestion: a pipeline running as a privileged service account reads everything it can reach and writes it into one shared index, leaving the source ACLs behind. The second is metadata filtering used as a stand-in for authorization: tag each chunk with a team or sensitivity field and filter at query time. Filters fail open. A missing or mislabeled tag returns the chunk. And because entitlements change daily while embeddings are written once, the index drifts further from reality with every reorg, offboarding, and permission change.

The control: a live decision at the retrieval boundary

The control that closes the gap is late-binding authorization: evaluate the request at query time, before content is returned, using the identity of the requesting principal synced from your identity provider, the attributes and classification of the resource, the relationships between them where applicable, and the policy in force right now, not the one that was true at ingestion. Deny by default, so a missing label or an unmatched policy withholds content instead of releasing it. And record every allow and deny with the full evaluation trace.

This is what Gateco does. It is authorization middleware that sits between your agent and your enterprise knowledge: it gates twelve vector databases, syncs principals and groups from Okta, Microsoft Entra ID, AWS IAM Identity Center, and GCP Cloud Identity, evaluates RBAC and ABAC policies with classification ceilings at query time, and adds less than 25ms of overhead to a retrieval. Every decision lands in an audit trail your security review can actually use: who asked, what was in scope, which policies fired, and what was allowed or denied and why.

One question for your next security review

If you are putting a copilot, RAG pipeline, or agent over sensitive knowledge, take one question into the review: can you prove why each retrieved chunk was allowed? If the answer is a per-decision log with the policy evaluation attached, your retrieval boundary is governed. If the answer is a description of your labels and filters, you have governance metadata and an ungoverned decision point. Purview and Gateco are not competitors on this: one governs the data estate, the other authorizes the retrieval. For a side-by-side of where each tool applies, see the full Gateco vs Microsoft Purview comparison.