Cloud Audit Logs is Google Cloud's built-in record of administrative and data activity, and Vertex AI writes to it under the service name aiplatform.googleapis.com (resource type audited_resource). But "audit logging is built in" hides a distinction that matters enormously for Claude workloads: audit logs come in categories with very different defaults.
Why prediction calls aren't logged by default
Google splits audit logs into types. Admin Activity and System Event logs — configuration changes, service events — are always enabled and can't be disabled. Data Access audit logs, which record reads of data, are disabled by default and must be explicitly enabled.
The wrinkle for Claude on Vertex AI: online prediction calls — including endpoints.predict and endpoints.rawPredict, the operations behind every Claude message request — are recorded as Data Access operations with the DATA_READ category. A model invocation "reads" from the endpoint, so it falls in the default-off bucket. The practical consequence: a team can run Claude in production on Vertex AI for months and have no record at all of who invoked the model, from which identity, or how often — while believing that "GCP audits everything." (Data Access logs are also high-volume and billable in general, which is why Google leaves them off; enabling them is a deliberate choice with a cost dimension.)
Turning DATA_READ logging on
You enable Data Access audit logs in your project's Audit Logs configuration (IAM & Admin → Audit Logs in the console, or via the project's IAM audit-config policy), selecting the Vertex AI service and the DATA_READ log type. Once enabled, each Claude prediction call produces an audit entry recording the caller identity, the operation (endpoints.predict / endpoints.rawPredict), the resource, and timing.
Two scope notes before you rely on it:
- These logs are metadata, not content. Audit logs answer who/what/when. Prompts and completions are captured by Vertex AI's separate request-response logging feature — which, note, is unavailable inside a VPC Service Controls perimeter (see the VPC-SC logging gap).
- Enable it before you need it. Audit logging is not retroactive; the trail starts when you switch it on. Make DATA_READ enablement part of the project-setup checklist, next to model enablement and IAM bindings.
Reading the logs requires Private Logs Viewer
Here's the second trap. The ordinary Logs Viewer role (roles/logging.viewer) covers Admin Activity, Policy Denied, and System Event logs only. Reading Data Access audit logs requires Private Logs Viewer (roles/logging.privateLogViewer).
So an auditor or security engineer with standard log access will see your configuration changes but draw a blank on prediction activity — not because the logs don't exist, but because their role can't see them. Google gates these logs harder because Data Access entries reveal usage patterns and caller identities. Grant roles/logging.privateLogViewer deliberately, to the people whose job is reviewing access, and treat that grant itself as audit-worthy.
roles/logging.privateLogViewer to your reviewers; (3) verify an endpoints.predict entry appears after a test Claude call before declaring the control operational.Where the entries land, and getting them out
Audit entries are organized into per-project log streams — Google documents names of the form projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access, alongside %2Factivity, %2Fsystem_event, and %2Fpolicy. For retention or analysis beyond Cloud Logging's defaults, logs can be routed to Cloud Storage, BigQuery, or Pub/Sub — a BigQuery sink is a common choice when security wants to query Claude usage by principal over time, and it composes with the identity model described in the Workload Identity Federation article, since federated workloads show up under their mapped identities.
This is the Vertex counterpart of Bedrock's CloudTrail story — same division of labor between call metadata (always structured, never content) and opt-in content logging. Compare the Bedrock CloudTrail article if you run both platforms.
Where to go next
See the audit logging overview for the cross-platform picture, and the token-count metric caveat for measuring usage rather than access.