Policy as code for vector databases forces you to ask: how do you prevent every data‑science notebook from using the same API key to query a vector store?
In many organisations the answer is a shared secret stored in a configuration file, checked into version control, or copied across dozens of environments. Engineers connect directly to the vector database using their favourite client, bypassing any central control plane. The secret never expires, and anyone who can read the file can issue arbitrary similarity searches, delete collections, or even re‑index the entire corpus. There is no record of who ran which query, no way to prevent a costly full‑table scan, and no protection against accidental exposure of personally identifiable information that may be embedded in the vectors.
This reality makes it hard to treat access policies as code. Teams can write JSON or YAML rules that say, for example, “only analysts may query the customer‑insights collection” or “mask fields that contain email addresses”. Yet the request still travels straight to the database, unchecked. The policy engine never sees the traffic, so the rules are never enforced. The result is a false sense of security: the policy exists on paper, but the system still allows unrestricted queries, un‑audited data exfiltration, and unapproved schema changes.
To close that gap the enforcement point must sit on the data path, between the identity that initiated the request and the vector database that fulfills it. That is exactly where hoop.dev operates. hoop.dev is an identity‑aware proxy that intercepts every wire‑level request, evaluates policy as code, and only then forwards the call to the target store.
Applying policy as code to vector databases
When you write policy as code for a vector database you typically define three things:
- Who is allowed to run which type of query (for example, search, upsert, delete).
- What data elements must be redacted or masked in the response (for example, email addresses embedded in metadata).
- When a request exceeds a risk threshold and needs human approval before execution.
Each rule is declarative, version‑controlled, and can be tested in a CI pipeline. The challenge is ensuring that the vector store never sees a request that violates those rules.
Setup: identity and least‑privilege grants
The first layer of protection is the identity that initiates the connection. Using OIDC or SAML, each user receives a short‑lived token that conveys group membership and attributes. Those attributes are the basis for the policy engine to decide if a request is permissible. The token itself does not grant direct access to the database; it merely proves who the caller is. This setup is necessary but not sufficient because the token can be presented to any endpoint that accepts it.
The data path: hoop.dev as the enforcement gateway
hoop.dev sits in the network near the vector database and acts as the sole ingress point. Because every request must pass through hoop.dev, it becomes the only place where policy can be applied. The gateway parses the vector‑store protocol, extracts the query, and runs it against the policy‑as‑code definitions. If the query matches an allowed pattern, hoop.dev forwards it. If the query attempts a disallowed operation, hoop.dev blocks it before any bytes reach the backend.
Enforcement outcomes that only hoop.dev can provide
- hoop.dev records each session, capturing the full request and response for later replay.
- hoop.dev masks sensitive fields in real time, so downstream tools never see raw PII.
- hoop.dev routes high‑risk queries to an approval workflow, requiring a manager or data‑owner to approve before execution.
- hoop.dev blocks dangerous commands such as bulk deletions or unrestricted similarity searches.
All of these outcomes exist because hoop.dev occupies the data path; without it the same policies would remain unenforced.
What to watch for when implementing policy as code
Even with a gateway in place, there are practical pitfalls:
- Policy drift. Policies stored in a repository can become out of sync with the live gateway if deployments are missed. Automate the rollout of policy files alongside your CI pipeline.
- Latency impact. Real‑time inspection adds a small amount of round‑trip time. Measure the overhead in a staging environment before scaling to production.
- Granular masking. Vector databases often return metadata alongside vectors. Ensure your masking rules target the exact fields that contain sensitive data, otherwise the gateway may inadvertently leak information.
Addressing these concerns starts with a solid getting‑started guide that walks you through deploying the gateway, wiring OIDC, and loading policy files. For deeper insight into policy syntax and best practices, see the learn section of the documentation.
Getting started with hoop.dev
Deploy the gateway using the provided Docker Compose file or the Kubernetes Helm chart. Register your vector database as a connection, upload the service credential, and point your client at the hoop.dev endpoint instead of the raw host. From that point forward, every query is subject to the policy you have codified.
When you are ready to explore the codebase, contribute, or run your own self‑hosted instance, visit the open‑source repository:
Explore hoop.dev on GitHub
FAQ
Q: Does hoop.dev store my vector data?
A: No. hoop.dev only proxies traffic; the actual vectors remain in the backend store.
Q: Can I use existing OIDC providers?
A: Yes. hoop.dev works with any OIDC or SAML identity provider that can issue signed tokens.
Q: How does session replay work for high‑dimensional vectors?
A: The gateway captures the raw request and response payloads, which can be re‑played in a sandbox for forensic analysis.
