Least-privilege access for AI agents on BigQuery

The reporting agent was set up to read one dataset. A year later it holds roles/bigquery.dataEditor across the project, because every time it hit a permission error someone widened the grant to get unblocked. Nobody narrowed it back. This is how least-privilege erodes: not through one bad decision but through a hundred small expansions that never reverse.

Least-privilege access for AI agents on BigQuery means an agent has exactly the rights its task needs and nothing more: the datasets it reads, the operations it performs, the window it runs in. The hard part is not setting it once. It is enforcing it where the agent cannot widen it on its own.

Scope has more than one dimension

Least privilege on BigQuery is not a single dial. It spans which datasets and tables an agent can touch, which operations it can run (read, write, delete), and how long it can do so. An agent that only summarizes data should never hold write or delete rights, and a tightly scoped read grant that lives forever is still too much privilege along the time axis.

Treating scope as one dimension is how over-grants creep in. You have to constrain all of them and keep them constrained.

Least-privilege access is a practice, not a one-time setting

The reason least privilege decays is that it is usually treated as a setup step. Someone scopes the agent on day one, the config is correct, and then reality applies pressure. A new report needs another table. A migration needs temporary write. Each request is reasonable, each widening is small, and none of them get reversed, because reversing a grant has no deadline and no owner.

Keeping least-privilege access tight means the default has to fight back. Grants should be narrow unless something widens them deliberately, and widenings should not be permanent by accident. That only works if the enforcement point makes the narrow path the easy one and the broad path the exception that expires, rather than relying on a human to clean up later.

Enforcement has to sit off the agent

If the agent enforces its own limits, a compromised agent removes them. Least-privilege access is only real when something on the connection path to BigQuery decides what each session may do and refuses the rest, regardless of what the agent asks for.

hoop.dev proxies the connection to BigQuery and applies that decision at the boundary. It scopes a session to the access the task needs, can route risky operations like writes for approval, and grants the session just in time so the privilege does not stand around between tasks. With GCP IAM federation, the brokered OAuth credential is itself scoped and short-lived.

Steps

1. Run the hoop.dev agent near your GCP project; it dials out to the gateway.
2. Register a BigQuery connection, set CLOUDSDK_CORE_PROJECT, and enable GCP IAM federation for per-user OAuth.
3. Scope the connection to the datasets the agent needs and gate write or delete operations for approval.
4. Route the agent's bq traffic through the gateway.

# a read the agent is scoped for returns; an out-of-scope write is refused
bq query --use_legacy_sql=false \
  'SELECT region, COUNT(*) FROM analytics.events GROUP BY region'

Verify

Have the agent attempt an operation outside its scope, such as a write to a dataset it should only read, and confirm the gateway refuses it. Then confirm its legitimate read still works, so you know the scope is tight but functional.

Pitfalls

• Do not widen a grant to clear a single error and forget to narrow it; that is how editor creep happens.
• Do not grant write or delete to an agent whose job is read-only.
• Do not ignore the time dimension. Pair narrow scope with just-in-time grants so privilege does not persist idle.

hoop.dev is open source, so you can audit where scope is enforced before relying on it. Read the getting started guide and see how least privilege pairs with just-in-time access for AI agents on BigQuery. Start at github.com/hoophq/hoop and put a scoped, write-gated connection in front of a test agent.

FAQ

Is least-privilege access just narrow IAM roles?

IAM roles set the floor, but they tend to drift wider over time and they do not bound duration. hoop.dev adds session-level scope, write approvals, and just-in-time grants on the connection, so privilege stays narrow in practice.

Can the agent escalate its own privileges?

No. The gateway decides what a session may do and refuses the rest. The agent cannot widen its scope, because enforcement sits off the agent on the connection path.