The restricted chunk cannot reach the generator. That includes its text, title, snippet, generated summary, citation key, and a “this result exists but you lack access” hint when existence itself is sensitive. A generator instructed to ignore a restricted result has already seen it. I would put permission into candidate retrieval where the index supports it and recheck current authority before assembling evidence, because an index can lag a revocation.

The irrelevant permitted chunk is safe to view, but permission is not a reason to use it. If it cannot support an answer, leave it out. The response should be “I don't have enough accessible evidence” or another retrieval attempt, not a plausible answer attached to the only citation we happened to find. These are two independent gates: allowed to disclose, and useful for the claim.

Rank 35 exposes the danger of global top-k then postfilter. If only the first 20 global hits are fetched and the first 19 are restricted, the system can wrongly conclude no authorized answer exists. Search within the user's authorized collection when possible. For a large, dynamic ACL, that may mean passing a permitted-document filter or a search principal to the engine, routing by tenant, or overfetching and continuing the search until a bounded number of authorized candidates is assembled. A final authoritative check remains necessary where revocation has a tighter freshness requirement than the index. Azure's vector filter modes show that prefiltering and postfiltering can have different recall behavior under selective filters. The precise behavior belongs to the chosen engine and query mode.

I would not promise “just fetch 35” as a universal fix. If the user's accessible fraction is 1 percent, a global ranking can need far more candidates, and the pattern may reveal information through timing or counts. Prefer a search plan scoped to allowed documents and impose a deadline and search budget. When an external search engine cannot efficiently prefilter the ACL, we need an architecture decision: a permission-aware index layout, a smaller exact filtered path, or an honest abstention under the budget. Never skip the final check to make the benchmark look good.

There is another subtlety in “rank 35.” Was that measured before or after the restricted results were removed, and is the authorized item truly answer-bearing? I would trace IDs through candidate generation, authorization, reranking, context selection, and cited span resolution for this query. Evaluate authorized answer-bearing recall, not global relevance recall. A result set containing the right secret answer can score well on an ordinary retrieval metric while being useless to this user.

If the authorized rank-35 result is current and supports the answer, retrieve it and cite its permitted revision. If it supports only part of the answer, say which part is known and what remains unsupported. If permission is revoked between search and generation, discard it and replan before any text is sent. The correctness condition is an answer grounded in what this principal can read now, not the best answer available somewhere in the corpus.