It is the morning after, and someone is asking what an agent did to the customers dataset overnight. You check the agent's own logs and find exactly what a compromised or buggy agent would let you find: whatever it chose to write. The record you need is the one the agent could not edit, and you do not have it.
Session recording solves this only if the recording lives somewhere the agent cannot reach. For an AI agent querying BigQuery, session recording means every statement it runs is captured at the connection boundary, attributed to the agent, and stored outside the process that ran it.
The record cannot live inside the thing it audits
Application logs, agent logs, and even BigQuery's own job history under a shared service account all share a weakness when you ask them to be forensic evidence. They describe activity from the perspective of a system that the actor might control or share. A shared key means a hundred runs collapse into one principal, and an agent that writes its own logs writes its own alibi.
Trustworthy session recording has to be produced by something on the path between the agent and BigQuery, by an observer the agent never authenticates as and cannot reconfigure.
What session recording has to capture for a BigQuery agent
A useful record of an agent's BigQuery activity has a few parts. It needs the statements themselves, every SELECT, UPDATE, and DELETE the agent issued, in the order it issued them. It needs an identity attached to each one, so a query is not an orphan event. It needs timestamps, so you can line the session up against an alert or an outage. And it needs to be stored where the agent cannot reach it, so a compromised workload cannot quietly trim the parts that incriminate it.
Miss any one of these and the record stops being evidence. Statements without identity cannot answer who. Identity without statements cannot answer what. A record the agent can edit cannot answer anything you would stake an incident review on.
How the gateway captures the session
hoop.dev proxies the connection to BigQuery. The agent runs the native bq client through the gateway agent, and because every query crosses the gateway, hoop.dev records the statements at the command level and ties each one to the agent's identity. The recording is created and stored by the gateway, not by the agent, so it survives a compromised workload.
With GCP IAM federation enabled, the session also runs under a per-user OAuth credential rather than a shared key, so the recorded identity is real rather than a generic service account shared across everything.
Steps to turn it on
- Deploy the hoop.dev agent near your GCP project so it connects outbound to the gateway with no inbound exposure.
- Create a BigQuery connection with
CLOUDSDK_CORE_PROJECT set, and enable GCP IAM federation for per-user OAuth. - Enable session recording on the connection so each query is captured and attributed.
- Send the agent's
bq traffic through the gateway.
# this statement is recorded at the gateway, tied to the agent
bq query --use_legacy_sql=false \
'UPDATE customers.profiles SET tier = "gold" WHERE spend > 10000'
Verify the replay
Run a sequence of queries as the agent, then open the session in hoop.dev and replay it. You should see each statement in order, the agent that ran it, and the timestamps, independent of anything the agent logged itself.
Pitfalls
- Do not treat BigQuery job history under a shared key as session recording. It loses per-agent attribution the moment the key is shared.
- Do not store the recording where the recorded workload can write to it. The record's value is that the actor cannot edit it.
- Do not record the queries but skip identity. A statement with no attributable principal is a story with no subject.
hoop.dev is open source, so you can confirm where the recording is produced and stored before you depend on it for an incident. Read the getting started guide and see how recording pairs with audit logging for AI agents on BigQuery to give an auditor the full trail. Start at github.com/hoophq/hoop and record a test agent's BigQuery session end to end.
FAQ
What does session recording capture for a BigQuery agent?
It captures the statements the agent runs through the gateway at the command level, tied to the agent's identity, with timestamps, so you can replay exactly what happened in a session.
Why not rely on the agent's own logs?
Because a compromised or buggy agent controls its own logs. Session recording produced at the gateway sits outside the agent, so the record holds even when the agent does not.
