When GitHub Copilot writes code that talks to a production data warehouse, the AI agent often runs with a service account that has blanket database access rights. That single credential can surface in logs, be reused by a compromised CI pipeline, and let the model extract sensitive rows without any human oversight. The cost is not just a data leak; it expands the blast radius of a compromised build, forces expensive retroactive remediation, and erodes trust in AI‑assisted development. Organizations that let Copilot query BigQuery directly accept these risks because they lack a gate that can inspect each query, enforce least‑privilege, and record who asked what.
Why database access needs tighter control for AI coding agents
The core problem is a mismatch between identity and authority. The identity that launches a Copilot‑generated script is typically a CI service account, not an individual engineer. That account is granted broad database access so the pipeline can run any migration or analytics job. The setup satisfies the immediate need to keep builds fast, but it leaves three gaps:
- There is no real‑time review of the SQL that the AI proposes.
- Sensitive columns such as personally identifiable information or financial figures are returned to the agent unfiltered.
- Every query runs without a durable audit record tied to a human decision.
These gaps are especially dangerous when the AI model is used to autocomplete queries based on vague prompts. An engineer might unintentionally expose a customer table, and the downstream impact is hard to trace.
What a proper control model looks like
A sound model starts with three pillars:
- Setup: Define who can request a database connection. This is done with OIDC or SAML tokens, group membership, and service‑account roles that encode the intent of the request. The setup decides who the request is and whether it may start, but it does not enforce any guardrails on its own.
- The data path: Place an enforcement point on the actual traffic between the Copilot‑generated client and BigQuery. The gateway is the only place where commands can be inspected, approved, masked, or recorded.
- Enforcement outcomes: Require just‑in‑time approvals before write queries, mask columns that contain regulated data, and log every statement with the originating identity for replay.
Without a gateway in the data path, the setup alone cannot guarantee that a privileged service account does not run an unintended destructive command or exfiltrate a credit‑card column. The enforcement outcomes must be produced where the traffic flows.
Introducing hoop.dev as the enforcement layer
hoop.dev implements the data‑path gateway that satisfies the model above. It sits between the AI‑driven client and BigQuery, proxying the wire‑level protocol. Because hoop.dev controls the connection, it can enforce every policy you need:
- Just‑in‑time approval: When a Copilot script attempts a data‑modifying or schema‑changing operation, hoop.dev pauses the request and routes it to an approver. The approver sees the exact SQL and can grant or deny access in real time.
- Inline data masking: For SELECT statements that reference columns marked as sensitive, hoop.dev rewrites the response on the fly, redacting or tokenizing the values before they reach the AI agent.
- Session recording: Every query, along with the identity token that initiated it, is stored in an audit log that provides a reliable record of activity.
- Command blocking: Policies can be defined to reject dangerous patterns such as commands that drop an entire database or that scan full tables, preventing accidental performance degradation.
All of these outcomes are possible only because hoop.dev is the active component in the data path. If you removed hoop.dev and left the service account to talk directly to BigQuery, none of the approvals, masking, or recordings would happen.