Is your team sure that the access reviews for BigQuery actually reflect who ran each query? That question haunts many security and compliance groups because the answer is often “no.”
Most organizations grant service accounts wide‑range permissions on BigQuery and let automation agents or scripts run under those accounts. The agents are usually configured once and then reused for weeks or months. When a new engineer needs to run a report, they are handed the same credential or asked to invoke the same automation wrapper. The result is a shared identity that masks the real actor behind every query. If an attacker compromises the automation, they inherit the same privileged token and can issue arbitrary queries without leaving a trace tied to a human user.
Access reviews rely on the premise that each permission can be traced back to a distinct identity. When a privileged service account is used as a blanket credential, reviewers see a list of accounts with broad scopes but no visibility into which individual triggered a particular query. The review process therefore becomes a checklist of “does this account need these rights?” rather than an evidence‑based assessment of actual usage. Even if you tighten IAM policies, the request still travels directly to BigQuery, bypassing any point where you could verify the true caller or enforce additional controls.
The missing piece is a data‑path enforcement layer that can see the request, apply policy, and record the outcome before it reaches the target. Without such a layer, the setup, identity federation, least‑privilege roles, and service‑account provisioning, only decides who *may* start a connection. It does not guarantee that the connection is inspected, approved, or logged in a way that supports reliable access reviews. The request continues to flow straight to BigQuery, leaving the audit trail empty and the opportunity for impersonation unchecked.
hoop.dev fills that gap by acting as a Layer 7 gateway positioned between the identity provider and BigQuery. The gateway receives the user’s OIDC token, validates it, and then proxies the query to BigQuery on behalf of the user. Because the proxy sits in the data path, it is the only place where enforcement can happen. hoop.dev can require just‑in‑time approval for risky queries, block commands that match a deny list, and mask sensitive result fields in real time. Most importantly, hoop.dev records every session, tying each query to the original identity that presented the token.
When hoop.dev records a session, the log entry includes the user’s subject, the exact SQL statement, the time of execution, and the outcome of any policy check. Those records become the evidence that access‑review teams need: they can now answer “who ran this query, when, and was it approved?” without guessing. Because the gateway holds the credential for BigQuery, the agent never sees the underlying service‑account key, eliminating the avenue for credential leakage and subsequent impersonation.
The enforcement outcomes, session recording, inline masking, just‑in‑time approval, and command blocking, exist only because hoop.dev sits in the data path. If you removed the gateway, the same identity setup would revert to the original problem: a shared service account issuing untracked queries. In other words, hoop.dev is the active cause of the audit fidelity required for trustworthy access reviews.