Permission-aware AI retrieval is an approach to AI search that enforces an organization's access rules on every fact within a generated answer at serve time. While legacy access-control lists (ACL) correctly filter the documents available during the input stage, they leave the synthesized output completely ungoverned. Permission-aware retrieval closes that gap: every fact carries an audience derived directly from its sources, so a response reaches only those cleared for every underlying document.
The common enterprise design applies a narrower control. Documents are indexed, each chunk retains the access control list of its source file, and the index is filtered at query time to only include material the requester may open. This provides meaningful protection for basic free-form Q&A.
However, that protection ends with the retrieval step. Retrieval only governs the model's inputs. Without output-level enforcement, the answer's audience is determined entirely by where the answer eventually appears.
An AI answer is a new artifact.
Retrieval-time filtering answers whether a person may open a source. Generation creates a completely separate access question: whether that person may see the resulting answer. This distinction becomes critical as tools move beyond reactive search and proactively push intelligence into shared spaces.
The asker is not always the reader.
A permission check tied to a requester works only when the requester remains the sole reader. Modern enterprise AI doesn't just wait for questions; it proactively surfaces information. When an agent automatically generates a daily morning playbook or pushes a pre-meeting intelligence brief—detailing call attendees, stretch goals, and landmines to avoid—into a shared environment like Slack, the original source permissions are left behind. Once shared, visibility depends on the channel's audience.
Synthesis erases the fence.
An answer synthesized from multiple sources rarely preserves the access boundary behind each sentence. As agents use protocols like MCP (Model Context Protocol) to pull context across internal tools, individually routine facts can combine to reveal sensitive information. The most restricted input must govern the full output. Without a per-fact audience, placement becomes the default access control instead of provenance.
One synthesized answer
| Security capability | Legacy ACL filtering | WonderForce per-fact permissioning |
|---|---|---|
| Enforcement stage | Index retrieval (input only) | Serve time (output enforcement) |
| Proactive agent workflows | Destination controls visibility | Source audience governs visibility |
| Information synthesis | Erases source boundaries | Maintains strict intersection of rights |
Retrieval-time access control, in the vendors' own words.
This is not a defect unique to one product. It is exactly how retrieval-time access control operates by design — vendors document the behavior as expected rather than treating it as a bug. A major vendor in the category states it plainly in its own help center:
“[ClickUp's Brain's] responses are visible to anyone with access to the location where it was posted, whether they have access to the private data used by Brain or not.”
Source: ClickUpThe rest of the category documents the same boundary from the other side. Each vendor publishes, in its own docs, where its unit of reach sits — a dataset, a room, the set of sources that contributed to a result — and one states outright that access control on its own does not settle the question:
“All permissions in Cognee are defined at the dataset level, never for individual documents.”
Source: Cognee“[M]emory is written to the narrowest room a conversation happened in, and what a given conversation can read depends on where it’s happening and who’s asking.”
Source: Supermemory“Effective metadata is the union over every contributing source, so an extra value means a source the grant does not name helped produce the object.”
Source: Zep“Permissions alone aren’t enough to secure enterprise data for AI. Built-in sensitive data protection is essential.”
Source: GleanTaken together, these statements show an entire industry wrestling with the same core problem. The difference lies in the level of control.
Coarse permissions—like locking an entire dataset or chat room—only govern where files are stored. They can’t dictate who gets to read a specific sentence in a synthesized AI brief. Because synthesis combines multiple sources, only an access control attached to the individual fact will survive the generation process.
This vulnerability recurs anywhere an AI assistant operates collaboratively: answering questions in a shared channel, recalling memory that multiple people can trigger, or acting through one user’s connected account. While this page documents that architectural flaw and the solution required to close it, we have deliberately chosen not to publish a criticism piece. No attack corpus and no harness is published, because a public toolkit for extracting private material from a live workspace would create unnecessary risk.
What to demand from any AI retrieval vendor.
These are the guarantees that make retrieval permission-aware, stated as things a buyer can require and verify. Each one is testable in an evaluation on your own data — ask to see the check fail, not only the answer succeed.
- Every fact carries an audience, derived from source access.Not assigned by hand and not inherited from a file's current folder. Ask how a fact's audience is computed, and what happens to it when the underlying source's permissions change.
- An answer built from several sources reaches only readers cleared for all of them.The most restricted input governs the output. Ask what a reader sees when one supporting source is outside their reach: the answer should narrow, not arrive with a caveat.
- The check runs at serve time, on every request.Not once at indexing and not once per session. Ask what happens the moment someone changes team, leaves a project, or loses access to a source mid-session.
- An agent reaches exactly what its principal reaches — never more.A shared assistant, a connector, or an automation must not widen anyone's reach. Ask whether one person's private connection can be borrowed by a colleague through a shared agent.
- No source, no answer.When the only evidence for a claim is outside a reader's reach, the claim is not paraphrased, implied, or repackaged in a summary. Ask to be shown the refusal.
These criteria define the term; they are not a specification of any one product. WonderForce is built to them, and every claim it serves carries the supporting source a reader can open for themselves.
The same guarantees are what make an agent connection worth having. An agent that reaches this context through MCP answers from the company's current, permission-checked state rather than from a stale copy or a guess, cites the source behind each claim, and stops exactly where its principal's reach stops.
Questions people ask about permission-aware retrieval.
What is permission-aware AI retrieval?
Permission-aware AI retrieval is an approach to AI search that enforces an organization's access rules on every fact in an answer at serve time. Each fact carries an audience derived from its sources. An answer synthesized from several facts is available only to readers cleared for every source.
Isn't ACL filtering at retrieval enough to stop AI leaks?
No. Filtering the index by access control list governs the model's inputs, not the audience for the resulting answer. Once an answer is synthesized and pushed into a shared channel, agent memory, or a morning playbook, visibility is determined by that destination rather than by source permissions.
How is per-fact permission different from document-level permission?
Document-level permission determines whether a reader may open a file. Per-fact permission determines whether a reader may see a specific claim and preserves that boundary through synthesis. An answer drawn from several facts inherits the intersection of their audiences, so the most restricted input governs the output.
Can AI leak private company data even with permissions in place?
Yes — through synthesis and delivery. Permissions checked at retrieval govern which sources a model may read, not who may see the answer built from them. An answer pushed into a shared channel, retained in agent memory, or generated for a different reader carries private material past the original boundary unless access is enforced again at serve time.
Does RAG respect permissions?
Standard retrieval-augmented generation (RAG) filters the index at query time, which protects the model's inputs — not the synthesized output. The generated answer is a new artifact no source ACL governs. Permission-aware retrieval adds the missing half: every fact in the answer carries an audience, and the answer reaches only readers cleared for all of them.
Do AI agents respect user permissions?
Only if the underlying context layer enforces them at serve time. An agent connected through the Model Context Protocol (MCP) should reach exactly what its principal may reach — never more. A shared assistant or automation that widens anyone's reach, or lets one person's private connection be read through a colleague's session, fails this test.
One company brain. Personalized for everyone.
WonderForce is in private development. Join the waitlist for product updates.