Do you know which logs you will hand to a HIPAA auditor when a service account runs a query on BigQuery?
Most organizations treat machine identities like static API keys or long‑lived service accounts. Those credentials are stored in configuration files or secret managers and are shared across pipelines, CI jobs, and ad‑hoc scripts. The result is a landscape where any compromised key can be used to read or write protected health information (PHI) without a clear trail. Auditors often see a single “machine user” entry in the access logs, but no record of which pipeline, which developer, or which approval triggered the request.
This lack of visibility violates the intent of HIPAA’s audit controls. The regulation requires that every access to PHI be attributable to a specific identity and that the organization retain evidence of that attribution. When a non‑human identity initiates a BigQuery job, the request still travels directly to the Google service, bypassing any enforcement point that could record the decision context, mask sensitive fields in the result set, or require a human sign‑off before the query runs.
To meet HIPAA, you need a control plane that does three things: it captures who or what initiated the request, it enforces policy at the moment of access, and it stores a record that can be presented to auditors. The control plane must sit in the data path so that no request can reach BigQuery without first being examined. It also needs to support just‑in‑time (JIT) grants for service accounts, inline masking of PHI in query results, and session recording for replay during investigations.
Why audit evidence matters for hipaa
HIPAA’s Security Rule mandates logs that show: the identity of the individual (or system) accessing ePHI, the date and time of access, the type of access, and the outcome of the request. Evidence must be retained for six years and be readily available for inspection. When a service account runs a query, the raw audit event from BigQuery only includes the service account name; it does not capture the upstream approval, the JIT token, or the masking actions applied to the result set. Without additional evidence, an auditor cannot prove that the organization enforced the minimum necessary standard for PHI exposure.
How hoop.dev captures the required artifacts
hoop.dev acts as a Layer 7 gateway that sits between the caller and BigQuery. By placing the gateway in the data path, hoop.dev becomes the sole point where every request is inspected. It records the full session, including the originating non‑human identity, the JIT approval token, and the exact query text. Before the query reaches BigQuery, hoop.dev can apply inline masking rules to redact PHI fields in the response. If a query exceeds a risk threshold, hoop.dev routes it to a human approver for sign‑off. All of these actions are logged to an audit store that satisfies HIPAA’s retention and availability requirements.
Setup: provisioning non‑human identities
The first step is to define service accounts in your identity provider and grant them the minimal set of scopes needed to request a JIT token from hoop.dev. These accounts never see the underlying BigQuery credentials; the gateway holds them securely. The provisioning process is documented in the getting‑started guide, which walks you through creating OIDC clients, assigning group membership, and configuring the gateway to recognize the service accounts.