AI coding agents that generate SQL on behalf of developers often run with a single, long‑lived service‑account key, which defeats just-in-time access principles. That key typically has read‑write privileges across an entire data warehouse, so a stray query can scan petabytes, incur massive cloud bills, or leak personally identifiable information. When the credential is shared, there is no way to tell which agent issued a particular query, and no audit trail to satisfy compliance reviewers.
The natural reaction is to grant the agent a dedicated identity and to require approval before expensive operations run. Even with a per‑agent identity, the request still travels directly to BigQuery. The data path remains unmediated, so the platform cannot see the exact query, cannot mask sensitive columns, and cannot block commands that exceed budget thresholds. In short, the prerequisite of just-in-time access is present, but the enforcement surface is missing.
Why just-in-time access matters for AI agents
Just-in-time access limits exposure by issuing credentials only for the duration of a specific request. For AI‑driven workloads, this means the agent receives a token that is valid for a single query or a short session, reducing the blast radius of a compromised secret. The approach also aligns cost control with usage: expensive analytics jobs must be explicitly approved before the token is minted. However, without a gateway that inspects traffic, the organization cannot enforce column‑level masking, cannot record the exact statement that ran, and cannot intervene when a query threatens data privacy or budget limits.
How hoop.dev enforces just-in-time access on BigQuery
hoop.dev acts as a Layer 7 gateway positioned between the AI agent and the BigQuery service. The agent authenticates to hoop.dev using an OIDC token that reflects its short‑lived identity. hoop.dev validates the token, extracts group membership, and then decides whether to issue a temporary credential for the requested operation. The actual BigQuery credential is stored inside the gateway; the agent never sees it.
Once the request is authorized, hoop.dev proxies the query to BigQuery. At this point the gateway can apply several enforcement outcomes:
- It records the full query and response for replay, giving auditors a complete audit trail.
- It masks sensitive fields in the response according to policy, preventing downstream leakage.
- It blocks statements that match a deny list, such as full‑table scans on high‑cost tables.
- It routes high‑cost or high‑risk queries to a human approver before the temporary credential is handed off.
All of these controls happen inside the data path, so they remain effective even if the AI agent is compromised. Because hoop.dev is the only component that sees the live query, the organization can enforce fine‑grained policies that would be impossible with a static service‑account key.
Setting up the gateway for BigQuery
The practical steps are documented in the getting‑started guide. In brief, you deploy the hoop.dev container, configure a BigQuery connection with the appropriate service‑account credential, and enable the just‑in‑time access flow in the policy UI. The gateway then automatically handles token exchange, approval routing, and session recording for every AI‑generated query.
Benefits beyond compliance
Because hoop.dev records each session, security teams can replay suspicious activity to understand intent. Inline masking ensures that downstream analytics pipelines never receive raw personally identifiable data, reducing the need for downstream sanitization. The just‑in‑time model also reduces the surface area for credential leakage, because the long‑lived key never leaves the gateway.
FAQ
What does just-in-time access mean for a BigQuery query? It means the AI agent receives a short‑lived token that is valid only for the specific query it is about to run. Once the query completes, the token expires and cannot be reused.
Does hoop.dev store my BigQuery credentials? The credentials are kept inside the gateway process and are never exposed to the calling agent. This isolation prevents accidental leakage.
Can I still use existing BI tools with hoop.dev in place? Yes. Because hoop.dev proxies standard BigQuery traffic, any client that speaks the BigQuery protocol (including BI tools) can connect through the gateway without code changes.
For a deeper dive into policy configuration and masking options, see the learn section. When you’re ready to try it yourself, explore the open‑source repository and contribute at github.com/hoophq/hoop.
