All posts

AI coding agents: what they mean for your least privilege (on BigQuery)

When an AI coding agent silently writes queries against your data warehouse, a single over‑privileged credential can expose millions of rows in seconds. Most teams treat the agent like any other service account: they create a Google service account, grant it the bigquery.admin role, and hand the JSON key to the model. The agent then runs unrestricted SELECT, INSERT, or even DROP statements directly against BigQuery, and the organization loses visibility into which queries were issued, by whom,

Free White Paper

Least Privilege Principle + AI Agent Security: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

When an AI coding agent silently writes queries against your data warehouse, a single over‑privileged credential can expose millions of rows in seconds.

Most teams treat the agent like any other service account: they create a Google service account, grant it the bigquery.admin role, and hand the JSON key to the model. The agent then runs unrestricted SELECT, INSERT, or even DROP statements directly against BigQuery, and the organization loses visibility into which queries were issued, by whom, and why.

Why least privilege matters for AI coding agents

Least privilege is the practice of giving a principal only the permissions it needs to perform its intended function. For an AI coding assistant, that function is usually to generate SELECT statements that read data for analysis or reporting. Granting bigquery.admin or owner rights violates the principle because the agent can also create tables, alter schemas, or delete datasets.

When the principle is ignored, the blast radius of a mistake or a malicious prompt expands dramatically. A single errant prompt that asks the model to “show all user records” can retrieve personal data that should be restricted, and the organization may be unable to prove who authorized the request.

What least privilege alone doesn’t solve

Even if you tighten the service account to bigquery.dataViewer or a custom role that limits column access, the request still travels straight from the agent to BigQuery. The data path remains unobserved, so you lose three critical controls:

  • Audit: there is no guaranteed record of which query was executed, when, and under which identity.
  • Masking: sensitive columns such as SSNs or credit‑card numbers are returned in clear text to the agent.
  • Approval: high‑risk operations like exporting data or creating temporary tables bypass any human review.

These gaps exist because the enforcement point is missing. The setup – OIDC authentication, service‑account provisioning, and role assignment – tells the system who the request is, but it does not inspect the traffic flowing to BigQuery.

How hoop.dev enforces least privilege on the data path

hoop.dev inserts a Layer 7 gateway between the AI agent and BigQuery. The gateway becomes the only place where traffic can be examined, altered, or blocked.

Continue reading? Get the full guide.

Least Privilege Principle + AI Agent Security: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

When the agent initiates a query, hoop.dev validates the OIDC token, maps the user’s groups to a policy, and then checks the SQL statement against that policy. If the statement attempts to access a column marked as sensitive, hoop.dev masks the value before it reaches the agent. If the statement tries to create a new table or export data, hoop.dev pauses the request and routes it to a just‑in‑time approval workflow.

Every session that passes through the gateway is recorded by hoop.dev, providing a replayable audit trail that shows the exact query, the identity that issued it, and the outcome. Because the gateway holds the BigQuery credential, the agent never sees the key, eliminating credential leakage.

In practice, this means you can grant the AI coding agent a broad service‑account role, but the gateway enforces least‑privilege intent at runtime: only SELECTs on approved datasets are allowed, sensitive fields are redacted, and any operation that could change data requires explicit human sign‑off.

Getting started with hoop.dev and BigQuery

Deploy the hoop.dev gateway using the official Docker Compose quick‑start, configure a BigQuery connection with the service‑account key, and enable the built‑in masking and approval policies. The getting‑started guide walks you through the steps, and the learn section explains how to tailor policies for AI agents.

FAQ

Does hoop.dev replace the need for custom IAM roles?
No. You still define the minimal role for the service account. hoop.dev adds runtime enforcement, audit, and masking on top of those static permissions.

Can hoop.dev mask data without changing the underlying query?
Yes. The gateway intercepts the response from BigQuery and replaces values in configured columns before they reach the agent.

Is the solution compatible with other AI models?
The gateway works with any client that speaks the BigQuery protocol, so you can route requests from LLM‑based assistants, custom code, or third‑party tools through hoop.dev.

Ready to tighten least‑privilege controls for AI coding agents? Explore the open‑source repository on GitHub and start building a secure data path today.

Open source

Save the open-source gateway for agent data access

Hoop is MIT-licensed infrastructure for controlling how AI agents reach production data. Star hoophq/hoop so you can inspect it, deploy it, or share it when your team starts governing agent access.

Star and save the repo →More posts