Key takeaway
Permission must survive the retrieval path. A restrictive prompt cannot repair an unrestricted search role.
Trace the request beyond the search box
A license can define permitted audiences, yet an implementation may use one broadly privileged service account for every user. Before an AI retrieval evaluation, trace the actual request: user identity, search role, document filter, retrieved passages, prompt context and final response. Check the boundaries on that path rather than inferring them from a product demonstration.
OWASP recommends validating authorization on every request and denying unauthorized access by default. Elastic documents a concrete composition trap: its document restrictions combine across roles with OR, and an unrestricted role can remove a restriction. That is product-specific behavior to check in Elastic; other systems need their own actual permission semantics.
A permissions matrix that includes a denied case
This hypothetical matrix uses two invented internal teams and three documents. Team A may read A-1; Team B may read B-1. Neither may read the held document H-1. The test identities are synthetic and the hold is explicit.
| Request | Permitted context | Expected result |
|---|---|---|
| Team A asks about A-1 | A-1 only | Answer with permitted citation |
| Team A asks about B-1 | No B-1 passages | No disclosure through answer or citation |
| Team B asks about B-1 | B-1 only | Answer with permitted citation |
| Either team asks about H-1 | No H-1 passages | Deny access before model context |
Test role combinations, not only single roles
Inspect the effective permissions of each test identity, including inherited and service roles. In the Elastic case, adding a role without document-level restrictions can broaden access despite an apparently restrictive role. Testing the restrictive role in isolation would miss the deployed combination.
Record the effective role set, filter version and documents actually retrieved for every matrix row. Confirm that denied passages do not enter the model context. Asking the model to omit a secret after it receives the passage places the boundary too late for this review. If the retrieval service cannot enforce a user-specific filter, stop and redesign that path before supplying real restricted records.
Check the paths that reuse an answer
Repeat the denied request after another authorized identity has asked it. Inspect whether a cache or conversation memory reuses a response without respecting the current caller’s permission. Also test a user whose access was revoked between requests. Save only the minimum diagnostic metadata needed to establish the behavior; broad logs can become another disclosure path.
Review snippets, highlights, citation titles and download links as well as the answer. A user can learn restricted content from a preview or a follow-up document request even if the initial answer is blank. The same authorization principle should apply to each exposed operation, although the specific mechanism depends on the receiving architecture.
Tie the result to one deployed configuration
A passing matrix should identify the tested role combinations, denied documents, retrieval configuration, cache policy and access-change cases. It supports a narrow statement about those exercised paths. It does not prove that all hidden operations are safe or that the underlying license permits the intended use.
Keep the technical evidence beside the permitted-use agreement, not in place of it. The rights review tool helps organize audience and onward-use questions; the diligence builder helps ask for implementation evidence. VOID’s possible named introduction is based on approved metadata, and does not grant document access to the receiving program or its end users.