An auditor asks a simple question: show me every query an automated system ran against the dataset that holds customer records, who authorized it, and what it returned. If your agents authenticate with a shared service-account key, you cannot answer cleanly, because the audit layer sees one principal doing everything. Session recording is how you turn that unanswerable question into a short demo.
Session recording for AI agents on BigQuery means capturing each statement an agent runs, attributing it to that specific agent, and keeping the record where the agent cannot alter it. Done right, it is the artifact you hand an auditor instead of an apology.
What an auditor actually wants
Auditors are not impressed by aggregate metrics. They want per-actor evidence: this identity, this query, this time, this result, with a clear chain showing the record was not produced by the thing being audited. A shared key fails the first test, and self-written agent logs fail the last.
So the recording has to do two things at once: attribute to a real identity, and originate outside the agent.
Session recording as the artifact you hand an auditor
An audit goes better when the evidence is boring. The reviewer asks for every automated query against a sensitive dataset over a period, and you produce a list: this agent, this statement, this timestamp, this result, session after session. No reconstruction, no caveats about which logs to trust. Session recording produced at the gateway gives you that list directly.
The reason it satisfies a reviewer is the chain of custody. The record was made by the gateway the agent connected through, not by the agent, so the agent had no opportunity to shape it. Pair that with a per-agent identity and the recording stops being a self-report and becomes third-party evidence, which is the standard an auditor is actually applying.
Recording at the connection boundary
hoop.dev proxies the connection to BigQuery, which is what makes both properties possible. Because every query crosses the gateway, hoop.dev records the statements at the command level and binds each to the calling agent. The recording is created by the gateway, not the agent, so it stands as independent evidence.
Enable GCP IAM federation and the session runs under a per-user OAuth credential rather than a shared key, so the identity in the record is the agent itself and not a generic service account. The record now answers the auditor's "who" without ambiguity.
The same recording serves two audiences that usually get separate tooling. An incident responder replays a single session to see what an agent did during a window. An auditor queries across sessions to confirm a control was in force the whole period. Both read the same gateway-produced record, so you are not maintaining one trail for compliance and another for operations and hoping they agree.
Steps
- Run the hoop.dev agent near your GCP project with an outbound connection to the gateway.
- Create a BigQuery connection, set
CLOUDSDK_CORE_PROJECT, and enable GCP IAM federation for per-user OAuth. - Turn on session recording for the connection.
- Route the agent's
bq traffic through the gateway.
# every statement here lands in the per-agent recording
bq query --use_legacy_sql=false \
'SELECT account_id, status FROM billing.invoices WHERE status = "overdue"'
Verify
Run several queries as the agent, then open the recording in hoop.dev and confirm each statement appears with the agent's identity and timestamp. Export a slice and check it reads as standalone evidence without needing the agent's cooperation.
Pitfalls
- Do not equate BigQuery job history under a shared key with session recording; it cannot attribute per agent.
- Do not keep recordings somewhere the recorded workload can modify them.
- Do not capture statements while dropping identity. Evidence without a subject is not evidence.
hoop.dev is open source, so you can show an auditor how and where the recording is produced. Read the getting started guide and see how recording underpins audit logging for AI agents on BigQuery. Begin at github.com/hoophq/hoop and produce a per-agent recording from a test session.
FAQ
Does session recording give per-agent attribution?
Yes, when the connection uses GCP IAM federation. Each session runs under the agent's own short-lived credential, so the recording attributes statements to the agent rather than to a shared service account.
Can the agent tamper with its own recording?
No. The recording is produced and stored by the gateway on the connection path, outside the agent, so it remains independent of the workload it records.
