Uncontrolled AI interactions today
A disciplined AI governance program makes every computer‑based interaction with large language models transparent, auditable, and strictly limited to approved prompts, ensuring that the organization retains control over what is asked and what is received.
In many workplaces, engineers, analysts, and even automated scripts launch AI models directly from personal laptops or shared workstations, using the same API keys and credentials that were originally intended for ad‑hoc experimentation.
Those credentials are often placed in plain‑text configuration files, environment variables, or version‑controlled repositories, and users paste proprietary code, customer data, or confidential business strategies into chat windows that are never recorded by any central system.
Because the requests travel straight from the endpoint to the cloud provider, there is no visibility into who issued a particular prompt, what data was included, or how the model responded, creating a blind spot that can lead to data exfiltration, compliance violations, and difficulty proving intent during audits.
Risks and failure modes
Common failure modes include prompting the model with raw customer identifiers, asking it to generate code that contains hard‑coded secrets, or using it to summarize internal documents that should remain confidential. Without a gate, these actions go unchecked.
Why governance is needed
Effective governance therefore requires three pillars: identity‑bound access that ties every request to a verifiable user, real‑time policy enforcement that can block or modify unsafe inputs and outputs, and an audit log that captures the full exchange for later review.
Designing policies
Policy designers typically start by classifying data sensitivity levels, mapping them to allowed model capabilities, and defining approval workflows for any request that crosses a predefined risk threshold.
The enforcement point
The enforcement point must be a gateway that sits between the computer and the AI service, capable of inspecting the request and response streams at the protocol level without requiring changes to existing client tools.
Introducing the gateway
hoop.dev implements that gateway. It authenticates users via OIDC or SAML, reads group membership to derive fine‑grained AI permissions, and stores the model credentials centrally so that client machines never see secret keys.
Because hoop.dev resides in the data path, it can enforce just‑in‑time approvals for high‑risk prompts, apply inline masking or redaction to any response that contains personally identifiable information, and block commands that violate corporate policy before they reach the external model endpoint.
Every interaction is recorded by hoop.dev, producing a replayable session that links each request to a specific identity, timestamp, and policy decision, thereby supplying the evidence needed for internal reviews and external audits.
Setup versus enforcement
The setup phase, defining OIDC clients, provisioning service accounts with the minimum necessary scopes, and configuring group‑based policies, decides who may initiate a request, but it does not by itself prevent misuse of the AI service.
All enforcement outcomes, inline masking, just‑in‑time approval, command blocking, and session recording, exist only because hoop.dev operates as the gateway in the data path, the sole place where traffic can be examined and altered.
Benefits of central control
By centralizing control, organizations shrink the blast radius of accidental data leaks, gain visibility into usage patterns across teams, and can demonstrate concrete governance evidence without rewriting existing scripts or tools.
The recorded sessions are emitted as structured events that can be consumed by existing security tooling. By feeding these events into a SIEM, teams can correlate AI activity with other user actions, build dashboards, and set automated thresholds that trigger investigations when policy violations occur.
Policies in hoop.dev are versioned and can be updated without disrupting ongoing sessions. When a new masking rule is added, subsequent responses are automatically filtered according to the latest definition, ensuring that governance evolves alongside business requirements.
Because the gateway mimics the native API endpoint, developers can embed the same address in scripts, containers, or serverless functions, gaining the same protection without refactoring code.
Getting started
To begin, follow the getting‑started guide and explore the feature documentation for detailed policy configuration, role mapping, and masking rules.
Call to action
Explore the source code and contribute on GitHub.
FAQ
What identity mechanisms does hoop.dev support for AI governance?
hoop.dev works as an OIDC and SAML relying party, accepting tokens from any compliant identity provider. It extracts user and group claims to drive per‑user policy decisions.
How does hoop.dev protect sensitive output from being exposed?
It can apply inline masking rules that redact fields matching regex patterns, data‑type tags, or custom policies before the response reaches the client, ensuring that PII or confidential strings never leave the gateway.
Can hoop.dev be integrated into existing CI/CD pipelines that call AI models?
Yes. Because the gateway presents the same endpoint signature as the native model API, pipelines can point to the hoop.dev address and automatically benefit from the same JIT approvals, masking, and audit logging without code changes.
