When every query issued by an AI coding agent to BigQuery is logged, masked where necessary, and approved before execution, the organization can be confident that data exfiltration is no longer a silent threat. In that ideal state, auditors see a complete, immutable trail, sensitive columns never leave the vault, and any unexpected data movement triggers a human review.
Today many teams hand AI‑driven assistants direct access to their data warehouses. The agent receives a service account credential, connects straight to BigQuery, and runs whatever SQL the model generates. This shortcut feels natural: developers type a prompt, the model emits a query, and the result appears in the notebook. The convenience hides a serious gap – the credential is long‑lived, the connection bypasses any central policy point, and the raw result streams back to the user or downstream system without inspection.
Even when organizations adopt non‑human identities for these agents and enforce least‑privilege scopes, the request still travels straight to BigQuery. The gateway that could enforce masking, block suspicious SELECTs, or require an approval step is missing. Consequently, a model that mistakenly includes a customer‑PII column or a proprietary metric can exfiltrate that data with a single query, and the event remains invisible to security teams.
Current practice with AI coding agents
Most AI‑assisted development environments embed a credential for the data warehouse directly in the runtime. The credential is often a service account with read‑only rights, but read‑only does not stop a malicious query from pulling large volumes of data. Because the agent talks directly to BigQuery, the platform cannot inspect the SQL payload, apply column‑level redaction, or enforce a “just‑in‑time” approval workflow. The result is a blind spot: data exfiltration can happen silently, and the only evidence is the query logs stored inside BigQuery, which are only accessible after the fact.
Why data exfiltration remains possible
The root of the problem is the missing enforcement layer. Identity providers (Okta, Azure AD, Google Workspace) can assert who the agent is, and IAM policies can limit which datasets are reachable. Those controls decide whether the request may start, but they do not see the actual SQL text or the rows returned. Without a data‑path gateway, there is no place to:
- Inspect each query for prohibited column references.
- Mask sensitive fields in the response before they reach the agent.
- Require a human approver when a query touches high‑risk tables.
- Record the full session for replay and audit.
Because the enforcement outcomes live nowhere, removing the agent or rotating its credential does not retroactively stop a past exfiltration. The organization remains exposed to accidental leakage or deliberate abuse.
Gatekeeping with hoop.dev
hoop.dev inserts a Layer 7 gateway between the AI coding agent and BigQuery. The gateway runs a network‑resident agent inside the same VPC as the warehouse, so all traffic is proxied through it. hoop.dev verifies the OIDC token presented by the agent, extracts group membership, and then applies policy checks on the actual SQL payload. The gateway can:
- Block or rewrite queries that reference protected columns, preventing raw data from ever leaving the warehouse.
- Apply inline masking so that the response stream contains only redacted values.
- Route suspicious queries to a just‑in‑time approval workflow, pausing execution until a designated reviewer signs off.
- Record every session, including the full query and masked response, for later replay and audit.
Because hoop.dev sits in the data path, the enforcement outcomes exist only because it is present. If the gateway were removed, the same credential would again talk directly to BigQuery and the protections would disappear.