What is permission-aware retrieval?

Permission-aware retrieval checks, for every record, whether the person asking may open it, before the record is ranked or handed to a model. It is how an AI assistant inherits the access control a company already runs, instead of answering every user as if they were an administrator.

It is narrower than access control in general, which decides who may sign in and which features they may use. It is also not the same as filtering an answer after the model has written it. The question it answers is which records may reach the model for this person, at this moment.

An assistant that searches SharePoint, Jira, a ticket system and the file shares can read far more than any one person can. If retrieval ignores permissions, every answer is written from that wider view. The salary table, the draft reorganization and the supplier contract are all one good question away.

OWASP lists this risk as LLM02:2025, sensitive information disclosure. It warns that restrictions written into a system prompt “may not always be honored and could be bypassed via prompt injection or other methods.” A prompt is an instruction to a model, not an access control.

Microsoft states the rule plainly for its own assistant. Its Copilot documentation says Copilot “only surfaces organizational data to which individual users have at least view permissions.”

It is also a correctness problem. An assistant that counts open tickets across records the asker cannot see gives a precise number about a team they are not on. The only data that produces a right answer for a person is the data that person may use.

There are three places to put the access check, and only one of them holds.

• On the answer. The model reads every match and writes its answer, and a filter removes the citations the person may not open. The model has already read the restricted record. Hiding its link does not take back the sentence written from it.
• After ranking. Search ranks every match, then drops what the person may not open. Restricted records still took places in the ranking, so pages come back short. Counts and facets can give them away: a note that three results were hidden tells the reader three records exist.
• Before ranking. The person’s access is part of the query. A record they may not open never becomes a candidate, so nothing downstream can read it, count it or rank it.

The same check has to cover every way data is read back: search results, a record fetched by its id, facet counts, autocomplete and the tools an assistant may call. A path the check does not cover is the path that leaks. This is the zero trust principle NIST SP 800-207 sets out for networks, applied to retrieval: decide access on each request, with rules as granular as the data allows.

The permissions already exist. A SharePoint site has members, a Jira project has roles, a ticket belongs to a group. Permission-aware retrieval reads them from the systems that own the records. The alternative is a second rulebook someone rebuilds by hand, and it drifts from the first.

Two details decide whether the sync holds. The permission should be written together with the record, or there is a moment when a new record is searchable by everyone. And group membership should come from the identity provider, so a person who changes teams changes access in one place.

Syncing permissions also brings over their mistakes. This is oversharing: a folder shared with the whole company was hard to find by browsing, and an assistant finds it on the first question. Retrieval that respects permissions makes wrong permissions visible faster. The fix belongs in the source system, before it is connected.

A permission check is only as current as the permissions it reads. Google’s Zanzibar paper describes the system that checks access for Drive, Calendar and YouTube. It calls this failure the “new enemy” problem. The paper says it can arise “when we fail to respect the ordering between ACL updates or when we apply old ACLs to new content.”

Its example: Alice removes Bob from a folder, then asks Charlie to move new documents into it. If the check reads the folder’s permissions from before Bob’s removal, Bob sees the new documents. Zanzibar prevents this by stamping every change with a time and never checking against a snapshot older than the content.

An assistant has the same exposure, usually wider. Say permissions are copied into a search index once a night. Someone removed from a team at nine in the morning can still get answers from that team’s records until the next run. Ask how long a change in the source takes to reach the check, for records and for group membership separately.

Do not ask whether a system supports permissions. Ask where they live and when they are applied. Five questions cover most of it:

• Where does the check run: before ranking, after ranking, or on the answer?
• Does the same check cover search, fetch by id, counts, autocomplete and the assistant’s tools?
• Are permissions read from the source systems, and how long does a change take to arrive?
• Does access reach fields as well as records, such as a contract whose price only some may see?
• Is there a record of who asked what, and what came back?

Then test it. Sign in as two people from different teams, ask the same question and compare the records each answer cites. Remove one of them from a team in the source system and ask again. Prompt injection, an attack on what the assistant does with what it reads, is a separate question, covered in What is prompt injection?. A tight retrieval scope limits what a steered assistant can reach.

In Curiosity Studio permissions are edges in the same graph as the data. A user is a member of a team, the team owns a record, and the user may open it. Connectors write those edges as they write the records, so access is synced from the source systems. There is no second rulebook to keep in step.

Access is checked per record at query time. Search adds the person’s teams to every query as a filter, so nothing is filtered after ranking (the permission model documentation shows how). A record fetched by id goes through the same check, and AI features only use content the person may see. Node types, single fields, endpoints, AI tools and assistants can each be restricted.

Two limits are worth knowing. Team memberships from your identity provider refresh when a person next signs in, so an immediate revocation also means removing the user in Studio. And a record’s permissions are as current as its connector’s last run. The security page and the Trust Center have the rest.