If an AI agent's BigQuery credential leaked right now, how long would the attacker have? With a standing grant the honest answer is "until a human notices," which on a busy team can be weeks. Just-in-time access changes the answer to "until the current task ends," and that single change does more for your blast radius than any amount of monitoring.
Just-in-time access for AI agents on BigQuery means an agent holds no permanent rights to your datasets. Access is granted for the task it is running, scoped to that task, and revoked when the task completes. The window in which a compromise matters shrinks from open-ended to one session.
Blast radius is a function of time, not just scope
Teams spend a lot of effort on scope, which dataset, which tables, and far less on duration. Yet a tightly scoped grant that lives forever is still a forever-exploitable asset. Multiply by the number of agents you run and the standing surface gets large fast.
Cutting duration attacks the part of blast radius that scope cannot. An agent that can read one dataset for thirty seconds is a far smaller liability than one that can read it indefinitely.
Just-in-time access turns a credential leak into a non-event
Think about the failure you are actually defending against. An agent's environment variable leaks into a log. A container image with a baked-in token ends up in a public registry. A prompt-injection nudges an agent into dumping its own credentials. In every case the damage is bounded by one thing: how long that credential keeps working.
With a standing grant, the leaked credential works until a human catches it. With just-in-time access, it works until the current session ends, which might be seconds. The leak still happened, but the window in which it matters has collapsed to almost nothing. That is the security property worth building toward, and it comes from time, not from hoping the credential never leaks.
The expiry has to be enforced off the agent
A timer the agent keeps for itself is worthless against a compromised agent. The grant must be issued and revoked by a system on the connection path to BigQuery, so it can refuse the next query the instant the window closes, regardless of what the agent believes.
hoop.dev sits on that path. It proxies the connection to BigQuery and grants access just in time for a session, then ends it. With GCP IAM federation enabled, the OAuth credential the gateway brokers for the session is short-lived too, so even a captured token expires on its own.
Steps
- Place the hoop.dev agent in the network that reaches your GCP project; it dials out to the gateway with nothing exposed inbound.
- Register a BigQuery connection, set
CLOUDSDK_CORE_PROJECT, and enable GCP IAM federation so sessions use per-user OAuth. - Attach a just-in-time policy so a request opens a scoped, time-limited session.
- Direct the agent's
bq calls through the gateway endpoint.
# the grant exists only for this session
bq query --use_legacy_sql=false \
'SELECT campaign, clicks FROM marketing.events LIMIT 200'
Verify
Open a session, run a query, wait for the window to lapse, and run again. The second attempt should be denied at the gateway, and the session log should show the open, the queries, and the close under the agent's identity.
Pitfalls
- Avoid generous default windows that quietly turn just-in-time into always-on.
- Avoid unbounded re-request loops; pair them with approval or rate limits so an agent cannot self-renew indefinitely.
- Avoid treating duration as a substitute for scope. Keep the dataset grant narrow as well.
hoop.dev is open source, so the grant-and-revoke logic is yours to inspect. Read the getting started guide and see how time-bounded access combines with least-privilege access for AI agents on BigQuery. Start at github.com/hoophq/hoop and put a time-limited connection in front of a test agent.
FAQ
What happens to in-flight queries when a window expires?
New statements are refused once the window closes. Just-in-time access governs whether the session can keep issuing work, so an agent cannot keep querying past its grant.
Can an agent extend its own access?
Not unilaterally. Renewal goes through the same policy, which is where you place approval or rate limits so just-in-time access does not collapse into standing access.
