When every embedding request is driven by a verifiable non-human identity, you can audit exactly which service accessed which model, automatically mask sensitive payloads, and revoke access without touching application code.
In most organizations today, embedding services are called from backend jobs, batch pipelines, or AI agents using a shared service account or a static API key. That credential is baked into configuration files, duplicated across environments, and rarely rotated. Because the request carries no per‑request identity, there is no way to attribute a specific inference to a particular job, nor to enforce data‑level policies on the response. Auditors see a flat stream of calls, and security teams have no guardrails to stop a rogue payload from leaking personal data.
The core problem is the lack of a non-human identity that is both machine‑readable and policy‑enforceable. Introducing a scoped service principal solves credential sprawl and enables role‑based access, but the request still travels straight to the embedding endpoint. Without a control point in the data path, the request bypasses any approval workflow, any inline masking, and any session recording. The setup alone does not guarantee that a privileged model cannot be queried for prohibited data.
Why a dedicated gateway is required for non-human identity
hoop.dev provides the missing control surface. It sits as a Layer 7 gateway between any client, whether a CI job, an autonomous AI agent, or a microservice, and the embedding service. The gateway validates OIDC or SAML tokens issued to the service principal, extracts group membership, and makes an allow‑or‑deny decision before the request reaches the model. Because the enforcement happens in the data path, hoop.dev can apply just‑in‑time approvals, block disallowed prompts, and mask sensitive fields in the model’s response.
Every session that passes through hoop.dev is recorded. The recording includes the identity that initiated the call, the exact prompt sent, and the masked response returned. hoop.dev provides security teams with immutable evidence of who queried what and when. If a policy change requires retroactive enforcement, the recorded sessions can be replayed for investigation.
Inline masking is another enforcement outcome that only works because hoop.dev inspects the payload at the protocol level. Sensitive attributes, such as Social Security Numbers, credit‑card numbers, or personally identifiable information, can be identified in the model’s output and replaced with placeholders before the response reaches the caller. The masking logic is defined centrally, so all services benefit from a consistent data‑privacy posture.
Just‑in‑time access is enforced by hoop.dev’s approval workflow. When a job attempts a high‑risk embedding operation, such as querying a model with a prompt that contains regulated language, the request is held at the gateway and routed to an authorized reviewer. Once approved, the request proceeds; otherwise it is denied and logged.
How to adopt non-human identity for embeddings with hoop.dev
Start by defining a service principal in your identity provider (Okta, Azure AD, Google Workspace, etc.) and granting it the minimal set of scopes required to call the embedding endpoint. Configure hoop.dev to trust tokens from that provider; the gateway will then verify each request’s token before forwarding it.
Next, register the embedding service as a connection in hoop.dev. The gateway stores the model’s API key, so client code never sees the secret. When a job runs, it authenticates with its service principal, obtains a short‑lived token, and connects through hoop.dev using the standard client library or HTTP request. hoop.dev inspects the request, applies any configured masking rules, checks for required approvals, and streams the response back to the caller.
All of the operational details, Docker Compose quickstart, Kubernetes deployment, and connection registration, are covered in the getting started guide. For deeper policy configuration, see the feature documentation. Because hoop.dev is open source, you can self‑host the gateway in the same VPC as your embedding service, ensuring that no traffic ever leaves your trusted network without passing through the enforcement layer.
FAQ
- What distinguishes a non-human identity from a regular service account? A non-human identity is an OIDC‑issued principal that can be scoped, rotated, and revoked programmatically. Unlike static API keys, it carries claims that hoop.dev can evaluate for policy decisions.
- Can hoop.dev mask data that the embedding model returns? Yes. hoop.dev inspects the response at the protocol level and replaces configured sensitive patterns before the payload reaches the client.
- Do I need to change my existing embedding client code? No. hoop.dev works with standard HTTP or SDK calls; you only point the client at the gateway’s address and provide a valid token.
By placing a non-human identity check and policy enforcement in the data path, hoop.dev turns a blind embedding pipeline into a fully auditable, privacy‑aware, and controllable workflow.
Explore the open‑source repository on GitHub to get started.
