A single exposed PHI record can trigger costly fines, damage reputation, and erode patient trust. Yet many teams that embed Claude Skills into internal tools treat the model like any other third‑party API, passing static credentials directly to the service and assuming the provider’s own logging is sufficient.
In practice, engineers often store the Claude API key in a shared vault, embed it in CI pipelines, and let any service that can reach the internet invoke the model. The request bypasses any internal policy engine, and the response, potentially containing PHI extracted from prompts, flows back to the caller unchanged. No central audit trail captures who asked what, no real‑time masking protects sensitive fields, and no approval step exists for high‑risk queries. When a breach occurs, the organization is left scrambling for evidence that may not exist.
The immediate fix is to introduce a layer that can enforce least‑privilege access, require just‑in‑time approvals, and mask PHI in responses. However, even with those controls in place, the request still travels straight to Claude’s endpoint. The gateway that decides whether a call is allowed does not see the actual data, and there is no immutable record of the interaction. Without a data‑path enforcement point, compliance programs cannot prove that PHI was handled according to regulatory expectations.
hoop.dev provides that missing data‑path. It sits between the caller’s identity and the Claude Skills service, acting as an identity‑aware proxy that inspects every request and response at the protocol level. Because the gateway is the only point where traffic passes, hoop.dev can enforce inline masking of PHI, require a human approver for queries that match sensitive patterns, and record the full session for replay. The recorded evidence includes the authenticated user, the exact prompt, the model’s response, and timestamps, all stored outside the caller’s process.
Why traditional Claude integrations fall short for phi
Claude’s own logging is designed for debugging, not for regulatory audit. It does not retain the original user context, nor does it provide field‑level redaction. When a health‑care application sends a patient’s name and diagnosis in a prompt, that information may be written to logs in plain text, violating PHI handling rules. Additionally, the model’s response can contain inadvertent disclosures that are never examined before reaching the application.
The compliance gap that remains after basic access controls
Even if an organization implements API‑key rotation, network firewalls, and role‑based access to the Claude endpoint, the following gaps persist:
- No guarantee that PHI is removed from model responses before they reach downstream systems.
- No auditable trail linking a specific user to a specific prompt and answer.
- No ability to pause a request for manual review when it contains high‑risk data.
Regulators expect continuous evidence that every PHI interaction is controlled, masked, and logged. Without a gateway that can enforce these policies at the data path, the organization must rely on after‑the‑fact log analysis, which is often incomplete.
How hoop.dev creates continuous phi evidence
When a user authenticates via OIDC or SAML, hoop.dev validates the token, extracts group membership, and maps the identity to a set of permissions. The user then issues a standard Claude API call through the gateway. At that moment hoop.dev evaluates the request against configurable policies:
- Inline masking: hoop.dev scans the request and response for patterns that match PHI (names, IDs, dates) and replaces them with safe placeholders before the data leaves the gateway.
- Just‑in‑time approval: If a request contains a trigger phrase such as "patient record" or exceeds a token‑count threshold, hoop.dev routes the request to an approval workflow where a designated reviewer can allow or deny the operation.
- Session recording: hoop.dev captures the full request‑response exchange, timestamps, and the authenticated user ID. The session log is retained in a dedicated storage area separate from the application, ensuring a reliable audit record.
Because hoop.dev is the sole conduit, every PHI‑related interaction is automatically covered by these controls. If hoop.dev were removed, none of the masking, approval, or recording would occur, demonstrating that the enforcement outcomes depend entirely on the gateway.
Implementing the solution
Deploy the gateway close to the Claude Skills endpoint, typically using the provided Docker Compose quick‑start. Register the Claude service as a connection, supplying the service credential to the gateway so that callers never see it. Configure PHI‑specific policies in the UI or via the declarative policy file, then enable OIDC authentication against your identity provider. The getting‑started guide walks through each step, and the learn section offers deeper examples of masking rules and approval workflows.
FAQ
Does hoop.dev store the Claude API key?
Yes, the gateway holds the credential securely and injects it only when forwarding the request. Callers never receive the raw key.
Can I audit who accessed Claude and what they asked?
hoop.dev records every session with the user identity, full prompt, and masked response, providing the evidence auditors require for PHI compliance.
Is the masking configurable?
Masking rules are policy‑driven and can be tailored to the specific PHI patterns your organization needs to protect.
Ready to see the code in action? Explore the open‑source repository on GitHub and start building a compliant Claude Skills integration today.
