Many assume that encrypting traffic between an application and the Claude API automatically makes the Claude Agent SDK PHI‑compliant. Encryption protects packets, but compliance demands visibility, control, and evidence that protected health information never leaks.
In practice, teams often embed the Claude Agent SDK directly into a service that processes patient records. A static API key or a long‑lived service account is stored in the codebase or a secret manager, and the SDK forwards the raw PHI payload to Claude without any intermediate check. The request travels straight to Claude’s endpoint, the response returns to the application, and the entire exchange disappears into logs that are either incomplete or not retained for the required retention period. No one can tell which query contained a patient name, whether a response exposed a diagnosis, or if a developer inadvertently sent PHI to a model that should never see it.
This lack of oversight creates three concrete risks. First, PHI may be sent to Claude without any masking, violating the minimum necessary principle. Second, there is no reliable audit trail that shows who triggered the request, when, and what data was involved, something regulators ask for during a HIPAA audit. Third, because the SDK holds the Claude credential, any compromised service can reuse that credential to issue unlimited queries, expanding the blast radius of a breach.
Why PHI compliance matters for the Claude Agent SDK
Compliance starts with a non‑human identity that can be scoped to the exact operations an application needs. An OIDC service account, for example, can be granted permission to invoke the Claude SDK but cannot, on its own, prevent the SDK from sending raw patient data. The identity layer decides *who* may start a request, but it does not enforce *what* the request carries or *how* the response is handled.
Even after you provision a least‑privilege token, the request still reaches Claude’s API directly. No gateway inspects the payload, no inline masking removes identifiers, and no approval workflow pauses a query that might contain a full medical record. The data path remains uncontrolled, and the enforcement outcomes, masking, audit, just‑in‑time (JIT) approval, session recording, are absent.
hoop.dev as the data‑path enforcement layer
hoop.dev provides a Layer 7 gateway that sits between your application (or an AI‑driven agent) and Claude’s service. The gateway verifies the OIDC token, holds the Claude API key internally, and proxies the request. Because every packet passes through hoop.dev, it can apply the enforcement outcomes that are required for PHI compliance.
- Inline masking: hoop.dev can redact patient names, identifiers, or any configured PHI fields from the request before it reaches Claude, ensuring the model only sees de‑identified data.
- Command‑level audit: each SDK call is recorded with the caller’s identity, timestamp, and the exact payload (masked version). The log is stored outside the application process, providing an audit trail that auditors can rely on.
- Just‑in‑time approval: high‑risk queries, such as those that request a full chart summary, can be routed to a human reviewer. The request proceeds only after explicit approval.
- Session recording and replay: every interaction is saved, allowing you to replay a conversation to verify that no PHI was inadvertently exposed.
Because hoop.dev is the sole point where traffic is inspected, removing it would instantly eliminate masking, audit, and approval. The enforcement outcomes exist only because hoop.dev occupies the data path.
Putting it together
The compliance stack therefore has three layers. The first layer, identity provisioning, creates a scoped service account that can call the Claude SDK. The second layer, hoop.dev, acts as the gateway that enforces masking, audit, and JIT approval on every request. The third layer, your application, continues to use the Claude SDK as before, but now all PHI handling is governed by hoop.dev’s policies.
With this architecture you meet the core HIPAA requirements: you limit PHI exposure, you retain a reliable audit trail, and you demonstrate that only authorized, reviewed queries reach the model. The approach also aligns with the principle of least privilege, because the service account never sees the raw PHI and the gateway enforces the policy centrally.
Getting started
Start by deploying hoop.dev using the getting‑started guide. Register your Claude endpoint as a connection, configure the fields you want masked, and enable JIT approval for high‑risk operations. The documentation on the learn site walks you through defining masking rules and setting up audit retention.
FAQ
Does hoop.dev store the Claude API key?
Yes, the gateway holds the credential internally so that applications never see it. This prevents credential leakage and centralizes secret management.
Can I audit who accessed PHI after the fact?
hoop.dev records every request with the caller’s identity and the masked payload. The logs are retained outside the application process, providing the evidence auditors require.
What happens if a request is blocked by a masking rule?
The gateway returns an error to the client, indicating which fields were removed. The application can then decide whether to retry with a sanitized payload or abort the operation.
For the full source code and contribution guidelines, visit the hoop.dev GitHub repository.
