Segregation of duties is critical because when a vector database is accessed with a single shared API key, any team member can read, write, or delete embeddings without oversight, and a single mistake can corrupt an entire knowledge base, leading to costly model retraining and lost trust.
In many organizations the key lives in a configuration file or environment variable that is copied across development, staging, and production environments. Data scientists, engineers, and automated pipelines all use the same credential, so there is no way to prove who added a particular vector, who altered a collection, or which automated job performed a bulk import. Without an audit trail, privilege creep goes unnoticed until a downstream service returns irrelevant results, forcing expensive re‑indexing and potentially exposing sensitive customer data.
Why segregation of duties matters for vector databases
Segregation of duties (SoD) is a control that separates the people who create or modify data from those who approve or audit those changes. In the context of vector stores, SoD prevents a single actor from both inserting malicious embeddings and later querying them to manipulate model outputs. The goal is to make every high‑impact operation visible, auditable, and, when appropriate, subject to a human review before it reaches the database.
Implementing SoD requires three distinct layers:
- Setup: Identity providers (OIDC or SAML) issue tokens that identify a user or service account. Roles and groups are defined in the IdP, but these tokens alone cannot enforce fine‑grained policies on the database connection.
- The data path: A gateway placed between the client and the vector database is the only place where requests can be inspected, approved, or altered.
- Enforcement outcomes: Session recording, just‑in‑time approval, inline masking, and audit logs are produced only when the gateway mediates the traffic.
hoop.dev fulfills the data‑path role. It sits on the network edge, receives an authenticated token, and then proxies the request to the target vector store. Because the gateway is the sole conduit, it can enforce SoD policies without relying on the database’s native permissions.
How hoop.dev enables segregation of duties
When a request arrives, hoop.dev first validates the OIDC token against the configured IdP. The token tells hoop.dev who is making the call, but the gateway decides what that identity may do. Policies are expressed as combinations of roles, actions, and resource patterns. For a vector database, a typical policy set might include:
- Data scientists may search and retrieve vectors but cannot upsert or delete without an explicit approval step.
- Ops engineers can upsert and delete but only after a peer‑reviewed change ticket is attached to the request.
- Automated pipelines receive read‑only tokens that expire after a short window, and any write operation triggers a temporary hold until a human reviewer releases it.
Because hoop.dev sits in the data path, it can:
- Record each session: hoop.dev logs every query, the identity that issued it, and the full response payload. hoop.dev stores each session log so it can be replayed for forensic analysis.
- Mask sensitive fields: If a vector store returns personally identifiable information alongside embeddings, hoop.dev can strip or redact those fields before they reach the client.
- Require just‑in‑time approval: For write operations that cross a duty boundary, hoop.dev pauses the request and routes it to an approver defined in the policy. The approver can grant or deny the action from a web console.
- Enforce least‑privilege connections: The gateway holds the database credentials; users never see them, eliminating credential sprawl.
All of these outcomes are possible only because hoop.dev is the gateway that inspects the wire‑level protocol. A setup that only defines roles in an IdP would leave the database exposed to unchecked commands.