# Ask a reviewer to search as the wrong account

A retrieval review becomes more useful when the reviewer tries to cross a known boundary. Use a small, explainable exercise that reaches beyond the main search box.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Give the reviewer a clear policy

Prepare two test accounts and a few synthetic documents. Write down which account should see each document and why. Include a document shared between the accounts and one restricted to each. This prevents the review from becoming a guessing exercise about permissions.

Ask someone other than the query implementation's author to run the exercise. They do not need to be a penetration tester to find a missing boundary. They do need an expected result and access to the relevant diagnostic evidence.

Keep the fixture separate from production customer content. The aim is to prove how the system handles a permission relationship, not to see whether the reviewer can recognise real confidential information.

## Try the paths that are easy to overlook

Begin with the ordinary search box, then repeat the request through a saved conversation, a suggestion, a citation link and any export feature. If the application exposes a direct API, use the same account there too.

Try replacing a document identifier in a request with the identifier of a denied document. Try changing an organisation or group value supplied by the browser. A secure application should derive the caller's scope from trusted information rather than accepting these values as proof of access.

Also test an error path. Make the permission service unavailable in a controlled environment and observe what the application does. The question is whether it withholds protected content, returns a useful error or silently searches a broader collection.

## Ask for the evidence behind a pass

For a denied query, inspect the candidate passages and the material sent to the model. A friendly refusal on screen does not demonstrate that restricted content stayed out of the model request. For an allowed query, confirm that the expected source remains usable. A system that denies everything is not a successful implementation.

Use the following questions to guide the discussion, then record concrete answers beside the tested request identifiers.

- Which component establishes the user's current organisation and groups?
- What happens when a passage has no permission metadata?
- Which query paths can reach the index without the shared access layer?
- How does a permission removal affect an existing conversation?
- Who can read the trace produced by this test?

The questions are prompts for investigation, not a certification checklist. A tick is useful only when it points to evidence someone else can examine.

## Turn findings into changes with owners

Describe each finding as an observed behaviour. "The export endpoint returned document D to account B" is more actionable than "improve AI security". Include the expected result, the request that reproduced the issue and the boundary that appears to be missing.

Separate an implementation defect from an unresolved policy decision. If nobody has decided whether former project members retain access to archived conversations, an engineer cannot fix that ambiguity with a better filter alone.

After the correction, rerun the failing exercise and one allowed case on the same path. Keep the fixture with the application's tests. The review then contributes a durable check rather than a document that becomes stale after the next release.

## Sources

- [OWASP: authorisation testing guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)
- [Microsoft Learn: security filtering](https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search)