When AI services are governed properly, ai governance ensures that every prompt, response, and model interaction is auditable, sensitive data is never exposed, and risky requests are blocked before they reach the model. Teams can trust that their LLM‑driven workflows comply with internal policies and external regulations without slowing down development.
In many organizations, developers reach for a large language model by embedding a static API key in source code or CI pipelines. The key is shared across dozens of services, rarely rotated, and never tied to an individual identity. Because the request bypasses any central control plane, there is no record of who asked what, no way to mask personally identifiable information in the response, and no checkpoint to stop a prompt that could cause data leakage or policy violation. The result is a hidden attack surface that can be exploited by insiders or compromised credentials.
Some teams try to improve the situation by moving the API key into a secret manager and requiring a short‑lived token obtained via OIDC. This adds identity‑based authentication, but the token still grants direct access to the model endpoint. The request travels straight from the client to the model, so the organization still lacks real‑time inspection, inline masking, or an approval workflow. The gateway that could enforce those controls is missing, leaving the core governance problem unsolved.
The missing piece is a data‑path component that sits between the caller and the model, able to observe and intervene on every LLM interaction. By placing a proxy at the protocol layer, the organization can enforce policy, capture a complete audit trail, and apply dynamic data protection without changing existing client code.
hoop.dev provides exactly that. It acts as an identity‑aware MCP gateway, intercepting LLM traffic, applying policy checks, and recording each session. The product is open source, MIT licensed, and designed to sit in the network close to the model endpoint.
Setup: identity and least‑privilege grants
The first step is to configure authentication with an OIDC or SAML provider. Each user or service obtains a short‑lived token that encodes their group membership and role. The token is presented to hoop.dev, which validates it and maps the identity to a set of permissions. Permissions are expressed as fine‑grained policies that define which prompts are allowed, which model features can be used, and what data may be returned.
Because the token is scoped to the specific request, the principle of least privilege is enforced at the identity layer. No static credential is ever stored on the client side, and the gateway never trusts a bearer token beyond the verification step.
AI governance enforcement with hoop.dev
hoop.dev sits on the network path between the caller and the LLM endpoint. All traffic is routed through the gateway, which operates at the wire‑protocol level. This placement makes the gateway the only place where enforcement can happen. The client continues to use its usual SDK or CLI, but the connection is transparently proxied through hoop.dev.
Because the gateway controls the flow, it can inspect each request in real time, apply inline transformations, and decide whether to forward, mask, or reject the call.
Enforcement outcomes delivered by hoop.dev
hoop.dev records every session, preserving a replayable log that includes the identity of the requester, the exact prompt sent, and the model’s response. This log satisfies audit requirements and provides forensic evidence when a policy breach is investigated.
hoop.dev masks sensitive fields in model responses, ensuring that personally identifiable information never leaves the controlled environment. The masking happens on the fly, so downstream systems only see redacted data.
hoop.dev blocks prompts that match a deny list or that exceed defined risk thresholds. Dangerous commands are intercepted before they reach the model, preventing accidental data exfiltration or policy violations.
hoop.dev routes high‑risk requests to a human approver. An authorized reviewer can grant or deny access in real time, adding an explicit approval step to the workflow.
Why this matters for AI governance
By centralising control in the data path, hoop.dev turns an uncontrolled LLM integration into a governed service. Organizations gain visibility into every AI interaction, can enforce data‑handling policies consistently, and reduce the blast radius of compromised credentials. The approach also aligns with regulatory expectations for auditability and data protection without requiring developers to rewrite their applications.
For teams ready to adopt this model, the getting‑started guide walks through deploying the gateway, configuring OIDC, and defining policies. The learn section provides deeper examples of masking rules, approval workflows, and session replay.
All of the source code and configuration examples are available in the GitHub repository. Contributions are welcome, and the community maintains an extensive set of plugins for extending policy logic.
FAQ
- Does hoop.dev replace my existing secret manager? No. hoop.dev consumes tokens issued by your identity provider. Secrets remain in your manager; the gateway only holds the short‑lived credentials needed to talk to the LLM.
- Can I use hoop.dev with any LLM provider? The gateway works with any model that speaks a standard HTTP or gRPC API. You configure the target endpoint once, and hoop.dev handles the rest.
- What happens to performance? Because hoop.dev operates at the protocol layer and runs close to the model, latency overhead is minimal. The audit log is written asynchronously, so request latency is not significantly impacted.
