When an AI coding assistant can perform unrestricted database access against a data warehouse, the organization pays for wasted compute, risks accidental data leakage, and loses any evidence of who asked what. Those hidden costs appear long after the model has generated a single line of code.
Devin, a large‑language‑model‑driven coding agent, often receives a shared service account that has full read‑write rights on a BigQuery project. The agent can spin up dozens of ad‑hoc queries, join tables that contain personally identifiable information, and export results without any human oversight. Because the connection bypasses a gate that records intent, the engineering team has no audit trail, no way to mask sensitive columns, and no ability to stop a costly query before it runs.
Why the current state is unsafe
In many organizations the default pattern is to embed a static credential in the CI/CD pipeline or in the agent’s runtime environment. That credential grants broad database access and lives forever unless someone remembers to rotate it. The result is a "wild west" of database access where anyone, or any automated process, can issue any SQL command. The cost is measurable in cloud spend, the risk is measurable in data exposure, and the compliance gap is measurable in missing logs.
What a proper control model must add
A realistic model starts with a strong identity layer: each AI agent authenticates through OIDC, receives a short‑lived token, and is assigned to a role that describes the kind of queries it may run. That setup defines *who* is making the request, but on its own it does not stop the request from reaching BigQuery directly. The request still travels straight to the data warehouse, carries no per‑query approval, no inline masking, and no session recording. In other words, the identity check is necessary but not sufficient for secure database access.
How hoop.dev enforces database access for AI agents
hoop.dev sits in the data path between Devin and BigQuery. It acts as an identity‑aware proxy that terminates the client connection, inspects each SQL statement, and then forwards it only after applying the configured policies.
- Just‑in‑time approval: When Devin attempts a query that exceeds a cost threshold or touches a sensitive table, hoop.dev pauses the request and routes it to a human approver. The query proceeds only after explicit consent.
- Inline data masking: Responses that contain columns marked as sensitive are filtered in real time. The masking happens inside hoop.dev, so the AI agent never sees raw values.
- Command‑level audit: hoop.dev records every SQL statement, the identity that issued it, and the outcome. The log is stored outside the agent’s environment, providing evidence for downstream audits.
- Session recording and replay: Each interactive session is captured as a replayable stream, allowing security reviewers to reconstruct exactly what Devin did during a troubleshooting session.
All of these outcomes exist because hoop.dev is the only component placed in the gateway layer. The upstream identity system merely tells hoop.dev who Devin is; hoop.dev decides whether the request may proceed, how it is transformed, and what evidence to keep. Learn more about policy configuration and how the enforcement engine can be tuned to your risk appetite.
Getting started with secure database access for Devin
To adopt this model, begin by deploying the hoop.dev gateway in the same network segment as your BigQuery project. Connect the gateway to your OIDC provider so that Devin can obtain short‑lived tokens. Register the BigQuery connection in the gateway, upload the service account credential that the gateway will use, and define policies that require approval for expensive queries and mask columns that contain PII.
Detailed step‑by‑step instructions are available in the getting‑started guide. The open‑source repository contains the Docker Compose file and Helm charts you need to spin up the gateway quickly.
FAQ
Does hoop.dev store my BigQuery credentials?
Yes. The gateway holds the credential internally and never exposes it to the AI agent or to end users. This prevents credential leakage at the client side.
Can I still run automated jobs through hoop.dev?
Automated workloads can be given their own OIDC client and scoped role. hoop.dev will apply the same policy engine, so you retain audit and masking even for non‑interactive scripts.
What happens if an approval is not granted?
hoop.dev rejects the query and returns a clear error to the caller. No data is sent to BigQuery, and the attempt is logged for later review.
Ready to protect your AI‑driven data pipelines? Explore the hoop.dev source code and start the deployment today.
