Configuring AI coding agents access to BigQuery with just-in-time access

An AI coding agent running in a CI pipeline needs to run analytical queries against BigQuery, but the organization currently stores a shared service‑account key in the pipeline configuration. This static credential creates a risk: when a contractor leaves, the key often remains, and any compromised build can issue costly queries or exfiltrate sensitive columns. The static credential also prevents per‑user accountability because every query appears to come from the same service account. Teams therefore look for just-in-time access, a model where the agent receives a short‑lived permission only at the moment a query is needed, and where every request is logged, masked, and optionally approved.

Why a data‑path gateway is required

A Layer 7 gateway can inspect the SQL payload, enforce deny‑lists, and trigger human approvals before the query is sent to the data warehouse. Because the gateway sits between the AI worker and BigQuery, it becomes the only place where enforcement can happen. The gateway also holds the service‑account credential in an encrypted store, so the AI process never sees a long‑lived secret.

Introducing hoop.dev as the enforcement layer

hoop.dev provides the data‑path that implements just-in-time access for BigQuery. It validates each OIDC token issued by the organization’s identity provider, extracts group membership, and maps the identity to a policy that defines which datasets the agent may query and for how long. When GCP IAM Federation is enabled, hoop.dev can exchange the OIDC token for a per‑user OAuth credential, eliminating the need for a shared service‑account key altogether. In environments without federation, the static key remains encrypted inside the gateway and never leaves the host, ensuring the AI agent never sees it.

Policy enforcement workflow

Before forwarding a request, hoop.dev inspects the SQL statement at the protocol layer. It can block dangerous commands such as DROP TABLE or ALTER DATABASE, preventing accidental or malicious schema changes. For queries that exceed a predefined cost or access high‑value tables, hoop.dev routes the request to an approval UI, pauses execution, and waits for a designated reviewer to approve. Once approved, hoop.dev injects a short‑lived token into the request, guaranteeing that the privilege expires as soon as the query completes.

Every session is streamed to a secure audit store where it can be replayed later. hoop.dev redacts columns marked as sensitive in the policy, such as SSN or credit‑card numbers, so that raw data never appears in logs or recordings. Masking happens in‑flight, ensuring downstream systems only receive the sanitized result set.

Auditing and compliance benefits

Because each query, approval, and masking decision is recorded, the system provides a detailed audit log that ties a specific AI run to the data it accessed. This evidence satisfies the requirements of standards that demand per‑user activity logs, even though the AI agent itself never holds long‑lived credentials.

Deployment overview

Deploying hoop.dev follows the same quick‑start pattern used for other targets. A Docker‑Compose file launches the gateway and its sidecar agent inside the same network as the BigQuery proxy. The configuration declares the BigQuery connection, the masking policy, and the approval rules. Once the service is up, the AI agents point their client libraries at the local gateway endpoint instead of the raw BigQuery endpoint.

For step‑by‑step instructions, start with the Getting started guide, then explore the feature reference in the Learn section to fine‑tune policies for your datasets.

FAQ

1. Can I use hoop.dev without GCP IAM Federation? Yes. You can rely on a static service‑account key that the gateway stores encrypted; the AI agent never sees the key.
2. How does hoop.dev ensure that masked data cannot be recovered? Masking occurs inside the gateway before any data leaves the network, so the raw values are never written to logs or recordings.
3. What happens if an approval request times out? If an approval does not arrive within the configured window, hoop.dev rejects the query and logs the timeout, allowing you to retry after adjusting the policy.

Scaling the gateway for multiple AI agents is straightforward. Because hoop.dev operates at Layer 7, you can run several instances behind a load balancer, each sharing the same policy store. The audit stream aggregates across instances, giving a unified view of all BigQuery activity regardless of which replica handled the request.

Monitoring integrates with existing observability stacks. The gateway emits structured metrics for connection attempts, approvals, and masking actions, which you can scrape with Prometheus or forward to your SIEM. Correlating these metrics with the session recordings lets you spot anomalous query patterns before they cause damage.

By centralizing control in hoop.dev, you eliminate the need to embed credential rotation logic into each AI worker and gain a single source of truth for who accessed which data and when. This reduction in operational complexity translates directly into faster development cycles and lower risk.

Explore the open‑source repository on GitHub to get the code and contribute.