How can you let a ChatGPT‑driven coding agent run queries against a production BigQuery warehouse while maintaining strict production access controls, without exposing credentials or losing visibility?
Today many teams hand a service account key to an AI worker and point it straight at the data lake. The key lives in the container image, the CI pipeline, or even a shared secrets manager. The agent can issue any SELECT, UPDATE or DELETE it wants, and there is no record of who asked for what, no way to block a dangerous DDL command, and no protection for personally identifiable information that might appear in query results.
What you really need is a production access control that still lets the AI write code, but forces every request to pass through a gate where identity, intent and data protection are verified. The gap remains: even if you federate the AI identity through OIDC, the request still travels directly to BigQuery. There is no inline approval step, no masking of sensitive columns, and no immutable audit trail of the session.
To close that gap you must place a Layer 7 gateway between the AI agent and the database. The gateway becomes the only place where policy can be enforced, and it can provide just‑in‑time (JIT) approval, real‑time column masking, command‑level blocking, and full session recording. The rest of the architecture, identity providers, service‑account provisioning, and network placement, remains unchanged.
Setup: identity and least‑privilege provisioning
The first step is to define a non‑human identity for the ChatGPT coding agent. Most organizations use an OIDC provider such as Okta, Azure AD or Google Workspace to issue short‑lived tokens. The token carries the agent’s group membership (for example, ai‑coding‑agents) and any custom claims that describe the intended environment (production vs. development).
Because the gateway never trusts a static credential, you can assign the service account only the BigQuery roles required for the specific workload, such as bigquery.dataViewer on the target dataset. The identity provider decides whether the token is valid; it does not enforce data‑plane policies. This separation ensures that a compromised token cannot be reused to bypass the gate.
The data path: why the gateway is the only enforcement point
When the AI agent initiates a query, the request is routed to the gateway instead of directly to BigQuery. The gateway terminates the protocol, inspects the SQL payload, and applies the policies you have defined. Because all traffic flows through this single point, you can guarantee that every command is subject to the same checks.
At this stage, hoop.dev becomes the enforcement engine. It reads the identity token, matches the agent’s group to a policy, and decides whether the request can proceed, needs human approval, or must be rejected outright. The gateway also knows the target resource (the BigQuery project and dataset) and can enforce resource‑level scoping.
Enforcement outcomes delivered by hoop.dev
- Just‑in‑time approval: If a query touches a production table flagged as high‑risk, hoop.dev pauses execution and creates an approval request. An authorized engineer can approve or deny the request from a web UI before any data is read.
- Inline data masking: When the result set contains columns marked as sensitive (PII, credit‑card numbers, etc.), hoop.dev redacts or tokenizes those fields on the fly, ensuring the AI never sees raw values.
- Command‑level blocking: Dangerous statements such as DROP TABLE or DELETE FROM … WHERE true are identified and blocked before they reach BigQuery.
- Session recording and replay: Every query, response and approval decision is captured. The recorded session can be replayed for forensic analysis or compliance audits.
All of these outcomes exist only because hoop.dev sits in the data path. If you removed the gateway, the AI would again have unfettered, unrecorded access.