A fully auditable embedding pipeline that logs every request, masks sensitive vectors, and requires approval before risky operations is the hallmark of SOC 2 compliance.
What SOC 2 expects from embedding services
SOC 2 focuses on the Trust Services Criteria of security, availability, processing integrity, confidentiality, and privacy. For a machine‑learning embedding service this translates into three practical obligations:
- Secure processing integrity. Every inference call must be traceable to an authenticated identity, and any deviation from expected behavior must be detectable.
- Confidentiality of data. Input vectors may contain personally identifiable information (PII) or proprietary business data that must never be exposed in logs or downstream systems.
- Continuous auditability. Auditors need immutable evidence that access was granted, that the request was approved when necessary, and that the response was properly masked.
Traditional deployments fall short because they rely on static API keys, store credentials in application code, and forward raw vectors directly to the model without any guardrails. The result is a black‑box where the only record is the downstream model’s own logs, often insufficient for a SOC 2 audit.
Why continuous evidence matters
SOC 2 audits are not a one‑time checklist; they require evidence that controls have been operating effectively over the audit period. If evidence is generated only when an auditor asks for it, the organization cannot prove that the controls were consistently applied.
Continuous evidence solves two problems:
- Gap elimination. There is no window of unrecorded activity because every session is captured as it happens.
- Risk reduction. Real‑time masking and command‑level approvals prevent accidental leakage before it ever reaches storage.
Without a unified point where these controls can be enforced, teams end up stitching together separate logging, IAM, and masking solutions that do not speak to each other, creating blind spots that auditors flag.
How hoop.dev creates that evidence
hoop.dev is a Layer 7 gateway that sits between identities and the embedding service. The gateway is the only place where enforcement can happen, and it provides three core evidence‑generating capabilities.
Session recording at the protocol level
When a client sends an inference request, hoop.dev intercepts the wire‑protocol payload, records the full request and response, and stores the record in a secure audit log. Because the gateway owns the connection, the recorded session includes the authenticated identity, the exact vector content, and the model’s output. Auditors can replay any session to verify that masking was applied and that the request originated from an authorized identity.
Just‑in‑time approvals for risky operations
Some embedding calls may trigger downstream actions, such as writing to a vector database or invoking a fine‑tuned model that could generate copyrighted text. hoop.dev can route these calls to a human approver before they reach the model. The approval decision, the approving identity, and the timestamp are all logged by the gateway, providing concrete evidence that risky work was reviewed.
Inline data masking
Embedding inputs often contain raw PII. hoop.dev can apply field‑level masking rules to the response before it leaves the gateway. The masking policy is defined once in the gateway and enforced on every response, guaranteeing that no sensitive data is ever written to downstream logs or storage. The masking action itself is recorded, so auditors see both the original value and the masked result.
Identity‑driven access control
Setup steps, OIDC or SAML integration, group‑based role assignment, and least‑privilege service accounts, determine who may start a session. However, those steps alone do not enforce policy. Because hoop.dev sits in the data path, it can enforce per‑request rules that go beyond static IAM permissions, such as limiting the number of vectors per minute or requiring multi‑factor approval for bulk queries.
In practice, the workflow looks like this:
- Developer authenticates via an OIDC provider; hoop.dev validates the token and extracts group membership.
- The developer issues an embedding request through the standard client library. The request is automatically routed through the hoop.dev gateway.
- The gateway checks the request against masking and approval policies. If the request is benign, it is forwarded to the model; if it is flagged, an approver is notified.
- Regardless of the path, the gateway records the full session, the approval decision (if any), and the masking actions.
- Auditors retrieve the audit logs to demonstrate continuous compliance with SOC 2 criteria.
This architecture satisfies the SOC 2 requirement for continuous, verifiable evidence while keeping the embedding service itself unchanged. The gateway requires no code changes in the model or the client; it merely becomes the network‑resident proxy.
Getting started with hoop.dev
To adopt this approach, begin with the official getting‑started guide. The quick‑start uses Docker Compose to launch the gateway and an example embedding service, then walks you through OIDC configuration, policy definition, and how to view recorded sessions in the audit UI. For deeper policy customization, the learn section provides detailed guidance on masking rules, approval workflows, and session replay.
FAQ
Does hoop.dev replace my existing IAM system? No. hoop.dev relies on your identity provider to authenticate users. It adds a layer of enforcement and evidence generation that IAM alone cannot provide.
Can I use hoop.dev with any embedding model? Yes. hoop.dev operates at the protocol level, so any model that exposes a standard API (gRPC, HTTP, or database‑style) can be proxied without code changes.
How long are session records retained? Retention is a policy decision you configure in the gateway’s storage backend. For SOC 2 you typically retain records for the audit period plus any required archive window.
Is hoop.dev open source? Absolutely. The project is MIT licensed and the source is available on GitHub. Contribute, audit, or fork the code to meet your internal compliance requirements.
