How do you let an AI coding assistant like Claude write queries against production BigQuery tables while enforcing production access controls?
Many teams hand Claude a service‑account key that has read‑write rights across all datasets. The key lives in the agent’s runtime, is reused for every request, and there is no record of which query was issued, who approved it, or whether sensitive fields were returned. In practice the AI can issue destructive DML, export entire tables, or exfiltrate personally identifiable information, and the activity disappears into the logs of the BigQuery service itself.
To reduce the obvious risk, organizations typically move to a non‑human identity model: a dedicated service account with a tighter set of IAM permissions, and an OIDC token that authenticates the agent. This step limits the surface area, Claude can no longer touch every dataset, but the request still travels straight to BigQuery. There is still no gate that can inspect the SQL, mask column values, require a human sign‑off for risky statements, or capture a replayable session for later review.
Why the data path must host the controls
Only a gateway that sits between the AI agent and the BigQuery endpoint can enforce the missing safeguards. The gateway examines each SQL command, applies inline masking to columns such as SSNs or credit‑card numbers, blocks statements that alter production tables unless an approver explicitly authorizes them, and records the entire conversation for audit and replay. Because the gateway is the sole point where traffic passes, every enforcement outcome is guaranteed to happen.
hoop.dev provides exactly that Layer 7 access proxy. It authenticates the Claude agent via OIDC, extracts the user or service‑account identity, and then routes the request through its data‑path component. The component can enforce just‑in‑time access, require an approval workflow for DML or DDL, mask sensitive result fields on the fly, and store a session log that can be replayed by an auditor. All of these capabilities exist because hoop.dev sits in the data path; without it, the setup described above would remain insecure.
How the architecture looks for Claude on BigQuery
1. Identity – Claude obtains an OIDC token from the organization’s identity provider (Okta, Azure AD, Google Workspace, etc.). The token proves who the agent is and carries group membership that hoop.dev can evaluate.
2. Gateway deployment – A hoop.dev gateway is deployed inside the same network as the BigQuery project. An agent runs alongside the BigQuery service, holding the static credential that the gateway uses to talk to BigQuery.
3. Connection registration – The BigQuery connection is registered with the gateway, including the target project, dataset, and the credential the gateway will use. Users never see this credential; the gateway presents it on their behalf.
4. Request flow – When Claude issues a query, it is sent to the gateway instead of directly to BigQuery. The gateway inspects the SQL, applies any masking policies, checks whether the operation requires approval, and either forwards the query or pauses it for a human reviewer.
5. Enforcement outcomes – hoop.dev records the full session, masks protected columns, blocks unauthorized DML, and logs the approval decision. Auditors can later replay the session to verify that no prohibited data left the environment.
Getting started with production access
To try this pattern, follow the getting‑started guide for a quick Docker‑Compose deployment of the gateway. The guide walks you through configuring OIDC, registering a BigQuery connection, and defining masking and approval policies. For deeper insight into policy configuration, see the learn page that explains how to craft rule sets for column‑level masking and command‑level approvals.
All of the source code and example configurations are available in the open‑source repository. Explore the GitHub repository to see how the gateway is built, contribute improvements, or adapt it to your own compliance framework.
FAQ
- Does hoop.dev replace the need for IAM policies on the service account? No. IAM still defines the baseline permissions. hoop.dev adds runtime enforcement, masking, approval, and audit, on top of those static permissions.
- Can I still use the standard bq CLI with the gateway? Yes. The gateway presents a standard BigQuery endpoint, so existing client tools work unchanged; they simply route through hoop.dev instead of connecting directly.
- What happens if the approval workflow is delayed? hoop.dev can be configured to either time‑out the request or queue it until an approver responds, ensuring that no risky operation proceeds without explicit consent.
By placing the control plane in the data path, hoop.dev gives you production‑grade safeguards for AI‑driven query generation without rewriting your applications or sacrificing developer velocity.
