The short version: permission filtering must happen before retrieval, not after. Post-filtering wastes Top-K slots and reveals "such a sensitive document exists" to the model and the logs—trading leakage for recall.
1. Where over-permission leakage comes from
Many teams have a sound permission model and a proper approval process, yet their RAG system still leaks. The failure is in the ordering: the system retrieves Top-K chunks first and judges permissions afterward. That sequence has two holes. First, if confidential blocks squeeze into the top K, filtering leaves far fewer than K useful blocks, and answer quality drops. Second, and more dangerous, by the time filtering runs, the confidential text has already entered the model context and likely the request logs and embedding cache. Even if nothing is shown to the user, leakage has already happened inside the system, and the logs become a new leak surface.
Picture a knowledge base at a nationwide commercial bank that holds public annual reports and internal risk notices side by side. Both describe the same companies and metrics, so they sit close in vector space. A business user asks an ordinary question, and a fragment of an internal notice gets retrieved. If the permission check runs after retrieval, the document's existence is already exposed: the user knows the file exists, and the logs retain its outline.
2. Three-level permission inheritance
The right order is tag first, ingest second, retrieve last. UGLYPEAR AI tags permissions at ingest across three levels: document → section → chunk. Document sets the baseline—an annual report is public overall. Section refines it—the risk-warning chapter alone is marked internal. Chunk lands on the smallest unit, so a single passage can be controlled precisely. Children inherit parent permissions, and secrecy merges by the highest: if any passage carries a higher level, the whole chunk takes it. Over-filtering beats under-filtering.
Rules come from two sources: regex matching and tag rule sets. Regex auto-tags on words like "confidential" or "internal," ID number patterns, and code formats; tag rule sets are written by the business system at ingest. Use both: auto-tag first, then spot-check by hand. Tagging quality decides everything downstream—if coverage is thin, every filter built on top of it stands on sand.
| Level | Role |
|---|---|
| Document | Baseline permission |
| Section | Refine by section |
| Chunk | Final atomic permission, highest wins |
3. How pre-filtering lands
Once the tags exist, the next question is when to filter. Pre-filtering scopes the blocks a user may see before retrieval, then runs vector and keyword search only inside that subset. Every Top-K slot is then authorized content—no wasted slots, and no exposure of sensitive documents' existence. The cost is one tag-based pre-screen, negligible next to the leakage risk.
Pre-filtering and desensitization are complementary lines of defense. Desensitization happens before chunking and embedding—the vector itself is a leak surface. Sensitive regions in embedded images—11 categories, including faces, license plates, seal signatures, and ID number zones, often counted as 13 in enterprise contexts—are blurred, mosaicked, or boxed before any vector is generated. Pre-filtering governs who may see a given vector. One erases sensitive content; the other keeps people out. You need both.
4. Tie it to evaluation
A permission system is not done when configured; it must enter the evaluation loop. Permission hit rate is one of the corpus-level metrics. Every build should measure two things: the share of chunks carrying a permission tag, and whether any over-permission hits remain after filtering. Thin coverage leaves chunks unguarded; a single residual hit is a hard red line.
UGLYPEAR AI splits permission tagging and secrecy filtering into 26 test scenarios covering inheritance, merging, and filtering, and all pass. Put coverage and residual hits on a dashboard, and permissions stop being a config item and become a measurable quality metric.
Permission is one slice of data security. Desensitization in Why Desensitization Must Precede Embedding; permission in evaluation in RAG Evaluation Metrics; pre-launch in 30-Item Checklist.
Common Pitfalls and Fixes: Post-Filtering Is Not Access Control
| Common Pitfall | Actual Risk | Correct Approach |
|---|---|---|
| Filtering results by permission after retrieval | Post-filtering wastes Top-K slots and shrinks useful results; differential probing can even reveal the existence of sensitive documents | Pre-retrieval permission filtering — sensitive chunks never enter the candidate set |
| Permissions set at document level only | Public sections inside a mixed document get locked away, hurting usability | Three-level inheritance: document → section → chunk content |
| Inconsistent permissions between parent and child chunks | A queryable child leaks its parent; privilege escalation slips through the seam | Merge by highest classification level across parent and children |
Rule sets are maintained as regex and tag rules, and every rule change must pass the regression gate — accidentally marking public content as confidential is also an incident in regulated industries. How the permission system pairs with private deployment is covered in Private Deployment and Data Sovereignty.
FAQ
Q1: Why filter permissions before retrieval?
Post-filtering wastes Top-K slots, so fewer useful blocks survive, and confidential text has already reached the model context and the request logs—the document's existence leaks either way. Pre-filtering keeps every Top-K slot authorized and shrinks the leak surface.
Q2: What are the three permission levels?
Document, section, and chunk content level. Children inherit parent permissions, and secrecy merges by the highest: one higher-tagged passage makes the whole chunk take that level. Over-filtering beats under-filtering when in doubt, because a leaked chunk cannot be recalled.
Q3: Where do permission rules come from?
Regex matches and tag rule sets. Regex auto-tags on words like confidential or internal, on ID number patterns, and on document code formats; tag rule sets are written directly by the business system at ingest. Auto-tag first, then spot-check and correct by hand.
Q4: How is the permission system proven effective?
Through permission hit rate, a corpus-level metric: track the share of chunks carrying permission tags, and whether any over-permission hits remain after filtering. Coverage measures tagging completeness; any residual hit is a hard red line that means a rule has a hole.
Related Articles
Need Production-Ready RAG Data Pipelines? Meet UGLYPEAR AI
A privately deployed RAG data engineering platform: parsing, cleaning, redaction, compression, chunking, governance, and evaluation in one on-premises pipeline — fully local inference, your data never leaves your domain.