A common misconception is that protected health information stays safe as long as it never lands in a database. In reality, the moment PHI is placed into an AI prompt, it becomes part of the model’s context window and can travel far beyond the original request.
PHI includes any individually identifiable health details, diagnoses, treatment dates, medication names, or lab results. Regulations such as HIPAA treat the disclosure of these data points as a breach, regardless of the storage mechanism.
Why PHI in context windows is a risk
Large language models process input in chunks called context windows, typically a few thousand tokens. The window holds the most recent conversation, and the model can reference any token inside it when generating a response. Consequently, any PHI that slips into the prompt remains reachable for the duration of that window.
If the prompt is logged, cached, or replayed, the PHI persists in logs that may be accessed by administrators, support tools, or even downstream AI services. Moreover, without explicit filtering, the model can echo PHI back to the user or embed it in generated code, increasing the blast radius of a single request.
How context windows retain data
Each token that enters the model stays in memory until the window slides past it. For a 4,000-token window, a PHI string entered early in a conversation may be reachable for dozens of subsequent turns. This persistence means that even a brief accidental inclusion can affect many later responses, amplifying the exposure risk.
Common failure modes
Teams often rely on manual redaction, assuming a developer will remember to strip PHI before calling an LLM. In practice, copy-and-paste errors, auto-completion, or generated code snippets re-introduce the data. Another pitfall is logging the raw request payloads in centralized log aggregators, which creates a searchable archive of PHI that is difficult to purge.
Policy design for PHI
Effective masking starts with a clear inventory of health fields. Map each column or JSON key that holds PHI to a policy rule, and assign a mask type, such as full redaction, tokenization, or hashing, depending on downstream needs. Policies can be scoped by role, so a data-science analyst sees only de-identified aggregates, while a clinician with higher clearance may request a temporary unmasking through a just-in-time approval workflow.
Integration with AI services
When an application calls an LLM endpoint, the request passes through the hoop.dev proxy instead of contacting the provider directly. The proxy injects the masking layer, applies any required approvals, and forwards the sanitized payload. The response returns through the same path, where hoop.dev can strip any residual PHI before it reaches the caller. This bidirectional guardrail works with OpenAI, Anthropic, or any compatible HTTP-based model API.
Compliance and audit
Regulators require a reliable audit log that shows who accessed PHI and when. hoop.dev records every session, including the identity that initiated the request, the exact query sent, and the masked response delivered. Because the gateway sits outside the application, the logs cannot be altered by a compromised service, giving auditors a reliable chain of custody for each interaction.
Real-world example
A health-tech startup built a chatbot to help clinicians draft discharge summaries. An intern inadvertently pasted a patient’s full name and diagnosis into the chat window. The request traveled through the hoop.dev gateway, which matched the name and diagnosis against the PHI policy, redacted them, and routed the request for a brief manual approval. The approved, masked prompt reached the LLM, which generated a response free of identifying details. The session log captured the original attempt, the approval step, and the final output, providing a complete audit trail for the compliance team.
Quick checklist
- Verify OIDC integration with your IdP.
- Tag PHI fields in the data schema.
- Enable hoop.dev’s inline masking and session recording.
- Test approval workflows for high-risk queries.
- Review audit logs regularly to confirm PHI never appears.
Following these steps keeps PHI out of the model’s context window while still allowing developers to use AI assistance safely.
FAQ
Can hoop.dev automatically detect PHI in any format? hoop.dev relies on policies you define. You declare which fields or patterns constitute PHI, and the gateway masks any matching data in real time.
What happens to the original PHI after masking? The gateway never forwards the raw value to the downstream model. The masked token is stored only in the session log, which is kept in a separate, access-controlled store for audit purposes.
For a hands-on start, see the getting-started guide and the learn section for details on policy creation and masking configuration.
Explore the open-source code on GitHub to deploy your own gateway.
