Uncontrolled access to a vector database can expose proprietary embeddings and give attackers a shortcut to reverse‑engineer business logic.
SOC 2 requirements for data stores
SOC 2 is built around five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. For any data store, the standard expects three concrete evidence streams.
- Access control logs that show who connected, when, and from where.
- Change and query audit trails that capture every read or write operation with enough context to reconstruct intent.
- Data protection safeguards such as masking or encryption that demonstrate confidentiality and privacy commitments.
Auditors also look for evidence that the organization enforces least‑privilege principles, reviews access requests, and can demonstrate that privileged actions are approved in real time.
How teams typically operate today
Most engineering groups connect directly to a vector database using a shared service account or a static API key. The credential lives in configuration files, CI pipelines, or even developer laptops. Because the connection bypasses any central gate, the following gaps appear:
- No single source of truth for who executed a query.
- No inline protection for sensitive vectors; the raw response is streamed back to the client.
- Standing access is granted indefinitely, making it hard to justify the principle of least privilege.
These gaps mean that, even if an organization has an identity provider and can issue tokens, the actual data path offers no enforcement point. The result is a blind spot in the evidence required for SOC 2.
What the missing piece looks like
The first step toward compliance is to bind every request to an identity and to limit that identity to the exact scope needed for the operation. Identity providers such as Okta or Azure AD can issue OIDC tokens, and the organization can configure role‑based policies that say, for example, "data‑science‑team may query but not write." However, without a gateway that sits on the data path, the request still reaches the vector database directly, and no audit record, masking, or just‑in‑time approval is captured.
In other words, identity and least‑privilege fixes the "who" but not the "what happened" or "was it approved". SOC 2 auditors will still see a gap because the system cannot prove that each query was authorized, recorded, and that sensitive embeddings were protected.
hoop.dev as the enforcement layer
hoop.dev is a Layer 7 gateway that sits between the identity provider and the vector database. By routing every connection through hoop.dev, the organization gains a single, immutable control surface where the following enforcement outcomes are applied:
- Session recording – each query and response is logged with the user’s identity, timestamp, and source IP. This creates the audit trail required by SOC 2 security and processing‑integrity criteria.
- Inline masking – sensitive fields in query results can be redacted in real time, satisfying confidentiality and privacy expectations.
- Just‑in‑time approval – high‑risk operations such as bulk inserts or schema changes trigger a workflow that requires a designated approver before the command is forwarded.
- Command‑level blocking – dangerous commands (for example, DELETE without a WHERE clause) are intercepted and rejected, reducing the risk of accidental data loss.
Because hoop.dev holds the database credential, the client never sees it. The gateway validates the OIDC token, checks the user’s group membership, and then enforces the policies above before allowing traffic to flow. All of this happens at the protocol layer, meaning existing client tools (psql‑like CLI, SDKs, or AI agents) work unchanged.
Generating SOC 2 evidence with hoop.dev
When a data‑science engineer runs a similarity search, hoop.dev logs the exact query, the identity token, and the masked response. If the engineer later requests a bulk update, the approval workflow creates a separate record that shows who approved, when, and why. Auditors can extract these logs from hoop.dev’s audit store and map them directly to the SOC 2 trust criteria.
The gateway also supports export of logs in standard formats (JSON, CSV) that can be fed into SIEM or compliance dashboards. This makes it easy to demonstrate continuous monitoring, a core expectation of SOC 2.
Getting started
Deploy the gateway using the official Docker Compose quick‑start, configure your vector database as a connection, and point your clients at the hoop.dev endpoint. The documentation walks through OIDC integration, connection registration, and policy definition. For a step‑by‑step walkthrough, see the getting‑started guide and the broader feature overview at hoop.dev/learn.
FAQ
Does hoop.dev make my vector database SOC 2 compliant?
hoop.dev provides the audit, masking, and approval evidence that SOC 2 auditors look for, but compliance also depends on organizational policies, risk assessments, and other controls outside the gateway.
What specific evidence does hoop.dev produce?
It generates per‑user session logs, approval workflow records, masked query results, and command‑blocking events. All of these are timestamped and can be exported for audit reviews.
Can I use hoop.dev with existing vector database deployments?
Yes. The gateway runs as a sidecar or standalone service in the same network as the database. You register the existing endpoint, and your applications continue to use the same client libraries; only the network address changes to point at hoop.dev.
By placing enforcement at the data path, hoop.dev turns a loosely governed vector database into a source of verifiable evidence for SOC 2.
Explore the open‑source repository on GitHub to see the code and contribute: github.com/hoophq/hoop.
