A single over‑privileged credential can give anyone read and write access to every vector embedding stored in your database. Without rbac, this flat trust model persists. In many organizations the default practice is to create a shared service account, hard‑code its secret in CI pipelines, and hand the same user name to every data scientist, backend engineer, and operations staff. The result is a flat trust model: anyone who can invoke the client library can issue arbitrary upserts, deletes, or similarity searches without any visibility into who performed the action. Auditing is limited to server logs that do not correlate a request with an individual identity, and there is no way to prevent a junior engineer from accidentally exposing proprietary embeddings.
When teams recognize the need for role‑based access control (RBAC), they often start by defining roles in an external directory and granting those roles to the shared account. The directory now knows which groups exist, but the request still travels directly to the vector store. No enforcement point checks the caller’s role, no session is recorded, and no sensitive fields are masked. The database itself sees only the service account, so it cannot enforce per‑user policies.
Why RBAC matters for vector databases
Vector databases power recommendation engines, semantic search, and AI‑augmented features. The vectors they store encode business‑critical knowledge and, in many cases, personally identifiable information. Without RBAC, a compromised developer workstation can exfiltrate an entire embedding set, or a mis‑configured job can overwrite training data, corrupting downstream models. Enforcing RBAC at the point where a request enters the data path limits the blast radius, provides clear evidence for auditors, and enables just‑in‑time approvals for high‑risk operations such as bulk deletions.
How to implement RBAC with hoop.dev
hoop.dev acts as a Layer 7 gateway that sits between identities and the vector database. The gateway receives an OIDC or SAML token, extracts the user’s group membership, and then decides whether the requested operation matches the role policy. Because the enforcement happens inside the gateway – the only place traffic is inspected – hoop.dev can:
- Reject queries that a user’s role does not permit, such as disallowing delete‑by‑id for a read‑only analyst.
- Require a senior reviewer to approve bulk upserts before they reach the database.
- Mask fields that contain raw text or personally identifiable data in query responses, ensuring that downstream logs never expose raw content.
- Record every session, including the exact query, the authenticated identity, and the decision outcome, so that a replay can be performed during an investigation.
The setup phase still relies on a standard identity provider. You configure OIDC client credentials, define groups that map to RBAC roles, and register the vector database as a connection in hoop.dev. The gateway holds the database credential, so users never see it. All of the enforcement logic lives in the data path, satisfying the requirement that RBAC cannot be reliably enforced by the database alone.
Designing role policies for embeddings
Start with a minimal set of roles: