Permission-aware retrieval: the security question enterprise AI keeps getting wrong

The Curiosity Team

• 2026-07-01

Permission-aware retrieval: the security question enterprise AI keeps getting wrong

Every enterprise AI project reaches the same uncomfortable moment. The assistant works. It answers questions from company data, cites its sources, and people start to trust it. Then someone asks: what stops it from telling me something I'm not allowed to see?

That question rarely has a good answer, because permissions were an afterthought. The data was indexed, the model was wired up, and access control got bolted on at the end — usually as a filter on the way out. That's the part most teams get wrong, and it's worth understanding why.

Where the leak actually happens

The common design looks reasonable. The assistant retrieves whatever is relevant, the model writes an answer, and a check at the end hides any source the user wasn't cleared for. Sources they can't access don't appear in the citations.

The problem is that by the time you filter the citations, the model has already read the restricted document. It reasoned over the salary figure, the unreleased financials, the HR note — and folded them into the summary. You can hide the link to the source. You can't easily un-say the sentence the model wrote because of it.

An employee asks the assistant to summarise "everything we know about the Q3 reorg." Retrieval pulls in a restricted planning doc. The citation gets stripped on the way out, so it looks clean. But the summary still mentions the two roles being cut — because the model saw them. Nobody attached a file. The information still leaked.

Post-filtering protects the footnotes. It doesn't protect the answer.

Permissions belong to the data, not the response

The fix is to move the check upstream. The model should never retrieve a record the user can't access in the first place — so there's nothing to leak, redact, or reason over by accident.

That only works if permissions travel with the data instead of sitting in a separate layer that runs last. Every record carries who can see it. Every query is made on behalf of a specific user. Retrieval resolves the two together and returns only what that user is already entitled to. The model works from the same view of the world the user would get if they searched by hand.

The difference in one line: post-filtering hides the answer; permission-aware retrieval means the model never had it.

It's a correctness problem, too — not only a security one

Leaks are the obvious risk. The quieter one is that ignoring permissions makes the AI wrong.

An assistant that retrieves across everything, for everyone, answers as if every user were an administrator. Ask it "how many open reqs does my team have?" and it counts reqs the asker can't see. Ask "what's the status of the deal?" and it pulls a version of the deal the asker isn't on. The answer is confident and precise and describes a company the user doesn't actually work in.

Permission-aware retrieval fixes both problems with one mechanism. The user gets answers grounded in exactly the data they're allowed to use — which is also the only data that produces a correct answer for them.

What this looks like in practice

Getting this right means enforcing access in a few places that are easy to forget:

• At the field, not just the document. Sometimes a record is fine to see but one field on it isn't — a salary column, a customer's contract terms. Access control has to reach individual fields and record types, not just whole files.
• Everywhere data is read back. Not only the AI answer, but search results, facet counts, and autocomplete. A filter that returns zero results still leaks that something matched. The count itself is information.
• On the tools the assistant can call. An AI assistant that can run actions needs those actions scoped too. A tool a user can't access should be invisible to their assistant — not merely refused when called.
• With a record of what happened. When retrieval respects permissions, you can also prove it did: a tamper-proof audit log of who asked what, and what the system returned, turns "trust us" into something you can actually inspect.

None of this is exotic. It's the same access model the rest of the business already runs on — applied at the moment the AI reads data, instead of after it speaks.

The takeaway

If you're evaluating an enterprise AI system, don't ask whether it "supports permissions." Almost everything claims to. Ask when the permissions are applied. If the answer is "we filter the results at the end," the model is still reading things it shouldn't, and you're one prompt away from a leak that never shows up in a citation.

Permission-aware retrieval is the version that holds up in production: access enforced with the data, resolved per user, on every read — search, facets, tools, and AI answers alike. That's how Curiosity is built. Permissions live on the graph, retrieval resolves them for the person asking, and the assistant only ever sees what that person could see themselves.

Want to see how it works on your own data and access model? Talk to an engineer.