Many teams assume that zero trust for embeddings is satisfied by simply placing a firewall in front of the model endpoint. The reality is that zero trust is a set of continuous, identity‑driven checks that must extend to every request and response.
In practice, most organizations expose their embedding services with long‑lived API keys or static bearer tokens. Those credentials are shared across dozens of services, rarely rotated, and the endpoint itself logs nothing about who asked for which vector. No one can tell whether a request was made by a legitimate service or a compromised script, and there is no way to block a malicious prompt that could exfiltrate sensitive data.
Applying zero trust to embeddings means moving from static secrets to identity‑based access, enforcing least‑privilege scopes, and gaining full observability of each interaction. Even when an organization adopts an OIDC provider and issues short‑lived tokens, the request still travels directly to the model server. The connection bypasses any enforcement layer, leaving the system without real‑time masking, approval workflows, or comprehensive audit records.
hoop.dev provides the missing data‑path layer. It sits between the identity provider and the embedding service, verifying each OIDC token, applying policy rules, and then proxying the traffic to the model. Because hoop.dev is the only point where the request is inspected, it can mask returned personally‑identifiable information, require a human approval for high‑cost or high‑risk prompts, and record the entire session for replay.
The architecture is straightforward. A network‑resident agent is deployed close to the embedding service. The gateway is configured with the service’s credentials, which never leave the agent. When a client presents an OIDC token, hoop.dev checks the token’s audience, groups, and expiration, then consults a policy that may limit the model, the number of tokens per minute, or the allowed prompt patterns. If the request passes, hoop.dev forwards it; if not, it blocks or routes it for manual approval. Every interaction is logged and can be queried later for compliance or incident response.
Because hoop.dev owns the enforcement point, several outcomes become possible that would not exist otherwise. It generates a comprehensive audit record that attributes each vector to a specific identity, it masks sensitive fields such as social security numbers or credit‑card fragments before they leave the model, it enforces just‑in‑time approvals for prompts that exceed a cost threshold, and it records the full session so that a security analyst can replay exactly what was asked and returned.
When designing a zero‑trust embedding pipeline, watch for the following pitfalls. First, avoid relying on a single static credential; instead, integrate an OIDC provider and define fine‑grained scopes per model or per project. Second, ensure that masking rules are comprehensive – missing a field can let PII slip through. Third, set clear approval thresholds; without them, high‑value prompts will run unchecked. Finally, monitor the audit logs regularly; collecting logs without review defeats the purpose of continuous verification.
To adopt this approach, start by deploying hoop.dev using the getting started guide. Register your embedding endpoint as a connection, configure the OIDC client, and define policies that reflect your risk appetite. The documentation on policy features and masking walks through common patterns for protecting PII and enforcing cost limits. Once the gateway is in place, every embedding request will be subject to zero‑trust controls without changing your existing client code.
FAQ
Do I need to change my application code to use hoop.dev?
No. hoop.dev acts as a transparent proxy, so existing clients (e.g., curl, Python SDKs) continue to point at the same host and port, but the traffic now passes through the gateway where policies are enforced.
Can hoop.dev mask data that the model returns?
Yes. By defining masking rules in hoop.dev’s policy, any response that matches a pattern (such as credit‑card numbers) is redacted before it reaches the caller.
How does hoop.dev help with compliance audits?
Because every session is recorded and attributed to a verified identity, hoop.dev supplies the audit evidence needed for standards that require traceability of data access and transformation.
Explore the open‑source code and contribute on GitHub.
