Cloud Audit Logs are Google Cloud's tamper-oriented record of "who did what, where, and when" across services. Vertex AI writes its audit entries under the service name aiplatform.googleapis.com (resource type audited_resource), so your Claude usage shows up in the same logging infrastructure — and the same reviewer tooling — as every other Google Cloud service you run. The catch is that the log type that records model calls is not on by default.
The log types, and what each captures
| Log type | Captures | Default |
|---|---|---|
| Admin Activity | Administrative and configuration actions | Always on; cannot be disabled |
| System Event | Google-initiated system actions | Always on; cannot be disabled |
| Data Access | Reads of resource data — including online prediction calls | Off; must be explicitly enabled |
| Policy Denied | Requests blocked by policy (for example, a VPC Service Controls perimeter) | On |
The line that matters for Claude: online prediction calls — including endpoints.predict and endpoints.rawPredict, the operations behind Claude requests on Vertex — are recorded as Data Access (DATA_READ) operations. So a project with default settings has a complete record of who enabled Claude and who changed settings, but no per-call record of who used it. Enable Data Access audit logs for the Vertex AI service (via the console's Audit Logs settings or an audit-config policy) in every project where Claude runs, ideally on day one — logs are not retroactive.
Who can read what
Access to the two families is deliberately asymmetric. The Logs Viewer role (roles/logging.viewer) covers Admin Activity, Policy Denied, and System Event logs only. Reading Data Access logs — which may reveal usage patterns and caller identities at fine grain — requires the Private Logs Viewer role (roles/logging.privateLogViewer). Grant the private role to your compliance reviewers and incident responders, not to every developer.
Querying in Logs Explorer
Audit entries land in per-project logs with well-known names: projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity (Admin Activity), ...%2Fdata_access, ...%2Fsystem_event, and ...%2Fpolicy. A compliance review of Claude usage typically starts from a Logs Explorer filter that combines the data-access log with the Vertex service name:
logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access"
protoPayload.serviceName="aiplatform.googleapis.com"From that base, narrow by the fields inside protoPayload — the method name (to isolate prediction calls such as rawPredict), the authenticated principal (to answer "which service accounts called the model last quarter?"), or the timestamp range. For recurring reviews, save the query; for long-horizon retention or SQL-grade analysis, route the audit logs to Cloud Storage, BigQuery, or Pub/Sub with a log sink — audit logs support all three destinations. BigQuery export is the usual choice when compliance wants quarterly aggregates rather than spot checks; see log sink export.
A minimal compliance posture
- Enable Data Access audit logs for Vertex AI in every Claude project.
- Grant
logging.privateLogViewerto a small, named reviewer group. - Create a sink routing audit logs to BigQuery or Cloud Storage for retention beyond default log windows.
- Save one Logs Explorer query per recurring question ("all Claude callers this month", "any calls from unexpected principals").
- Decide separately whether to enable request-response logging for content-level records — noting it isn't available inside a VPC Service Controls perimeter (see VPC Service Controls).
Where to go next
Ready-made queries live in the audit log query cookbook; the cross-platform view is in audit logging across platforms.