No. The count reveals at least one matching document in a corpus the caller is not allowed to search. With repeated exact queries an attacker may infer whether particular cases, customers or projects exist. Elasticsearch's search API documents total-hit behavior. It does not recommend this hypothetical pipeline. The problem is our ordering of authorization and aggregation. OWASP's object-level authorization guidance applies to the data exposed by an API, not only the full record body.

I would capture the query as executed, authorized candidate predicate, total-hit calculation, facets, suggestions and response cache key. A team may filter the visible hits and forget that counts, aggregations, reranker scores, pagination cursors or autocomplete still came from the global result set. Test with two tenants, one secret canary document and a query that matches only the canary. Vary the caller, then inspect every returned field. Do not rely on a model's refusal to mention the count. If the tool returns it, the boundary has already leaked information.

The fix is to define search over the caller's authorized corpus, so matching, counting and aggregating all share the same effective access predicate. If a search engine cannot efficiently apply a dynamic policy inside candidate generation, use an index or query plan that can still produce authorization-correct results. Returning a global count rounded or noisy is a separate privacy product with its own threat model, not a substitute for a normal tenant search contract. Cache by full authorization context and policy version, or avoid caching sensitive count responses. Permission changes must invalidate or recheck access.

Could we just omit total_hits? That closes the obvious field and may leave a side channel through facets, suggestions or response behavior. Investigate the full surface, then decide which channels matter for the attacker model. A semantic cache served tenant A's private answer to tenant B. What now? covers a semantic cache serving tenant A's answer to B. How would you design retrieval when permissions change faster than the index? covers rapidly changing retrieval permissions. This question shows that even when every returned document was filtered correctly, metadata computed before authorization can expose a private fact.