Running a self‑hosted model without continuous audit invites PCI DSS violations.
Most teams deploy large language models or inference services on their own compute clusters and protect them with a single API key or a shared service account. The key is baked into deployment scripts, stored in plaintext, and handed to every engineer who needs to run a query. When a request reaches the model, the connection goes straight from the client to the inference server. No gateway inspects the traffic, no central log captures the exact prompt, and no mechanism masks credit‑card numbers that might appear in a response. If a breach occurs, the organization cannot prove who issued the request, what data was returned, or whether a policy was violated.
PCI DSS explicitly requires that every access to cardholder data be tracked and that the logs be retained in a tamper‑evident form. Requirement 10 mandates detailed audit trails for all system components that store, process, or transmit card data. Requirement 3 demands that sensitive data be rendered unreadable whenever it is displayed or logged. And Requirement 8 insists on strong authentication and role‑based access control. In practice, compliance teams must produce continuous evidence that each request was authorized, that the response was protected, and that any privileged operation was reviewed.
Many organizations address the authentication piece by integrating an OIDC or SAML identity provider, issuing short‑lived tokens, and assigning fine‑grained roles. This step limits who can start a connection, but it does not give the organization visibility into what happens after the token is accepted. The request still travels directly to the model, bypassing any enforcement point. Consequently, the system cannot record the exact prompt, cannot mask sensitive fields in real time, and cannot require a human to approve risky operations such as bulk data extraction.
Why PCI DSS demands continuous evidence for self‑hosted models
PCI DSS treats every interaction with cardholder data as a critical event. A single unlogged query that returns a credit‑card number can be a compliance breach. The standard therefore expects:
- Immutable logs that capture who accessed the system, when, and what was accessed.
- Real‑time protection of sensitive data in transit and at rest.
- Just‑in‑time approval workflows for high‑risk commands.
- Replay capability to reconstruct a session for forensic analysis.
When a self‑hosted model sits behind a plain network socket, none of these controls exist by default. The only way to generate the required evidence is to insert a control layer that can see every request and response without exposing credentials to the client.
How hoop.dev provides the audit trail PCI DSS requires
hoop.dev is a Layer 7 gateway that sits between the identity provider and the inference server. It proxies the connection, inspects the protocol, and applies policy before the request reaches the model. Because hoop.dev is in the data path, it can enforce the controls that PCI DSS expects.
Session recording. hoop.dev records each interaction, including the exact prompt, the model’s response, and the identity that initiated the request. The recordings are stored separate from the model process and can be replayed. This satisfies Requirement 10’s demand for a complete audit trail.
Inline data masking. When a response contains fields that match PCI‑defined patterns, such as PANs or security codes, hoop.dev can mask those values before they leave the gateway. hoop.dev keeps the original data protected, meeting Requirement 3’s encryption‑or‑masking rule.