# Investigating a suspected retrieval leak

When an assistant appears to reveal a restricted document, contain the affected path and preserve enough evidence to find where access was lost.

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

## Establish what was actually disclosed

Start with the reported answer, its request identifier and the account that received it. Ask whether the answer contained restricted text, whether a citation opened a restricted source, or whether the user recognised a fact that may also exist in an allowed document. These are different observations and may lead to different causes.

Avoid asking the reporter to paste confidential material into an ordinary support ticket. Use the organisation's approved incident evidence channel. Record the time, document identifier and a description of the affected information so the investigation can proceed without spreading the content further.

If the report appears credible, restrict the affected retrieval path while the investigation continues. Depending on the scope, that may mean disabling one connector, excluding a document collection or temporarily withholding generated answers. Choose a control that actually stops the suspected disclosure rather than merely removing the citation link.

## Preserve versions before clearing caches

Capture the application's effective view of the user's organisation, groups and document access at the time of the request. Current membership alone may not explain what happened earlier. Record the source version, permission version, index version and cache key version associated with the answer.

Preserve relevant configuration and deployment identifiers. A query handler changed during a release may have omitted a mandatory filter, while the current version looks correct. If the incident spans a deployment, compare requests on both sides of that boundary.

Clearing a cache can be a reasonable containment action. Before doing so, preserve the metadata needed to identify which entry was served and why it was considered valid. Keep the evidence in a restricted location with an owner and retention decision.

## Follow the passage through the system

Trace the reported source from ingestion to the final response. Check the permission metadata stored with its passages. Then inspect the query filter produced by the application and the candidates returned by search. Finally, inspect the selected model context and any stored answer reused by the request.

This sequence narrows the fault. Correct index permissions with an absent query filter point towards the query handler. A correct search response followed by a forbidden cached answer points towards answer reuse. A source link that bypasses access checks points towards the citation or download endpoint.

Use a synthetic reproduction where possible. Copy the permission relationship and request shape into a controlled fixture, replacing sensitive text with a unique marker. This lets engineers repeat the failure without giving a wider group access to the original material.

## Restore the path with a regression case

Do not restore the affected feature solely because one manual request now looks correct. Add the failing relationship to the access test suite and exercise fresh queries, existing conversations, caches and source links. Include any error fallback involved in the incident.

Record what the fix does and what it does not address. An index repair may correct existing records while leaving an ingestion bug able to recreate them. A query fix may protect the main assistant while an export endpoint still uses the old access layer.

The incident owner should decide when containment can be lifted, using the organisation's response process. Finish with assigned work for any remaining source-data repair, access review and monitoring. A technically corrected query is only one part of closing the incident.

## Sources

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