GCP already gives you Cloud Audit Logs. So why is audit logging for AI agents on GCP still a gap? Because Cloud Audit Logs records what the GCP API saw: a service account ran a query. It does not record which agent, on whose behalf, ran which exact statement, or whether a human approved it. When the actor is an AI agent sharing one service-account key, the log says "the key did it" and stops there.
To close that gap you need a log at the connection layer, one that names the real identity and captures the command. This post shows how to build it.
What good audit logging has to prove
An audit log earns its name when it can answer three questions about any action against a GCP-hosted resource:
- Who. A specific identity, not a shared key. If five agents share one credential, the log cannot tell them apart, and the audit fails on the first question.
- What. The exact command or query, not "performed database maintenance."
- Whether it was allowed. Did this action fall inside an approved scope, and if it was sensitive, did a human sign off?
The architectural requirement is that this log accumulate continuously and live outside the agent. An agent that writes its own audit trail is a witness testifying about itself. The record has to be produced by the layer the agent passes through, not by the agent.
The connection layer is where the truth is
Every action an agent takes against GCP-hosted infrastructure is a connection: a query to BigQuery, a statement to Cloud SQL, a command to a GKE-hosted service. If you log at that connection, you log the truth of what happened, and you log it whether or not the agent cooperates.
hoop.dev is an open-source Layer 7 access gateway built around that idea. It proxies the agent's connection to the GCP-hosted resource and records each session at the command level, attributed to the authenticated identity. That record is your audit log, and it is generated by infrastructure the agent cannot reconfigure.
Standing up audit logging with hoop.dev
- Deploy the hoop.dev gateway and add a connection for each GCP-hosted target you want audited.
- Turn on GCP IAM federation for the connection. Identity now resolves to a per-user short-lived OAuth credential, so the log records a real principal instead of a shared service-account key.
- Route agent access through the gateway. Each query and command flows through the proxy, where it is captured and attributed.
- For sensitive operations, attach an approval step. The audit log then shows not just the command and the actor but the approval that gated it.
- Verify: run a handful of agent actions, then pull the session records and confirm each one names an identity, the exact command, a timestamp, and any approval.
The result reads like an audit trail an auditor recognizes: continuous, per-identity, command-level, and produced outside the actor.
How this complements Cloud Audit Logs
This does not replace GCP's own logging. Cloud Audit Logs still records control-plane activity. hoop.dev's record adds the layer GCP cannot see: which human or agent identity, behind a federated credential, ran which exact command through the connection, and whether it was approved. Together they cover the control plane and the connection.
Pitfalls to avoid
- Do not rely on the agent's application logs as your audit source. They live inside the actor and can be incomplete or altered.
- Do not log the credential instead of the identity. A shared key in the log is not attribution. Federate so the log names a person or agent.
- Do not assume hoop.dev fronts GCP's admin API. It governs connections to GCP-hosted infrastructure and records those, not the GCP control plane itself.
FAQ
Is this a replacement for GCP Cloud Audit Logs?
No. It complements them. Cloud Audit Logs cover the GCP control plane; hoop.dev's session records cover the per-identity, command-level activity on the connection to GCP-hosted resources.
How does audit logging name the actor when agents share infrastructure?
With GCP IAM federation on the connection, each session resolves to a per-user short-lived OAuth credential, so the log attributes actions to a distinct identity rather than a shared key.
Where is the audit record stored?
At the gateway, outside the agent process, so the actor cannot edit its own history.
To build audit logging for AI agents on GCP that holds up under review, run the open-source gateway: github.com/hoophq/hoop. The getting started guide walks through your first connection, and hoop.dev/learn explains how attribution and recording produce the trail.
