we replicated your permissions

The Copilot guide is about an assistant reading your live permissions and finding them wider than you thought. The RAG index guide is about a homemade index that dropped the permissions entirely. This one is about the products in between: the ones that keep your permissions, as a copy.

Most of these products do not read your permissions live. They read them when they index your files and store the answer alongside the content. Every query after that is answered against a snapshot.

The marketing phrase is permission-aware. The accurate phrase is that they replicated your permissions, and the replica is exactly as current as the last crawl.

the vendors say this themselves

Nobody is hiding this. It sits in the documentation, stated plainly, and the gap is between what the docs say and what the sales page implies.

Glean’s documentation says it fetches the permissions map from each source and applies the permission snapshot mirrored during crawling and incremental updates. That last clause matters: the snapshot is refreshed, and the question is how often. Microsoft’s search documentation describes query-time enforcement as checking the caller’s claims against permission metadata already stored in the index.

Read those carefully and the mechanism is the same in both: the check happens at query time, against data that arrived at crawl time.

Microsoft’s documentation goes on to say that permission changes show up in results only after the metadata is synchronised to the index, and that some inherited permission changes need an explicit resynchronisation.

No vendor publishes a number for that lag. It is your crawl schedule, which is a setting somebody configured once.

the switch that turns a permissioned corpus flat

Amazon’s version has a detail worth putting on a wall.

Its business search product crawls access control lists per connector. If access-control crawling is disabled, AWS’s own blog says, indexed content in that source is considered accessible to users with access to the application.

One setting, on one connector, turns a corpus with permissions into a corpus without them, for everybody who can reach the assistant.

Nobody flips it maliciously. It gets flipped because ACL crawling is slow, or because a connector’s permission model is awkward, or because somebody is trying to get a pilot working before a demo. And once flipped, nothing about the resulting behaviour looks wrong. The assistant answers questions. It answers more of them.

where the permission check actually happens

1. 1crawlThe product copies the document and its permissions.
2. 2you change accessSomebody is removed from the document in the source system.
3. 3queryThe answer is checked against the copy, which still has the old permissions.
4. 4next syncOnly now does the copy catch up. When is that?

your version of this is smaller and worse

Most companies your size have not bought an enterprise search product. You have two other things instead.

The first is the assistant that came with your collaboration suite. Google’s documentation says Gemini cannot use Workspace data beyond what the signed-in person can already reach. What it does not spell out is whether that check runs against live permissions at the moment you ask, or against an index that catches up later. For a Workspace company, that is the most important open question in this guide, and the test at the end is how you answer it for yourself.

The second is somebody clever who pointed a vector database at a Drive folder, because it took an afternoon and it worked.

There is no per-document access control in that architecture. Pinecone’s own guidance for serving multiple tenants is namespaces and metadata filters, which is isolation you build in your application code. The other popular vector stores have the same shape.

So the API key is the whole authorisation system for your content. These products do have organisation and project roles, including read-only keys, so the caveat is precise: the access control operates on the index, never on the documents inside it. Anything holding a key that can read, reads everything, and what it reads is a copy of documents that had permissions when they lived in Drive and do not have them any more.

Two consequences, and the second is the one people miss.

When you remove somebody from a document, nothing happens in the index until the next sync, and your sync interval is a number you have probably never looked at.

And when somebody exercises a deletion right, you now have two deletions to perform, in two systems, and only one of them has a delete button anybody knows about. European data protection law reaches derived copies of personal data, and an embedding is a derived copy. Regulators have written about unlearning in model parameters, and say very little about retrieval indexes. So the obligation is fairly clear and the guidance is thin.

the part that is real and the part that is oversold

There is a research literature on whether an embedding leaks the text it came from, and it gets cited badly in both directions.

What was demonstrated: work presented at EMNLP in 2023 recovered 92% of thirty-two-token inputs exactly, using an iterative correct-and-re-embed method, and recovered full names from clinical notes. Earlier work at ACM CCS in 2020 showed partial input recovery and attribute inference.

What was not demonstrated: anybody reconstructing a production corpus from a stolen index. Thirty-two tokens against a known embedding model with query access is a real result, and it is a long way from a document dump.

So when a vendor tells you embeddings are just numbers and cannot be reversed, they are wrong. When somebody tells you a leaked vector store is equivalent to a leaked file share, they are ahead of the evidence. The index is a copy of your data in a form that is partially recoverable, and you should treat it as data. The embeddings guide goes further into this.

the closest public case

There is no published case of a retrieval index for an assistant exposing data across a permission boundary.

The closest analogue is a stale index, and it is instructive. In February 2025, TechCrunch reported researchers’ findings that more than twenty thousand GitHub repositories from over sixteen thousand organisations, made private or deleted, remained retrievable through Microsoft’s Copilot via a search cache, after the visible cache links had been removed. Microsoft rated it low severity.

That is a search index, so the analogy is only an analogy. It still shows the mechanism this guide is about: the permission changed, the copy did not, and the copy kept answering.

the question to ask, and the test to run

One question for any vendor in this category, and the answer tells you what you bought.

When I remove somebody from a document, how long until your index stops returning it to them, and what is the mechanism?

Acceptable answers name an interval, or a webhook, or a resync operation. “We respect your existing permissions” does not answer that question, and if it is the answer you get, ask again in writing.

Then test it, because it takes twenty minutes. Pick a document. Give a colleague access. Confirm the assistant surfaces it for them. Remove the access. Ask again, on a timer. Write down how long it took.

That number is a property of your environment that nobody at your company currently knows, and it decides whether your access reviews mean anything once an index exists.

Run it even if you expect a reassuring answer, because the test also shows you whether the index is the only copy. A removal that clears the index may not clear an answer somebody generated last week and pasted into a document that is now itself indexed. That is what happens when the output of one system becomes the input of another, which is the normal condition of a company that adopted these tools enthusiastically.

There is a second reason to run it yourself. Vendors describe their architecture accurately and your configuration not at all, and most products in this category let an administrator set the crawl schedule. So the interval that governs your exposure was chosen by somebody at your company, probably during setup, probably to make the first index finish faster, and probably never revisited. No support ticket will surface that.

the market take

The category sells permission-awareness and ships permission-replication. Both are defensible engineering, and only one of them is what the words suggest.

What to hold vendors to is disclosure. Tell me the sync interval. Tell me which connectors are live and which are snapshots. Tell me what happens when an inherited permission changes upstream. All three are in somebody’s documentation already, and none of them are on the page where the buying decision gets made.

And for the thing you built yourself: you have two copies of that folder now. Only one of them is governed.