A common misconception is that compliance evidence for Retrieval Augmented Generation (RAG) systems can be gathered after the fact, like a retroactive audit. In reality, evidence must be collected continuously as the model queries and retrieves data, ensuring every interaction is traceable.
Why continuous compliance evidence matters for RAG
RAG pipelines stitch together large language models, vector stores, and external data sources. Each query may pull a document, enrich it, and write a response back to a downstream service. Regulators and internal auditors expect to see who accessed which document, what transformation was applied, and whether any sensitive fields were exposed. Because the data flow crosses multiple components, a point‑in‑time snapshot cannot prove that the system behaved correctly throughout its lifecycle. Continuous compliance evidence gives a chronological record that aligns with audit requirements and supports incident investigations without guessing.
The missing control: continuous capture at the access layer
Most organizations rely on identity providers, OIDC tokens, and role‑based policies to decide who may start a request. This setup step authenticates the caller and assigns a set of permissions, but it does not observe what the caller actually does once the connection is opened. Without a gateway that inspects traffic, a privileged token can be used to run arbitrary commands, extract confidential fields, or exfiltrate data, and none of those actions appear in the audit trail.
Because the enforcement point is absent, the following gaps remain:
- There is no session‑level log that ties a specific query to a user identity.
- Sensitive values returned by a vector store are not masked before they reach downstream services.
- Any deviation from approved query patterns goes unchecked.
- Replay of a session for forensic analysis is impossible.
Addressing these gaps requires a dedicated data‑path component that sits between the identity layer and the target resource.
Introducing hoop.dev as the data‑path gateway
hoop.dev is a Layer 7 gateway that proxies connections to databases, Kubernetes clusters, SSH endpoints, and HTTP services. It receives the caller’s OIDC or SAML token, validates it, and then forwards the request to the target only after applying policy checks. Because the gateway sits in the data path, it is the only place where enforcement can happen.
When a RAG component initiates a connection, hoop.dev records the entire session, masks any fields marked as sensitive, and can pause execution for a human approval if the request exceeds a risk threshold. All of these actions are performed by hoop.dev, not by the calling service or by the underlying resource.
How hoop.dev generates compliance evidence for RAG
hoop.dev creates the evidence required by auditors in three distinct ways:
- Session recording. Every query, response, and command passes through the gateway, and hoop.dev writes a timestamped log that includes the authenticated identity. The log can be replayed to reconstruct exactly what happened during a given request.
- Inline masking. Before data leaves the target, hoop.dev can replace credit‑card numbers, social security numbers, or any custom pattern with a placeholder. The original value never reaches the downstream RAG component, reducing the risk of accidental leakage while still preserving the fact that a masked field was accessed.
- Just‑in‑time approvals. If a query touches a high‑value dataset, hoop.dev can route the request to an approver. The approval decision, along with the approver’s identity and timestamp, becomes part of the audit record.
Because hoop.dev controls the traffic, the compliance evidence it produces is continuous and directly tied to the identity that initiated the request. Teams can query the audit store to answer questions such as “Which user accessed customer PII on March 12?” or “Did any RAG inference run without an approval?” without having to instrument each downstream service individually.
Getting started with hoop.dev for RAG pipelines
To adopt this model, begin by deploying the gateway in the same network segment as your vector store and database. The quick‑start guide walks you through a Docker Compose deployment that includes OIDC authentication, default masking rules, and session logging. Once the gateway is running, register your RAG resources as connections in the console, and update your application to point to the gateway endpoint instead of the raw database host.
For detailed steps, see the getting‑started documentation. The broader feature set, including custom masking policies and approval workflows, is explained in the learn section. When you are ready to explore the code or contribute, explore the source on GitHub.
FAQ
Do I need to change my existing RAG code to use hoop.dev?
No. hoop.dev works with standard client libraries (psql, curl, ssh, kubectl, etc.). You only change the endpoint address to point at the gateway; the rest of the code remains unchanged.
How long are session logs retained?
Retention is a policy decision made by your organization. hoop.dev writes logs to a configurable backend, and you can set any retention window that satisfies your audit requirements.
Can I mask fields that are not known ahead of time?
hoop.dev supports pattern‑based masking, so you can define regular expressions that match credit‑card formats, email addresses, or any custom pattern. New patterns can be added without redeploying the RAG application.
