Why AI coding agents need guardrails
When an AI coding agent like Devin can run unrestricted queries against BigQuery, a single mis‑prompt can expose customer PII, inflate cloud bills, or corrupt production tables. Teams often hand the agent a static service‑account key and let it connect directly, trusting that the model will stay well behaved. In practice the model can be steered, the prompt can be malformed, and you lose visibility into which rows were read or which tables were altered. Regulatory fines, lost customer trust, and wasted compute dollars measure the cost of a data leak or a runaway query.
Most organizations today address this by placing the credential in a secret manager and granting the service account broad, standing permissions. The agent authenticates, reaches BigQuery, and executes whatever it wants. The system does not keep an audit trail, does not mask sensitive fields, and no human sees the request before it runs. The result is a blind spot: you know the agent exists, but you cannot prove what it did or stop it from doing something dangerous.
What the pre‑condition looks like
What we really need is a way to keep the convenient "just‑ask‑the‑model" workflow while adding guardrails that enforce policy at the moment of access. The ideal state would let Devin request a query, have hoop.dev inspect the request, and only allow it to proceed if it complies with data‑privacy rules, cost limits, and change‑control policies. At the same time, the request must still travel straight to BigQuery, because the data resides there and the agent needs low‑latency access.
In this intermediate state the authentication and identity layer (service accounts, OIDC tokens) decides who Devin is, but the request reaches the database without any inline check. The missing piece is a data‑path component that can observe, mask, approve, and record each query before it hits BigQuery.
How hoop.dev provides guardrails for Devin
hoop.dev sits exactly at that missing data‑path. It acts as an identity‑aware proxy that terminates the client connection, inspects the BigQuery wire protocol, and then forwards the request to the target only after applying the configured policies. Because the gateway holds the credential, the agent never sees the secret, satisfying the setup requirement while keeping the credential out of the agent’s runtime.
When Devin initiates a query, hoop.dev performs three enforcement outcomes:
- Inline masking: hoop.dev redacts response fields that match a PII pattern before they ever leave the gateway, ensuring downstream logs or consumers never see raw personal data.
- Just‑in‑time approval: hoop.dev triggers a workflow that asks a human approver to sign off on queries that touch high‑risk tables, preventing accidental writes or large‑scale scans.
- Session recording: hoop.dev logs every request and response with the identity that originated it, giving auditors a replayable audit trail for compliance and incident response.
hoop.dev enforces all of these controls because it is the only point where the traffic passes. The underlying identity system (OIDC or SAML) tells hoop.dev who Devin is, but the gateway is the authoritative place where policy is evaluated.
Implementation overview
Deploy the gateway near your BigQuery network, Docker Compose is the quickest way to get started. Register the BigQuery connection in the gateway, attach the service‑account credential, and define the guardrail policies in the UI or declarative config. Once the gateway is running, point Devin’s client library at the hoop.dev endpoint instead of the raw BigQuery endpoint. From that point forward every query flows through the gateway, where the gateway applies the guardrails.
For a step‑by‑step walkthrough, see the getting started guide. The feature documentation contains details on masking rules, approval workflows, and audit‑log retention. You can find the full source code and contribution guidelines in the open‑source repository on GitHub.
FAQ
Does hoop.dev change the latency of BigQuery queries?
Because hoop.dev operates at Layer 7 and forwards the request after policy checks, the added latency is limited to the time needed for inspection and any approval step. For queries that do not trigger additional workflows, the overhead is typically a few milliseconds.
Can I still use existing service‑account keys for other workloads?
Yes. hoop.dev only intercepts traffic that you explicitly configure to route through it. Other workloads can continue to use the same credential directly, but they will not benefit from the guardrails.
What happens to data that is masked?
hoop.dev replaces masked fields with a placeholder before the response leaves the gateway. The original values remain in BigQuery storage and are visible only to authorized users who query the data directly, preserving data integrity while protecting downstream consumers.
