Data classification is the missing safeguard when running a self‑hosted model on raw enterprise data.
In practice, many teams spin up an LLM container, point it at log files, email archives, or customer records, and trust that the model will not exfiltrate anything. The risk is amplified when the same model is accessed by dozens of engineers, scripts, or automated agents, each operating under different assumptions about what data is safe to send.
Data classification is the first line of defense. By labeling records as public, internal, or restricted, an organization can decide which payloads are permissible for inference. However, most deployments stop at the labeling stage. The model still receives the request directly, meaning there is no real‑time check that the payload matches its classification, no audit trail of who asked what, and no way to scrub sensitive fields before they are processed.
Why classification alone is not enough
Even a rigorous classification program can fall short when the enforcement point is missing. Engineers may forget to tag a new data source, scripts can bypass manual checks, and AI‑assisted tools might generate queries on the fly. Without a central point that inspects each request, the following gaps remain:
- Unclassified or mis‑classified data reaches the model unchecked.
- There is no record of which user or service sent a particular prompt.
- Sensitive fields such as SSNs or credit‑card numbers can be echoed back in model responses.
- Any accidental exposure cannot be traced back to a specific request for remediation.
These gaps exist because the enforcement logic lives outside the model’s runtime, and the model itself has no built‑in policy engine for data classification.
Introducing a data‑path gateway
hoop.dev sits between the requester and the self‑hosted model, acting as an identity‑aware proxy that enforces classification policies at the protocol layer. Because it is the only component that can see the request before it reaches the model, hoop.dev can apply the missing controls without requiring changes to the model code.
When a user authenticates via OIDC, hoop.dev validates the token, extracts group membership, and maps that identity to a classification policy. The gateway then inspects the inbound payload. If the request contains data labeled as restricted, hoop.dev can either mask the sensitive fields, block the request until a human approves it, or log the attempt for later review. Every inference session is recorded, providing a replayable audit trail that ties the request back to the originating identity.
How the gateway enforces data classification
hoop.dev implements three core enforcement outcomes that directly address the gaps described above:
- Inline masking: hoop.dev redacts or replaces classified fields before the payload reaches the model, for example by substituting a credit‑card number with a generic placeholder such as "XXXX‑XXXX‑XXXX‑1234".
- Just‑in‑time approval: If a request contains restricted data, hoop.dev routes it to an approver who can grant a one‑time permission, ensuring that only vetted queries are processed.
- Session recording: hoop.dev logs the full request and response, linking it to the user’s identity, which satisfies audit requirements and enables forensic analysis.
All of these actions happen in the data path, meaning the model never sees unfiltered or unauthorized data, and the organization retains full visibility into model usage.
Deploying the gateway for self‑hosted models
Setup begins with provisioning the gateway in the same network segment as the model. The gateway holds the model’s service credentials, so users never handle them directly. Identity providers such as Okta, Azure AD, or Google Workspace supply the tokens that hoop.dev validates. Once the gateway is running, engineers point their client (curl, python‑requests, or a custom inference script) at the gateway’s address instead of the model’s raw endpoint.
From that point forward, every inference request passes through the classification checks described above. The deployment is documented in the getting started guide, which walks through container‑based installation and basic policy configuration.
Benefits beyond compliance
While data classification is often driven by regulatory mandates, the practical benefits of a gateway extend to everyday development. Engineers gain confidence that accidental data leaks are caught automatically, reducing the need for manual code reviews of prompt construction. Security teams obtain a single source of truth for model access, simplifying incident response. And because hoop.dev is open source, organizations can audit the enforcement logic themselves or extend it to cover new data types.
For a deeper dive into policy definition, masking rules, and approval workflows, the learn section provides extensive examples and best‑practice recommendations.
FAQ
Q: Do I need to modify my model code to use hoop.dev?
A: No. The gateway operates at the network layer, so existing inference clients continue to work without code changes.
Q: Can hoop.dev handle high‑throughput inference workloads?
A: Yes. The gateway is designed to scale horizontally; you can run multiple instances behind a load balancer to match your model’s throughput.
Q: Is the audit data stored securely?
A: hoop.dev records sessions and can be integrated with existing log aggregation pipelines, allowing you to apply your organization’s storage and retention policies.
Explore the source code on GitHub to see how the gateway enforces data classification for self‑hosted models.
