When an AI coding agent runs unrestricted queries against a production BigQuery warehouse, the lack of production access control can expose millions of rows, inflate cloud bills, and corrupt downstream analytics pipelines. The financial and reputational cost of such a slip quickly outweighs the convenience of a shared credential.
Today many teams hand the same Google service‑account key to their automated agents. The key lives in CI pipelines, is checked into container images, and is used by any process that can reach the network. Because the agent authenticates directly to BigQuery, there is no per‑user audit trail, no way to hide sensitive columns, and no gate that can pause a risky query for human review.
Even when teams move to a non‑human identity model, issuing a distinct service account per agent or enabling GCP IAM federation, the request still travels straight to the BigQuery endpoint. The gateway that could enforce policies is missing, so the system still lacks production access control: no inline masking, no just‑in‑time approval, and no session record that can be used for audit.
Production access control with hoop.dev for BigQuery
In this architecture the identity layer (OIDC or SAML) determines who the AI agent is, but the only place the system can actually enforce policies is the data path. hoop.dev acts as a Layer 7 gateway that sits between the agent and BigQuery. By proxying the connection, hoop.dev can inspect each query, apply column‑level masking, require an approval workflow before executing high‑impact statements, and record the entire session for replay.
When an AI agent initiates a query, hoop.dev first validates the OIDC token, extracts group membership, and maps the request to a least‑privilege BigQuery connection. The gateway then forwards the query to BigQuery using a credential it holds, either a shared service‑account key or a per‑user OAuth token obtained via GCP IAM federation. Because the agent never sees the credential, credential leakage is eliminated.
Before the query reaches BigQuery, hoop.dev evaluates it against configured guardrails. If the statement touches a protected dataset, hoop.dev masks the sensitive fields in the response. If the operation exceeds a predefined cost threshold, hoop.dev routes the request to a human approver and only proceeds after explicit consent. Every interaction, including the original request, the approval decision, and the final result, is recorded by hoop.dev for later audit or replay.
This combination delivers true production access control: the AI agent can only run queries it is explicitly allowed to, sensitive data is never exposed in raw form, costly or destructive operations are gated by a reviewer, and a complete log exists for compliance and forensic analysis.
Key architectural steps
- Deploy the hoop.dev gateway near your BigQuery environment using the Docker Compose quick‑start or a Kubernetes manifest.
- Configure an OIDC provider (Okta, Azure AD, Google Workspace, etc.) so that the gateway can verify the agent’s identity token.
- Register BigQuery as a connection in hoop.dev, supplying either the shared service‑account key or enabling per‑user OAuth via GCP IAM federation.
- Define masking policies for columns that contain PII or proprietary data.
- Set up approval rules for queries that exceed cost or affect critical tables.
- Enable session recording to capture the full request‑response flow.
All of these configurations are expressed in hoop.dev’s declarative resource model. Once in place, any AI‑driven client, whether it uses the standard bq CLI, a Python client library, or a custom LLM‑integrated runtime, connects to the gateway instead of directly to BigQuery. The gateway enforces the policies you defined, without requiring changes to the client code.
For a step‑by‑step walkthrough, see the getting‑started guide. Detailed explanations of masking, approval workflows, and session replay are available in the learn section. The full source and deployment manifests live in the GitHub repository.
FAQ
How does hoop.dev ensure the AI agent never sees the BigQuery credential?
hoop.dev holds the credential inside the gateway process. The agent authenticates only with its OIDC token, and the gateway uses the stored credential to talk to BigQuery on the agent’s behalf.
Can I still use per‑user OAuth tokens with GCP IAM federation?
Yes. When you enable federation, hoop.dev exchanges the agent’s OIDC token for a short‑lived OAuth token that is scoped to the exact BigQuery permissions required for that request.
What audit evidence does hoop.dev provide for compliance audits?
Every session is recorded, including the original request, any approval steps, the masked response, and timestamps. This log can be exported for SOC 2, GDPR, or internal audit reviews.
