Static credentials give autonomous agents unrestricted, invisible power over your data warehouse, and they completely bypass just-in-time access controls.
Today many teams hand a service‑account key to a bot, a CI job, or an AI‑driven analyst and let it run queries against BigQuery whenever it wants. The key never changes, the bot never authenticates as a distinct human, and every query slips by without a trace. If the agent is compromised, an attacker inherits the same unlimited read/write rights, can exfiltrate sensitive columns, and can run destructive DDL without any approval workflow.
That baseline is dangerous, but it is also common. The first step toward a safer model is to give each agent a per‑user identity – for example, using GCP IAM federation so the bot receives an OAuth token tied to a service account that reflects its purpose. This change stops the blanket key, but the request still travels straight to BigQuery. The token proves who the caller is, yet there is still no gate that can inspect the query, mask protected fields, or require a human sign‑off before a risky operation runs.
Why just-in-time access matters for BigQuery agents
Just-in-time access means granting the minimum privilege for the exact moment a query is needed, then revoking it automatically. For autonomous agents this model reduces blast radius: a compromised agent can only act while a request is approved, and only on the data it is explicitly allowed to see. It also satisfies audit requirements because every request is tied to an identity and a timestamp, and any privileged operation can be forced through an approval workflow.
Without a dedicated gateway, you would need to stitch together separate pieces – IAM policies, external logging, custom query wrappers – and each piece would run outside the data path. That architecture leaves gaps where an agent could bypass a guardrail, and it makes it hard to guarantee that masking, approval, and recording happen for every query.
Implementing just-in-time access with hoop.dev
hoop.dev provides the Layer 7 gateway that sits directly between the agent and BigQuery. The architecture follows three clear layers.
Setup: identity and purpose
First, configure an OIDC or SAML identity provider (Okta, Azure AD, Google Workspace, etc.) so that each autonomous agent receives a short‑lived token. When the token is presented to hoop.dev, the gateway extracts the user or service identity and any group membership that defines the agent’s purpose. This step decides who the request is, but it does not enforce any policy on its own.
The data path: hoop.dev as the only enforcement point
All BigQuery traffic is forced through the hoop.dev gateway. The agent never contacts BigQuery directly; instead it talks to the gateway using the standard bq client or any compatible library. The gateway terminates the protocol, inspects each SQL statement, and then forwards it to BigQuery on behalf of the agent. Because the gateway is the sole path, it is the only place where enforcement can be applied.
Enforcement outcomes: audit, masking, approval, and revocation
- Session recording: hoop.dev retains each session log, including the query, the identity that issued it, and the result set, so it can be reviewed later for forensic analysis.
- Inline data masking: before a result set reaches the agent, hoop.dev can redact or hash columns that are marked as sensitive, ensuring that even a compromised agent never sees raw PII.
- Just-in-time approval: if a query matches a policy that requires human sign‑off – for example, a DROP TABLE or a cross‑project export – the gateway pauses the request and routes it to an approver. Only after explicit approval does the query continue.
- Command blocking: dangerous statements can be rejected outright based on policy, preventing accidental or malicious data loss.
All of these outcomes are possible only because hoop.dev sits in the data path. If you removed the gateway, the IAM token would still identify the agent, but you would lose the real‑time inspection, masking, and approval that protect your warehouse.
To get started, follow the getting‑started guide which walks you through deploying the gateway, registering a BigQuery connection, and configuring per‑user OAuth via GCP IAM federation. The learn section provides deeper detail on masking policies, approval workflows, and session replay.
FAQ
Can I still use a shared service‑account key for legacy scripts?
Yes, but those scripts will bypass hoop.dev’s controls. For just‑in‑time access you should migrate them to per‑user OAuth tokens so every request passes through the gateway.
Does hoop.dev store my BigQuery credentials?
The gateway holds the service‑account key or the temporary OAuth token, but agents never see it. This separation prevents credential leakage from the client side.
How long are approval windows kept?
Approval policies are configurable; you can set a window of minutes to hours. Once the window expires, the pending query is automatically rejected.
Explore the open‑source repository on GitHub to see the full implementation and contribute your own guardrails.
