When in-transit data governance works perfectly, every query to a vector database is inspected, sensitive vectors are masked before they leave the system, and a log records who asked for what and when. Engineers can grant a data‑science notebook just‑in‑time read access, and the request is automatically approved or routed for manual review if it touches high‑risk collections. If something goes wrong, the session can be replayed to understand the exact payload that traversed the network.
That ideal state is rarely the reality today. Most teams connect directly to their vector store with a static credential stored in a secret manager or embedded in application code. The connection bypasses any gate that could enforce policies, so every request runs unchecked. Sensitive embeddings, personal identifiers, health records, or proprietary product features, flow unaltered to downstream services, and no central audit captures the exact query or response. When a breach is discovered, the lack of a reliable trail makes forensic analysis costly and incomplete.
Current practice and its gaps
In many organizations, a service account is created for the vector database and granted broad read/write permissions. The account key lives in a vault, but developers and automated jobs retrieve it and use it directly with the client library. This setup satisfies authentication, but it does not provide any of the controls required for effective in‑transit data governance. The data path is a straight pipe from the client to the database engine; there is no place to inspect the payload, apply masking rules, or enforce just‑in‑time approvals.
Even when teams adopt OIDC or SAML for authentication, the identity check stops at the token validation stage. The token proves who the caller is, but the request still travels straight to the database without a gateway that can enforce policy. As a result, the organization still lacks:
- Command‑level audit that records the exact vector query and its parameters.
- Inline masking that redacts personally identifiable information from query results.
- Just‑in‑time approval workflows that pause high‑risk queries until a human reviews them.
- Session replay that lets security analysts see the full interaction after the fact.
These missing controls are the core of the in‑transit data governance problem for vector databases.
Why the data path must host the controls
The only place to reliably enforce masking, approval, and audit is the network layer that all traffic must cross. Identity and credential provisioning (the setup) decide who may start a connection, but they cannot modify the payload once the connection is established. If the enforcement logic resides inside the client or the database, a compromised component could bypass it entirely. Placing the guardrails in a dedicated gateway ensures that every byte of traffic is subject to the same policy, regardless of the caller.
That gateway must be protocol aware, understand the vector database wire format, and be able to inject or block commands in real time. It also needs to be able to record the session in a log so that auditors can later verify compliance with in‑transit data governance requirements.
hoop.dev as the enforcement layer
hoop.dev provides exactly the data‑path gateway required for vector databases. It sits between identities, whether human engineers, CI pipelines, or AI agents, and the database engine. Because hoop.dev proxies the connection at Layer 7, it can inspect each request, apply inline masking rules, and enforce just‑in‑time approvals before the query reaches the store. The gateway records the full session, making replay and forensic analysis straightforward.
When a request arrives, hoop.dev validates the caller’s OIDC token, extracts group membership, and then checks the request against configured policies. If the query touches a protected collection, hoop.dev either masks the response fields that contain sensitive embeddings or routes the request to an approval workflow. Only after an authorized approver signs off does the request proceed. Every step, authentication, policy check, masking decision, and approval outcome, is logged in an audit trail that captures each action.
Because the gateway holds the database credentials, the client never sees them. This eliminates credential sprawl and reduces the attack surface. The agent that runs inside the network only forwards traffic; it cannot alter the policy engine because the policy enforcement lives in hoop.dev, not in the agent.
Key enforcement outcomes
- Query‑level audit: hoop.dev records the exact vector query, the parameters supplied, and the identity that issued it.
- Inline data masking: Sensitive fields in query results are redacted in real time, ensuring that downstream services never receive raw PII.
- Just‑in‑time approval: High‑risk queries trigger an approval request that must be satisfied before execution.
- Session recording and replay: The full request/response stream is stored for later analysis, supporting incident response and compliance reporting.
- Credential isolation: The gateway owns the database secret, so callers cannot extract or reuse it elsewhere.
All of these outcomes exist only because hoop.dev sits in the data path. If the setup (OIDC, service accounts, vaults) were left unchanged but hoop.dev were removed, none of the above controls would be enforced.
Getting started
Deploying hoop.dev is straightforward. The project supplies a Docker Compose file that launches the gateway and a network‑resident agent near the vector store. After registering the database as a connection and defining masking rules, you can point any client, psql‑like tools, SDKs, or notebooks, to the hoop.dev endpoint. The official getting‑started guide walks through the steps, and the learn section provides deeper coverage of masking policies and approval workflows.
FAQ
Does hoop.dev modify the vector database itself?
No. hoop.dev only proxies traffic; the underlying database remains unchanged.
Can I use existing OIDC providers?
Yes. hoop.dev works with any OIDC or SAML identity provider, including Okta, Azure AD, and Google Workspace.
How is the audit log stored?
The gateway writes logs to a configured backend that can be a logging service or similar store. The logs provide a complete record of each session.
Next steps
If you want to explore the implementation or contribute, the source code is available on GitHub. Explore the repository to see how the protocol‑aware gateway is built and to start customizing policies for your own vector database workloads.
