Many teams assume that simply encrypting PHI before it reaches a LangGraph workflow satisfies all regulatory requirements. In reality, encryption alone does not produce the audit evidence regulators expect, nor does it protect against insider misuse once the data is in memory.
Today, most LangGraph deployments handle PHI with static service‑account credentials that are shared across multiple engineers and automated jobs. The credentials are stored in configuration files or secret managers that are not tied to individual identities. When a request to run a LangGraph node arrives, it bypasses any real user context, and the system logs only a generic "execution started" message. No per‑user attribution, no command‑level visibility, and no masking of sensitive fields occur. If a breach happens, the organization cannot answer who accessed which piece of PHI, what transformation was applied, or whether the data was exposed in logs.
Adding a proper identity provider and granting each engineer the minimum set of permissions is the first step toward control. With OIDC or SAML integration, every request can be tied to a user or service account, and standing access can be limited to specific LangGraph nodes. However, the request still travels directly to the LangGraph runtime. The gateway that sits between the identity layer and the runtime is missing, so there is still no place to enforce masking, request approval, or session recording. The setup alone does not generate the continuous evidence auditors require.
Why continuous evidence matters for phi
Regulators such as HIPAA and state privacy laws expect organizations to retain an audit trail that shows who accessed PHI, when, and what was done with it. Evidence must be collected at the moment of access, not retroactively from application logs that can be edited or omitted. Continuous evidence also supports incident response: if a suspicious query is detected, the organization can replay the exact session to understand the scope of exposure.
For LangGraph, this means capturing every node execution that touches PHI, masking any PHI that appears in responses, and requiring explicit approval for high‑risk operations (for example, exporting data to external storage). The evidence must be stored outside the LangGraph process so that a compromised runtime cannot alter it.
How hoop.dev creates audit evidence for LangGraph
hoop.dev acts as a Layer 7 identity‑aware proxy that sits between the authenticated request and the LangGraph runtime. When a user or an automated agent connects through hoop.dev, the gateway inspects the LangGraph protocol, applies policy checks, and records the interaction before the request reaches the actual node executor.
Because hoop.dev owns the data path, it can:
- Associate each request with the caller’s OIDC token, producing a per‑user audit record.
- Mask PHI fields in responses in real time, ensuring that downstream logs never contain raw identifiers.
- Require just‑in‑time approval for operations that match a risk rule, such as bulk data export or execution of custom code.
- Record the full session, including input prompts, node outputs, and any user‑issued commands, for later replay.
All of these actions happen inside the gateway, so the LangGraph process never sees the credential that authenticates the request. The gateway stores the audit trail in a location that is separate from the runtime, satisfying the “continuous evidence” requirement.