Gatekeeper
RAG systems were never designed with security in mind.
Gatekeeper is the layer that lets them ship.
THE PROBLEM
RAG systems were never designed with security in mind. They surface sensitive context to the LLM, and the LLM has a real chance of leaking it. Existing access control is either too coarse (database-level) or scattered through application code (impossible to audit, version, or maintain). Many RAG systems never made it to production for exactly this reason.
THE APPROACH
A pluggable policy layer that sits on top of any existing RAG system, no rewrite required. A visual builder lets non-security engineers write rules without touching code; rules export as YAML and load directly into the runtime. Four enforcement stages (pre-query, pre-retrieval, post-retrieval, post-generation), each targeting a distinct threat. A novel "distilled prompt" mechanism injects governance rules into the LLM system prompt as a soft enforcement complement to the hard layer.
FOUR ENFORCEMENT STAGES
Block jailbreaks, rate-limit, and inject distilled rules into the LLM system prompt before any retrieval cost is paid.
Inject metadata filters into the vector search. Unauthorized chunks can't enter the LLM context even if they're semantically similar.
Redact PII. Drop or degrade chunks based on sensitivity. The last line before the prompt is assembled.
Enforce citations. Check confidence. Scan for leakage in the model's own output — the only stage that catches parametric-memory leaks.
THE OUTCOME
99.54% reduction in data leakage across three synthetic enterprise datasets (healthcare, financial, government). Sub-50ms p95 enforcement latency. Perfect F1 score (1.0) on access control. 73% reduction in policy authoring time compared to imperative code. Published as a research paper. Released open source.
EVIDENCE
- 01
Four-stage enforcement
Pre-query, pre-retrieval, post-retrieval, and post-generation hooks, each addressing a distinct RAG threat vector identified in the recent security literature.
- 02
Policy-as-code DSL
Declarative YAML or JSON. Schema-aware. Versioned. Readable and writable by compliance officers, not just developers.
- 03
Rules Studio
Visual policy builder with a form-based condition editor, live simulator, version diff view, and audit log explorer. Built in Next.js, TypeScript, and shadcn/ui.
- 04
Distilled-prompt injection
Active rules become natural-language constraints in the LLM system prompt. Soft enforcement alongside the hard layer.
- 05
Structured audit
Every decision generates a JSON event with a cryptographic policy-version hash. End-to-end data lineage reconstructable from a single SQL query.
MY CONTRIBUTION
- 01
Co-author with Sagar Harsora, Kush Kapadia, and Siddhanth Srivastava, under Prof. Neha Katre.
Final-year research project at DJSCE, Department of Information Technology.
- 02
Built the Rules Studio, the policy authoring frontend.
Cascading dropdowns from the registered schema, a live policy simulator, version diff view, audit log explorer. Built in Next.js, TypeScript, and shadcn/ui. The same stack the rest of the framework was hardened against.
Policy stopped being scattered application code.