Search for a command to run...
Makes sense. A RAG system is only as trustworthy as the data and steps feeding into it.
Interesting approach. We've seen many teams focus heavily on retrieval quality and prompt engineering while overlooking retrieval governance and authorization controls. The idea of performing authorization before retrieval is particularly important for enterprise AI systems handling sensitive data. Curious whether you've tested the framework with multi-tenant RAG environments where document access policies vary across tenants.
Yes tested with Pinecone namespaces.
Zero-trust for RAG is such an important topic—making sure embeddings and retrieved context can't leak sensitive data is where things get tricky.
Excatly, that's why we included PII/PHI, Secrets and Injection Scanners to make it clean. Also each embeddings are hashed and signed during ingestion and verified during retrieval to avoid any tampered records.
Retrieval-Augmented Generation (RAG) has quickly become the standard architecture for enterprise AI applications.
Most teams focus on improving retrieval quality, embedding models, chunking strategies, and prompt engineering. Much less attention is given to a fundamental question:
Can you trust the data being retrieved?
Traditional RAG pipelines assume that anything returned from a vector database is safe and trustworthy. In practice, that assumption often breaks down.
Potential risks include:
To address these challenges, we are open-sourcing the AetherGuard RAG Security Kit.
The goal is simple:
Add zero-trust retrieval governance to existing RAG systems without requiring changes to your vector database or embedding model.
The project was designed around a few principles:
The SDK acts as a lightweight client while security processing happens server-side.
This allows organizations to continue using Pinecone, Chroma, Weaviate, Qdrant, pgvector, OpenSearch, or other vector stores without changing their existing retrieval architecture.
The AetherGuard RAG Security Kit provides a set of security controls that can be integrated into existing Retrieval-Augmented Generation (RAG) pipelines.
Prompt Injection Detection
Detects common prompt injection attempts embedded in retrieved content, including patterns such as:
Uses semantic analysis rather than relying solely on keyword matching, enabling detection of paraphrased and indirect attacks.
PII Detection
Identifies sensitive information within retrieved content, including:
Supports both masking and blocking workflows depending on organizational policy requirements.
Secrets Detection
Detects potentially exposed credentials and secrets, including:
Helps prevent accidental disclosure of sensitive information through retrieved context.
Toxicity & Safety Checks
Screens retrieved content for potentially unsafe material, including:
Allows organizations to apply safety controls before content reaches downstream LLMs or end users.
During ingestion, document chunks and embeddings are submitted for security processing.
Metadata generated during ingestion can then be stored alongside vectors inside the vector database.
This creates a verifiable chain of trust between the original content and future retrieval operations.
Instead of sending raw retrieval results directly to an LLM, applications can introduce a verification stage.
Retrieved chunks are evaluated before they become part of the model context.
This allows organizations to:
The objective is to ensure that only trusted context reaches the model.
One area that receives surprisingly little attention in RAG discussions is retrieval integrity.
Most security conversations focus on prompt injection.
However, if retrieved context has been altered, corrupted, incorrectly classified, or otherwise manipulated, downstream model behavior becomes unreliable regardless of prompt protections.
The RAG Security Kit introduces integrity verification mechanisms that allow applications to validate retrieved content before it is used for generation.
Another common pattern is querying a vector database first and checking permissions later.
A zero-trust approach reverses this process.
Applications can perform authorization checks before retrieval, ensuring users only access data they are permitted to retrieve.
This helps reduce accidental exposure of sensitive content and supports data governance requirements.
Enterprise teams frequently ask:
The project generates evidence records that can be used for auditing and investigation workflows.
We believe secure AI infrastructure should be easier to adopt.
Many teams already have functioning RAG systems but lack practical mechanisms for retrieval governance, integrity verification, and authorization controls.
By open-sourcing the SDK, developers can integrate these controls into existing pipelines without rebuilding their architecture.
The project is still evolving, and we'd appreciate feedback from engineers building production RAG systems.
In particular, we're interested in discussions around:
GitHub repository: https://github.com/AetherGuardAI/aetherguard-rag-security-kit
GitHub: https://github.com/AetherGuardAI
Website: https://aetherguard.ai
Feedback, issues, feature requests, and contributions are welcome.
