# Permission filters belong in both retrieval branches

A secure keyword query does not protect an unrestricted vector query. Review the complete hybrid path, including merging, reranking and result reuse.

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

## Establish one access scope for the request

The application should resolve the caller's organisation and current access before starting retrieval. Both branches need to use that same scope. If one branch obtains groups from the session and another accepts groups from a request field, the system has two different interpretations of the user's rights.

Represent the scope through a shared, typed interface or another controlled boundary. This does not make the policy correct by itself, but it reduces the number of places where an engineer must remember to reconstruct it.

Decide what happens when access cannot be resolved. Returning an unrestricted candidate list and hoping a later stage removes forbidden material creates an unnecessary exposure path, especially if candidates are logged or sent to a model-based reranker.

## Restrict candidates before sharing them downstream

The keyword and vector branches should return only candidates eligible for the caller. Search engines differ in how they apply vector filters internally, and those choices can affect result coverage. Review the documented behaviour of the actual engine rather than assuming that every filter mode produces the same candidate set.

The security boundary is that forbidden content must not be passed to downstream consumers that should not receive it. A final user-interface filter is too late if the reranker, model request or tracing system has already seen the passage.

Carry source identity and access-relevant version information through merging. A deduplication step that keeps the text but drops the source identifier makes later access checks and incident diagnosis much harder.

## Test asymmetric mistakes deliberately

Create a fixture where keyword retrieval would find one protected source and vector retrieval would find another. Run it as a user who can access neither. This helps expose a missing filter in a single branch that an ordinary query might not reach.

Repeat with one allowed source so the application still has useful evidence to return. Check the merged candidate list, not only the final answer. Then make one branch unavailable and confirm that the fallback retains the same access boundary.

Test caches separately. A merged candidate cache must not be reused for another organisation merely because the question text is the same. If the cache stores passages, it also needs a policy for access changes after the entry was created.

## Include the people and tools that can bypass the application

Review credentials used by ingestion workers, query services and diagnostic tools. A broad search-service credential may be necessary for a particular internal operation, but it should not be exposed to the browser or used as proof of an end user's access.

Identify any direct index browser or support console. Decide who can use it and whether it shows protected passage text. A well-filtered public endpoint does not compensate for an unrestricted administrative interface given to every support user.

Close the review with a list of serving and diagnostic paths, the access control on each and a tested denied request. That record is more useful than a single claim that the search index has security enabled.

## Sources

- [Microsoft Learn: vector filtering modes](https://learn.microsoft.com/en-us/azure/search/vector-search-filters)
- [Microsoft Learn: security filter limitations](https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search)