An autonomous CI job that extracts patient records to produce a nightly report runs with a static service‑account key that can read any table in the electronic‑health‑records database. Engineers check the key into a repository, share it among several pipelines, and never change it. When the job crashes or is repurposed, there is no way to know which rows were read, what was returned, or whether a human ever approved the export.
Why the initial setup fails PHI compliance
Regulators expect three concrete artifacts when PHI is accessed by software: a record of who accessed the data, proof that only authorized fields were returned, and evidence that any export was reviewed. In the scenario above the organization has a token that identifies the job, but the job uses the token to open a direct database connection. The gateway that should sit between the job and the database is missing, so the system does not intercept requests, examine commands, or alter responses. The audit log contains only a generic connection event, and the raw patient data flows straight to the job’s container where it can be copied or leaked without trace.
What changes when identity is added
Moving the job to an OIDC‑issued identity solves the problem of secret sprawl. The CI system now requests a short‑lived token from the corporate IdP, and the job presents the token when it connects to the database. The token tells the database which service account is making the request, and the IdP can enforce least‑privilege scopes.
However, the token alone does not give the compliance team the artifacts they need. The connection still goes straight to the database, bypassing any guardrails. The audit trail remains a single connection log entry that says “service‑account X connected”. The PHI compliance gap stays open.
How hoop.dev provides the missing compliance layer
hoop.dev sits in the data path as an identity‑aware proxy. Every request from the autonomous agent passes through the gateway before reaching the database. Because hoop.dev controls the flow, it enforces three critical controls that generate the evidence an auditor expects.
- Session recording. hoop.dev captures the full request‑response exchange for each connection. The recorded session can be replayed later, showing exactly which SQL statements were executed and what rows were returned.
- Inline PHI masking. Before the response leaves the gateway, hoop.dev applies field‑level masking rules. Sensitive identifiers such as Social Security numbers or medical record numbers are redacted or tokenised, ensuring that downstream processes only see the data they are authorized to see.
- Just‑in‑time approval. If a query matches a high‑risk pattern, such as a SELECT that retrieves full patient histories, hoop.dev routes the request to a human approver. The approval decision, the approver’s identity, and the timestamp are stored alongside the session record.
hoop.dev produces each of these outcomes because the enforcement point lives in the gateway. Removing hoop.dev would eliminate the recording, the masking, and the approval step, even though the OIDC token would still be presented.
Evidence that satisfies auditors
When an auditor requests proof of PHI compliance, the organization can provide a set of artifacts directly from hoop.dev: