When an AI coding agent runs queries against a data warehouse, the organization loses visibility into who asked what, when, and why, and it forfeits essential audit logging. Untracked queries can inflate cloud bills, expose sensitive columns, and make it impossible to prove compliance during an audit. The hidden cost is not just dollars; it is the erosion of trust in automated tooling that should accelerate development, not create blind spots.
Most teams hand a shared Google service‑account key to the agent and let it talk directly to BigQuery. The key grants broad read/write privileges, and the agent uses it without any mediation. Because the connection bypasses any enforcement layer, there is no record of individual statements, no way to mask personally identifiable information, and no gate to pause a risky operation for human review.
What many organizations try to add on top of that raw connection is a logging sidecar or a custom wrapper that writes query metadata to a separate table. Those approaches still rely on the agent’s own process to emit logs, so a compromised or buggy agent can simply stop reporting. The missing piece is a control point that sits between identity and the BigQuery endpoint, guaranteeing that every request is observed, recorded, and, if needed, filtered before it reaches the database.
Why audit logging matters for AI coding agents
Audit logging is the backbone of any data‑centric governance program. It provides an immutable trail that can be queried to answer questions such as:
- Which user or service account triggered a particular query?
- What data elements were returned, and were any protected columns exposed?
- Did the query comply with internal policies or regulatory requirements?
For AI agents that generate code on the fly, the risk profile is higher. The agent may produce ad‑hoc queries that were never reviewed, and the speed of execution can amplify the impact of a mistake. Without reliable audit logging, an organization cannot detect misuse, cannot attribute responsibility, and cannot demonstrate compliance to auditors.
The missing control in a direct BigQuery connection
In the current model, the setup, identity federation, OIDC tokens, or a static service‑account key, determines who is allowed to start a session. That setup is essential, but it does not enforce anything once the session is active. The request travels straight from the agent to BigQuery, bypassing any point where a policy could be evaluated. Consequently, audit logging, inline masking, and just‑in‑time approvals are unavailable.
Because the enforcement outcomes are absent, the organization cannot rely on the logs produced by the agent itself. If the agent is compromised, the logs disappear along with the malicious activity. The gap is the lack of a data‑path component that can see and act on every request.
Placing hoop.dev in the data path
hoop.dev is a Layer 7 gateway that lives between the identity provider and the BigQuery endpoint. The data path is the only place where hoop.dev can inspect the wire‑protocol traffic, apply policies, and generate evidence. When an AI coding agent authenticates via OIDC or SAML, the gateway validates the token, extracts group membership, and then forwards the request to BigQuery on behalf of the agent. Because the connection is proxied, the agent never sees the underlying credential.
All enforcement outcomes, audit logging, inline masking of sensitive fields, just‑in‑time approval workflows, and session recording, are produced by hoop.dev because it is the sole observer of the traffic. If hoop.dev were removed, none of those outcomes would exist, even though the identity setup remains unchanged.
What hoop.dev records for every AI session
- Full query log: Each statement issued by the agent, together with the authenticated identity, timestamp, and execution status, is stored in an immutable audit trail.
- Response masking: When a query returns columns marked as sensitive, hoop.dev can redact or replace those values in real time, ensuring that downstream logs never contain raw PII.
- Just‑in‑time approval: If a query matches a high‑risk pattern (for example, a full table scan on a regulated dataset), hoop.dev can pause the request and route it to an approver before execution.
- Session recording: The entire request/response stream is captured so that security teams can replay the interaction for forensic analysis.
Because these capabilities are enforced at the gateway, they are independent of the AI agent’s code. Even a compromised agent cannot bypass the audit log or suppress masking, because the traffic never reaches BigQuery without passing through hoop.dev.
Getting started
The first step is to deploy the gateway in the same network segment as the BigQuery service account. The official getting started guide walks through a Docker Compose deployment, OIDC configuration, and the registration of a BigQuery connection. Once the connection is defined, the AI coding agent simply points its client library at the hoop.dev endpoint instead of the native BigQuery endpoint.
After deployment, the learn section provides deeper coverage of audit‑logging policies, masking rules, and approval workflows. All configuration is expressed as policy objects that the gateway evaluates for each request.
Explore the open‑source repository on GitHub to view the code, contribute improvements, or spin up a local test environment: github.com/hoophq/hoop.
FAQ
Does hoop.dev replace the need for service‑account key rotation?
No. Service‑account keys remain the credential that the gateway uses to talk to BigQuery. hoop.dev adds a layer of visibility and control on top of that credential, but key management best practices still apply.
Yes. Any client that authenticates through the gateway, whether a human user, a CI pipeline, or an AI agent, will have its traffic recorded and subject to the same policies.
Is the audit log tamper‑proof?
The audit trail is written by hoop.dev after each request and stored in an immutable audit trail. Because hoop.dev is the only component that creates these entries, the record cannot be altered without detection.
