A single HIPAA violation can cost millions in fines and erode patient trust. When an organization runs its own AI models on‑premise, the same regulatory stakes apply: any protected health information (PHI) that passes through the model must be accounted for, masked where required, and never exposed to unauthorized eyes.
Self‑hosted models are attractive because they keep data inside the corporate network, but that advantage disappears the moment a request reaches the model without a transparent control point. Engineers often connect directly with a client library, a curl command, or an internal script, trusting that the model’s runtime logs are sufficient. In practice those logs are incomplete, lack per‑user attribution, and rarely capture the exact query‑response exchange needed for a HIPAA audit.
Why HIPAA evidence matters for self‑hosted models
HIPAA’s Security Rule demands documented evidence that only authorized individuals accessed PHI, that every access was logged, and that any disclosure was intentional and approved. Auditors look for:
- Exact timestamps of each request and response.
- Identification of the user or service account that initiated the request.
- Proof that sensitive fields were masked or redacted before leaving the system.
- Approval records for high‑risk operations.
- Replayable session recordings for forensic analysis.
Without a single point that can capture all of these items, organizations end up stitching together logs from the model runtime, the operating system, and network devices, an error‑prone process that often fails to satisfy auditors.
HIPAA evidence requirements
The rule does not prescribe a specific technology, but it does require that the evidence must be immutable, time‑ordered, and tied to an identity. That means the control surface must sit on the traffic path between the identity provider and the model endpoint, not after the fact.
Why a data‑path gateway is required
Setup components, OIDC or SAML identity providers, service‑account roles, and least‑privilege policies, decide who may start a request, but they cannot enforce masking, approval, or recording on the data itself. The only place enforcement can happen is the data path that carries the request to the model. By inserting a gateway at that point, you gain the ability to apply policies in real time and to produce the audit artifacts HIPAA demands.
hoop.dev as the enforcement layer
hoop.dev is a Layer 7 gateway that proxies connections to self‑hosted model endpoints. It authenticates users via OIDC/SAML, reads group membership, and then applies policy checks before any data leaves the model. Because hoop.dev sits in the data path, it can:
- Record each session with full request and response details.
- Mask PHI fields in real time, ensuring that only sanitized data is returned to the caller.
- Require just‑in‑time human approval for operations flagged as high‑risk.
- Store immutable logs that can be exported to a SIEM or audit archive.
- Provide replayable recordings for forensic review.
All of these outcomes exist only because hoop.dev is the gateway that intercepts the traffic; the upstream identity system alone cannot produce them.
Artifacts hoop.dev creates for auditors
When a request passes through hoop.dev, the following artifacts are generated automatically:
- Session log entry: User ID, client IP, timestamp, and the exact query sent to the model.
- Response record: The model’s answer, with any PHI fields masked according to policy.
- Approval chain: If a request required manual approval, the approver’s identity, decision, and timestamp are captured.
- Audit trail: A chronological series of all session entries, stored in an immutable log.
- Replay file: A binary recording that can be replayed to reproduce the exact interaction for investigations.
These artifacts satisfy the evidence checklist that HIPAA auditors expect, and they are produced without any code changes to the model itself.