A well‑designed access reviews process for embedding stores means every request is tracked, approved, and the data it returns can be masked to hide sensitive attributes.
In many organizations, embeddings live in vector databases or managed services that are accessed via a single API key or a shared service account. Engineers, data scientists, and even automated pipelines reach directly into the store without a per‑user gate. The result is a blind spot: anyone who possesses the credential can query the model, retrieve vectors that encode personally identifiable information, proprietary product details, or other regulated data. There is no record of who asked for what, no way to verify that the request aligns with policy, and no mechanism to prevent a high‑risk query from slipping through.
Access reviews are the practice of examining and approving each request to read or write sensitive resources. For embeddings, the stakes are high because a single vector can be reverse‑engineered to expose underlying text, images, or user behavior. An effective review process therefore needs three ingredients: identity‑driven decisions, a point where the request can be inspected, and a record that can be presented to auditors.
Why access reviews alone are not enough
Most teams already adopt a “least‑privilege” model: they issue short‑lived tokens, federate identities through OIDC or SAML, and assign roles that limit which endpoints a service can call. This setup decides *who* may start a connection, but it does not inspect the payload of the request. The query still travels straight to the vector database, bypassing any opportunity for a reviewer to intervene, for sensitive fields to be redacted, or for the activity to be recorded in an immutable audit log.
In other words, the prerequisite of having an identity and a scoped token fixes the authentication problem, yet leaves the core governance gap: there is no enforcement point where access‑review policies can be applied.
hoop.dev as the data‑path enforcement layer
hoop.dev is a Layer 7 gateway that sits between the identity system and the embedding store. By proxying every client connection, it becomes the only place where policy can be enforced. When a request arrives, hoop.dev reads the caller’s OIDC token, checks the configured access‑review policy, and then decides one of three actions:
- Allow and mask. If the query is permitted but contains fields marked as sensitive, hoop.dev masks those values in the response before they reach the client.
- Require approval. For high‑risk queries, such as bulk retrieval of vectors or searches that match regulated data, hoop.dev routes the request to a human approver. The request is held until an authorized reviewer grants permission.
- Block. If the policy explicitly denies the operation, hoop.dev stops the command before it reaches the database.
In every case, hoop.dev records each session in an audit log that includes the caller identity, the policy decision, any masking applied, and the final response. Those records can be replayed for audit, compliance reporting, or forensic investigation.