Production access control for AI agents on BigQuery

The line between a test agent and a production incident is one config value: the project ID. An agent pointed at a staging dataset that suddenly carries a production CLOUDSDK_CORE_PROJECT now runs real queries against real customer data, with the same broad key and no extra scrutiny. Production access control is what should make that crossing deliberate instead of accidental.

Production access control for AI agents on BigQuery is not one feature. It is the set of guarantees you want around any session that touches production data: the agent is authenticated and scoped, risky operations are approved, every query is recorded, and access does not stand around between tasks. The mistake is treating these as separate tools you bolt together.

Why a checklist of separate controls fails

Teams often assemble production access control from parts: an IAM policy here, a logging sink there, a manual approval in a chat channel, a script that rotates a key. Each part has gaps, and the seams between them are where access slips through. The approval that lives in chat is not enforced on the connection. The logging sink does not know which agent ran the query if the key is shared.

What you actually want is one control surface on the path to BigQuery, where identity, scope, approval, recording, and time bound are the same enforcement point, not four systems that have to agree.

What production access control means for an autonomous agent

Production access control is stricter than the access you would hand a developer in a sandbox, because the data is real and the actor runs unattended. For an autonomous agent the bar has three parts. The agent must be a known, authenticated identity, not a shared key. The operations that can cause harm, writes and deletes, must be gated rather than automatic. And every query has to land in a record you can audit, so an unattended actor is never unobserved.

Notice that these are not independent features you could satisfy one at a time. A gated write is meaningless if the identity behind it is a shared key. A recording is weak if it cannot name the agent. Production access control is the property that emerges when identity, scope, approval, and recording hold together at one point, which is the case the architecture below is built around.

One boundary in front of production

hoop.dev proxies the connection to BigQuery, so production access control happens at that single boundary. The agent authenticates through the gateway and, with GCP IAM federation, runs under a per-user short-lived OAuth credential rather than a shared key. The gateway scopes the session to the datasets the task needs, routes risky writes for approval, records every query at the command level, and grants access just in time so it expires with the task.

Because these are properties of one gateway, not four integrations, there are no seams for an agent to slip through. The control is what hoop.dev is, not something you wire together around it.

Steps

1. Run the hoop.dev agent inside the network that reaches your production GCP project; it connects outbound to the gateway.
2. Register the production BigQuery connection, set CLOUDSDK_CORE_PROJECT, and enable GCP IAM federation for per-user OAuth.
3. Scope the connection to production datasets, gate writes for approval, enable recording, and attach a just-in-time policy.
4. Route the agent's bq traffic through the gateway.

# a scoped read runs; a write to prod waits for approval, and all of it is recorded
bq query --use_legacy_sql=false \
  'SELECT order_id, total FROM prod_sales.orders WHERE created > "2026-06-01"'

Verify

Have the agent attempt a write to a production dataset and confirm it pauses for approval. Confirm a scoped read succeeds and appears in the recording under the agent's identity, and that access ends when the session does.

Pitfalls

• Do not let the same broad connection serve staging and production. Separate them so a project-ID swap cannot quietly grant prod access.
• Do not run approvals in a side channel the connection cannot enforce. The gate has to sit on the path.
• Do not leave production grants standing. Pair scope and approval with just-in-time access.

hoop.dev is open source, so you can inspect the whole control surface before it fronts production. Read the getting started guide and see how production controls build on least-privilege access for AI agents on BigQuery. Start at github.com/hoophq/hoop and put a gated, recorded connection in front of a production dataset.

FAQ

What makes access control "production grade" for an agent?

Authenticated identity, scoped access, approval on risky operations, recording of every query, and time-bounded grants, all enforced on the connection. hoop.dev provides these as one gateway rather than separate tools.

Can I require approval before an agent writes to production?

Yes. hoop.dev can route risky operations like writes for human approval before they reach BigQuery, so a production write is a deliberate, recorded decision rather than an automatic one.