Who Can Read That Answer? Permissions for Internal AI Search

By Greg Nowak. Last updated 2026-10-19.

Before you give more people access to an internal AI assistant, ask for evidence that it respects their document permissions. A search spanning staff guidance, management files and several clients’ project folders needs a clear answer to one question: why was each retrieved passage available to this person?

Retrieval-augmented generation, or RAG, brings searched material into an AI answer. Reviewing its permissions means following that material from the source document through indexing and retrieval. The approach below sets out what to check before expanding access to more staff or contractors.

Start with the person asking

At login, the server needs to establish the user’s identity and resolve which groups, projects and client workspaces they can access. Review authentication and authorization separately. Knowing who someone is does not establish which documents their request may retrieve.

Agree the access rule before choosing filter syntax. A client-workspace rule might require both membership of the correct workspace and permission to read the document. Validate that rule with the document owner. A department label alone may not capture the permissions the business actually needs.

The browser can request a workspace, but the server must check that choice against trusted access information. If it cannot establish the identity or permitted scope, reject the request. Specify this behavior explicitly: an empty group list must never cause a search across everything.

Check what happens to permissions during indexing

Review content and access metadata together. Record the source document identifier, its permissions and any client boundary required by the agreed policy. Then check what reaches the search index.

Microsoft’s document-level access overview distinguishes generally available security filters, which use string matching, from preview identity-based permission features. The filter pattern connects the caller’s identity to permission information stored in the index. Microsoft also explains that, when documents are split into chunks, permission metadata must be carried into the index projections.

Inspect both the parent document and its searchable passages. Repeat the check after replacing a document or rebuilding the index. For this design, content with unresolved permissions should stay unavailable until a named owner has settled who may read it.

Enforce access when the search runs

OpenAI’s file-search documentation shows metadata filtering through the tool’s filters configuration, using a category attribute in its example. That gives an integration a filtering mechanism. Connecting the filter inputs to trusted business permissions still needs to be implemented.

In an OpenAI integration, the server should select the permitted search scope and build the filter from the authenticated user’s access. A client identifier supplied by the user needs validation. Trace the complete route from question to tool request, including any alternative route the application can use to search.

Configuration can change the result just as much as application code. Elastic documents that leaving out a document-security query disables document restrictions for that indices permission entry. It also combines document restrictions across roles using OR. An unrestricted role can therefore grant access to all documents even when another role applies a restriction.

Inspect the effective permissions of the identity performing retrieval, including its combined role grants. The evidence should show that unauthorized passages were excluded before reaching the model’s context. An answer that happens to leave out a confidential detail does not establish that retrieval respected the boundary.

OWASP’s sensitive-information-disclosure guidance supports least-privilege access and restricted data sources, and warns that system-prompt restrictions may be bypassed. Prompt guidance can add another measure, but document access needs enforcement in the retrieval path.

Test with users who should get different results

Create a small set of fictional, clearly marked documents with known permissions. Write down the expected results before running searches. Each test should include an authorized user too; otherwise, a broken service returning nothing to everyone could appear to pass.

Run these checks through the application’s actual search endpoint, using ordinary questions as well as direct requests for restricted documents. Record the identity, expected decision and retrieved identifiers. Keep the evidence limited to what the review needs.

How quickly does removed access take effect?

Test revocation separately. Retrieve an allowed test document, remove access at the authoritative source, then repeat the request. Inspect each stage until retrieval stops.

Microsoft’s overview states that native query-time checks use permission metadata already synchronized into the index. Changes at the source take effect in search after the relevant synchronization mechanism updates that metadata. Even a permission-aware query therefore needs a documented refresh process.

Agree an acceptable revocation window with the business and assign someone to own it. Test delayed and failed updates. If the system cannot meet the agreed window, decide whether affected searches should be suspended or the source excluded until the design improves.

Include saved answers and conversation history in this review. Decide whether later requests may reuse previously retrieved content and who can reopen saved conversations, then test those paths. Passing a fresh-search test tells you nothing about whether retained material remains accessible.

Give the permissions review a clear scope

A useful first engagement should leave you with a map of source permissions, agreed access rules, a walkthrough of the current retrieval path and acceptance tests with clear expected results. That gives the business something concrete to approve and defines the implementation work.

Greg could then implement the agreed changes: carrying access metadata through indexing, building server-enforced retrieval filters, handling permission updates and testing separation between users and clients. The handover should identify who owns each source and who maintains the revocation process, so access changes have an owner after delivery.

If your internal assistant is moving beyond its first pilot, GrN can help review its permissions and turn the findings into an implementation plan with access boundaries you can demonstrate.

Related on GrN.dk

• Before an AI Assistant Issues a Refund, Put Approval in Its Path
• NGINX Can Read JSON Before Routing—Should It Handle Your AI API?
• The Answer Was in the Old Handbook: Keeping an AI Assistant Current

Need help with this kind of work?

Discuss an AI search permissions review Get in touch with Greg.

Sources

• Microsoft: Document-level access control in Azure AI Search
• OpenAI: File search
• Elastic: Controlling access at the document and field level
• OWASP: Sensitive Information Disclosure