The Permission Filter Becomes the Reconstruction Oracle
A permission check can hide the forbidden row while shared query processing still reveals that the row exists.
When an interface permits expressive repeated queries, a small existence leak can become a reconstruction channel.
The Paper
The source is Zachary Espiritu and David Cash's Plaintext Recovery Against Post-Filtering Access Control, arXiv:2608.11730v1 [cs.CR], submitted August 12, 2026. The arXiv record identifies it as the 21-page full version of a paper in the 35th USENIX Security Symposium. Espiritu is affiliated with MongoDB Research and Cash with the University of Chicago.
The paper studies fine-grained controls over shared physical indexes: row-level security in PostgreSQL and document-level security in Elasticsearch and OpenSearch. Its central finding is not that permission rules vanished. In the threat model, policy enforcement still returns only authorized results. The leak comes from observable behavior produced before or around that final filtering step.
Authorization After Computation
A result-only audit asks whether an unauthorized row or document appears in the response. Post-filtering can pass that audit because the protected item is removed. A stronger isolation audit asks whether changing hidden data changes anything the requester can observe. If execution time, ranking score, query expansion, error behavior, or another response feature depends on the hidden corpus, the system can disclose a fact without returning the protected object.
The paper assumes a legitimate user with mediated query access, some knowledge of the schema or data domain, and no ability to bypass enforcement, read raw storage, or alter another user's records. The document-search case also permits the user to add records it is authorized to own. This is a narrower and more useful claim than “access control is broken”: the relevant question is whether a particular deployment combines shared processing, the necessary query features, and an observable data-dependent signal.
Two Channels, One Design Error
In the PostgreSQL evaluation, the authors tested version 18.1 over a network and used timing differences from indexed, policy-filtered queries. Range predicates reduced large possible-value domains, while conjunctions associated recovered values across columns. The governance point is the amplification: an apparently small existence signal became enough to reconstruct rows in the controlled setup. The paper does not require a missing policy check; it studies work performed on hidden data before the policy has finished shaping what the user can observe.
The document-search evaluation used OpenSearch 3.6.0 and Elasticsearch 9.3.3 with document-level security, a single shard, default BM25 scoring, and a controlled Enron-email corpus. Scores and prefix expansion depended on corpus-wide indexed terms even though private documents were not returned. Under the tested indexing configuration, the researchers recovered term sets and short term sequences, then demonstrated approximate text reconstruction. The technical channel differs from timing, but the institutional mistake is the same: permission-aware output sits downstream from permission-unaware computation.
The Result and Its Boundary
The authors did not test production services or private user data. Their machines and databases were under their control, and they disclosed the work to PostgreSQL, Elastic, and OpenSearch before publication. The PostgreSQL study gave the test user arbitrary read queries over the target table. The search study allowed protected reads, visible score observation, and authorized record injection. Those capabilities may be absent or constrained in an application-mediated interface.
The document experiment also assumed stable corpus statistics during an adaptive run and used a single-shard configuration. The paper says live concurrent writes can disturb the signal, and it leaves narrow fixed-query application interfaces for future evaluation. Approximate document reconstruction did not uniquely recover document boundaries or the exact original text. These are not reasons to ignore the result; they are the conditions that keep a laboratory reconstruction from becoming a blanket claim about every row- or document-level control.
Mitigation Changes the Architecture
For the tested PostgreSQL policy, the authors' mitigation combined tenant-leading composite indexes with a policy rewrite visible to the query planner. Either change alone was insufficient in their benchmark. Together they confined the relevant index work to the requesting tenant, but the authors warn that this is not a general replacement for row-level security: complex policies and many indexed attributes can resist or burden that design.
For document search, the mitigation discussion moves scoring statistics and term expansion toward the user's visible corpus, removes some score components, or separates indexes. Each option changes utility, performance, or operational cost. Noise and delays may raise attack cost without establishing independence from hidden data. The durable control is architectural: do not let unauthorized data affect requester-visible computation. The paper's version 2 Zenodo artifact provides its experiment software under Apache-2.0 for deployment-specific testing.
The Retrieval-Layer Lesson
This is a database-security paper, not an evaluation of retrieval-augmented generation or autonomous agents. Its relevance to AI infrastructure is nevertheless direct as a design inference. An enterprise assistant can correctly omit a forbidden document from its answer while the search layer still exposes data-dependent scores, counts, latency, completion behavior, or retries to a caller. A connector permission map therefore does not complete the confidentiality argument.
Review should follow the whole decision path: identity and policy resolution, query translation, planner behavior, index access, ranking, expansion, caching, redaction, returned metadata, timing, and repetition. The question is not only “Did the model see the document?” It is also “Could any component learn from the hidden corpus and return a measurable trace?”
The Isolation Receipt
An isolation receipt should record the database and version, tenant layout, policy text, enforcement stage, query templates, allowed predicate families, index and shard design, scoring configuration, returned metadata, timing exposure, write or injection rights, rate limits, cache state, concurrency conditions, side-channel tests, mitigation, residual leakage, artifact or replay reference, reviewer, rollback rule, and date. A passing receipt should include paired tests where authorized data stays fixed while hidden data changes.
The Governance Standard
Do not certify confidentiality from a clean result set alone. Test noninterference across the observables a real principal receives and across the expressive queries that principal can compose. State the prerequisites and negative results, preserve the exact configuration, and re-run the test when indexes, planners, scoring, policies, or interfaces change. A filter is a boundary only when the computation around it also respects the boundary.
Related Pages
- Vector Databases
- OpenFGA
- AI Data Security
- The Enterprise Connector Becomes the Permission Map
- The Vector Database Becomes Institutional Memory
Sources
- Zachary Espiritu and David Cash, Plaintext Recovery Against Post-Filtering Access Control, arXiv:2608.11730v1 [cs.CR], submitted August 12, 2026.
- Authors' version 1 HTML paper, PDF, and source archive, reviewed for threat model, configurations, evaluations, limitations, mitigations, ethics, disclosure history, and artifact availability.
- Official USENIX Security '26 paper record and the authors' Zenodo software artifact, version 2.