Putting access controls around Claude: database access for AI coding agents (on BigQuery)

Why unrestricted AI agents are a hidden cost

Uncontrolled database access by an AI coding assistant like Claude can quickly become a hidden cost. When teams hand Claude a static service‑account key, the agent can run any query against BigQuery, bypassing human oversight, inflating cloud bills, and exposing sensitive rows. The immediate benefit is speed, but the lack of a central enforcement point means you lose visibility, cannot mask PII, and cannot require approval before costly operations run.

The missing piece in current AI‑driven database workflows

The core problem is that identity and least‑privilege apply only at the token level, while enforcement lives on the target side. A service account may be scoped to a project, but every query still reaches BigQuery unmediated. This leaves three critical gaps:

• Security teams lack a real‑time audit of which user or agent issued each SQL statement.
• BigQuery returns sensitive fields such as SSNs or credit‑card numbers in clear text to the agent.
• High‑cost operations, large scans, export jobs, or schema changes, run without a human checkpoint.

These gaps persist even after you configure OIDC authentication for Claude, because the request still flows straight to the data warehouse.

Introducing a gateway that sits in the data path

hoop.dev provides the missing enforcement layer. It is a Layer 7 gateway that proxies every BigQuery connection made by Claude. The gateway sits between the AI agent and the database, so all traffic must pass through it before reaching the target. Because hoop.dev is the only point where the protocol is inspected, it can apply the following controls:

• Session recording: hoop.dev records each query and its result set, creating a replay log for later review.
• Inline masking: hoop.dev redacts sensitive columns on the fly, ensuring Claude never sees raw PII.
• Just‑in‑time approval: hoop.dev holds queries that match a risk profile for a human reviewer before execution.
• Command blocking: hoop.dev rejects dangerous statements outright based on policy rules.

All of these outcomes exist because hoop.dev sits in the data path. The identity setup that authenticates Claude (OIDC, SAML, or a service‑account token) decides who is making the request, but without hoop.dev the request would reach BigQuery directly and none of the above protections would be possible.

How the architecture works for Claude and BigQuery

First, you deploy the hoop.dev gateway inside the same network segment as the BigQuery endpoint. You can start with Docker Compose for a quick trial or use Kubernetes for a production deployment. The gateway runs an agent that holds the credential needed to talk to BigQuery; Claude never sees this secret.

Second, you register a BigQuery connection in hoop.dev, specifying the project, dataset, and the credential the gateway should use. The registration also includes policy definitions that describe which queries require approval, which columns must be masked, and which users or agents are allowed to run them.

Third, when Claude needs to run a query, it authenticates to hoop.dev using its OIDC token. hoop.dev verifies the token, extracts the agent’s identity, and then forwards the request through the gateway. The gateway inspects the SQL, applies masking, checks the approval policy, and either executes the query against BigQuery or pauses for a reviewer. hoop.dev logs the full session for audit.

Benefits for security and compliance programs

Because hoop.dev captures every interaction, security teams gain a complete audit trail for database access. Auditors can see who asked for what data, when, and whether a human approved the operation. Inline masking reduces the risk of leaking PII to AI agents, satisfying privacy requirements without sacrificing the usefulness of the assistant. Just‑in‑time approvals keep cost‑heavy operations under control, preventing accidental large‑scale scans that could blow up a cloud bill.

A single, open‑source component delivers all of these capabilities, eliminating the need to stitch together separate logging, masking, and approval tools.

Getting started

To try this pattern, follow the getting‑started guide for hoop.dev. The documentation walks you through deploying the gateway, registering a BigQuery connection, and defining basic policies for masking and approvals. For deeper details on policy language and audit features, explore the learn section. The source code and contribution guidelines are available on GitHub.

FAQ

Q: Does hoop.dev replace the need for service‑account keys?
A: No. hoop.dev still uses a credential to talk to BigQuery, but that secret lives only in the gateway. Agents never receive the key, reducing credential sprawl.

Q: Can I use hoop.dev with other AI models besides Claude?
A: Yes. The gateway is model‑agnostic; any client that can present an OIDC token can be proxied, so the same pattern works for other coding assistants.

Q: How does hoop.dev ensure low latency for interactive queries?
A: The gateway inspects traffic at the protocol layer and only adds processing for policies that match. Simple SELECTs that do not trigger masking or approval pass through with minimal overhead.

Explore the source, contribute improvements, and see the full implementation on GitHub.