Applies tags, permissions, tenancy, recency, jurisdiction, document type, or other metadata filters incorrectly, excluding needed records or including forbidden or irrelevant ones. Unlike Retrieval Miss, the retrieval failure is caused by filter logic or metadata quality. Unlike Memory Scope Leakage, this concerns retrieval access boundaries, not persisted memory crossing scopes.
A generated filter uses an enum value that no longer exists after a taxonomy rename, matches nothing, and the empty result is reported as the documents not existing.
User: Find our security audits from 2024. [… generated filter: doc_type = "security_audit" — the taxonomy renamed the tag to "audit_security" last year, so the filter matches zero records …] Assistant: I couldn't find any security audits from 2024 — it looks like none were conducted.
A malformed predicate is silently dropped instead of erroring, and the search returns another tenant's records as if they were the user's own.
User: Show me our largest open invoices. [… the tenant_id clause is malformed and the query executes unfiltered across all tenants …] Assistant: Your largest open invoice is $84,000 from Meridian Logistics. [… Meridian Logistics is another customer's client; the user's tenant has no such invoice …]
The user's "recent legal docs from the EU" doesn't say how the conditions combine. The system picks OR over AND without flagging it, and the result set quietly includes documents that match only one condition.
User: Pull up recent legal docs from the EU. [… generated filter: date > 2025 OR jurisdiction = "EU" — results include a 2019 EU contract and a recent US filing …] Assistant: Here are the documents matching your criteria.
The applied filter is echoed back with the answer, so an over-strict or misread predicate is visible to the user instead of masquerading as ground truth.
User: Find our security audits from 2024. Assistant: Searching with doc_type "audit_security" and date range 2024 — zero results. Before concluding none exist, note the filter may be the issue: searching without the type filter, I find three 2024 documents tagged "security_review". Are those what you're after?
Filters are only as good as the metadata they query, and metadata is usually the weakest data in the corpus — inferred by ingestion heuristics, copied from inconsistent source fields, or left null. A correct filter over wrong tags excludes the right documents and admits the wrong ones.
Increasingly the filter itself is generated by a model translating natural language into filter syntax. That translation inherits every language-model failure — wrong field names, wrong enum values, misread date ranges — and a malformed predicate often fails open or matches nothing.
Taxonomies drift while filters stay fixed. Teams rename tags, split categories, and add document types, and every filter written against the old schema silently starts missing the new records.
Permission models do not map cleanly onto metadata predicates. Source systems express access through groups, inheritance, and sharing links, while the index flattens this into static tags, and anything lost in that flattening becomes an over- or under-inclusion at query time.
Boolean filter logic has sharp edges that natural language hides. Users say "recent legal docs from the EU" without specifying how the conditions combine, and AND-versus-OR choices, null handling, and timezone boundaries on date cutoffs each flip records in or out.
Filter errors are silent in both directions. An over-strict filter looks like an empty corpus and an over-permissive one looks like a successful search, so without auditing which filters fired and what they excluded, neither failure produces an error signal.
Categories of checks that can identify the issue. These are strategies, not specific implementations.
Log every executed filter with its predicate and match count. Zero-match filters are review candidates rather than proof of absence, and any clause dropped or malformed at execution time should alert rather than silently fail open — that silent drop is the tenancy-leak case.
Regularly sample indexed records and validate their tags against the live taxonomy — enum values that no longer exist, null rates per field, permission tags diverging from the source system. A correct filter over drifted metadata fails exactly like a wrong filter.
Maintain natural-language requests with known correct result sets — including ambiguous boolean phrasings, date boundaries, and renamed tags — plus isolation probes that query for another tenant's records and must return nothing. Score both directions — wrongly excluded and wrongly included.
High-level reliability strategies that reduce how often this failure occurs.
Apply tenancy and permission filters in the infrastructure layer, not as model-generated predicates, and make a malformed or missing security clause an error rather than an unfiltered query. The cross-tenant invoice leak happens precisely because the broken clause was dropped instead of refused.
Validate every generated predicate against the live taxonomy before execution — field names, enum values, date formats. A filter referencing the renamed "security_audit" tag should fail loudly at validation, not execute cleanly against zero records and masquerade as an empty corpus.
Have the system echo the applied filter back with its results, treat zero matches as a filter-review prompt rather than proof of absence, and ask when a boolean combination is ambiguous — "recent AND from the EU, or either?" — instead of silently picking one reading.