How can you prove that CrewAI workflows that touch phi are auditable without rewriting your entire stack?
Most teams start by granting the AI service a static database user or a service‑account key that can read and write patient records. The credential lives in a secret store, the AI code pulls it at runtime, and every query runs directly against the underlying PostgreSQL or MongoDB instance. Engineers can see the raw data, and there is no central point that records who asked for what, when, or whether a response contained protected health information. When an incident occurs, the logs are scattered across application logs, database logs, and ad‑hoc audit trails. The result is a compliance gap that auditors flag as “insufficient evidence of access control and data handling for phi”.
Even when an organization adopts modern identity providers, OIDC, SAML, or federated Azure AD, those tokens only prove that a request was authenticated. The request still travels straight to the database or API, bypassing any enforcement layer that could mask identifiers, require a human approval for high‑risk queries, or capture a replayable session. The identity system alone does not generate the granular, per‑command audit records that PHI regulations demand.
Why existing setups fall short for phi compliance
Regulatory frameworks for PHI require three core artifacts:
- A definitive log of every access attempt, including user identity, timestamp, and the exact query or command executed.
- Evidence that sensitive fields (for example, Social Security numbers or medical record numbers) are protected, either by masking in responses or by restricting the columns that can be returned.
- Proof of intent‑based controls, such as just‑in‑time (JIT) approvals for privileged operations, and the ability to replay a session for forensic analysis.
When a team relies solely on the underlying database’s audit feature, they often miss the “intent” layer. Database logs may capture the SQL statement but not the identity that originated it if the connection uses a shared service account. Masking is usually an after‑the‑fact process, applied by downstream ETL jobs rather than at the point of access. And without a gateway that can enforce JIT approval, any engineer with the service account can run a destructive command at any time.
The missing control layer
The missing piece is a Layer 7 gateway that sits between the AI runtime and the target system. This gateway becomes the sole place where policy can be enforced, because every request must pass through it. The gateway can:
- Inspect the protocol (SQL, HTTP, SSH) and apply inline masking rules before data leaves the target.
- Require a real‑time approval workflow for commands that match a risk profile, such as bulk updates to patient tables.
- Record the full session, including request, response, and user identity, in an immutable audit store that auditors can query directly.
- Enforce just‑in‑time access windows, granting temporary rights that automatically expire.
Without this control layer, the identity system is only a gate‑keeper, not a policy enforcer. The enforcement outcomes exist only because the gateway sits in the data path.
How hoop.dev creates phi audit evidence
hoop.dev implements exactly this control layer. It is deployed as a network‑resident agent that proxies connections to databases, Kubernetes clusters, SSH endpoints, and internal HTTP services. When a CrewAI job initiates a connection, it authenticates to hoop.dev via OIDC or SAML. hoop.dev validates the token, extracts group membership, and then forwards the request to the target. At that point, hoop.dev becomes the only place where policy can be applied.