Every Claude inference call on Vertex AI can leave an audit trail. Vertex AI writes Cloud Audit Logs under the service name aiplatform.googleapis.com (resource type audited_resource), and online prediction calls — including the endpoints.predict and endpoints.rawPredict operations that carry Claude requests — are recorded as Data Access audit entries of type DATA_READ. Cloud Logging retains these entries for a limited period, which is fine for debugging and useless for forensics. Long-term retention means routing them somewhere durable and queryable, and BigQuery is the natural destination: Google's audit-logging documentation lists Cloud Storage, BigQuery, and Pub/Sub as the supported routing targets.
Step zero: turn Data Access logs on
This is the step most teams miss. Admin Activity and System Event audit logs are always enabled and can't be disabled — but those only capture administrative operations. Data Access audit logs, the ones that record actual inference calls, are disabled by default and must be explicitly enabled for the Vertex AI service in your project's audit log configuration. Until you do, there is nothing to export: no record of who invoked Claude exists. Enable them before the pilot ships, because logs cannot be backfilled.
Reading these logs is also privileged. Data Access entries require the Private Logs Viewer role (roles/logging.privateLogViewer); the ordinary Logs Viewer role (roles/logging.viewer) covers only Admin Activity, Policy Denied, and System Event logs. Plan the same distinction for your BigQuery dataset permissions after export.
Creating the sink
A log sink is a standing rule in Cloud Logging: "every entry matching this filter, copy to that destination." The audit log streams live under names like projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access (with parallel %2Factivity, %2Fsystem_event, and %2Fpolicy streams). A sink for Claude-relevant forensics therefore filters on the Data Access stream and the Vertex service:
logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access"
protoPayload.serviceName="aiplatform.googleapis.com"Point the sink at a dedicated BigQuery dataset. Two operational notes: grant the sink's writer identity permission on the destination dataset (the console flow prompts for this), and set the dataset's location and access controls deliberately — audit data about Claude usage is itself sensitive, and if you follow a CMEK strategy, this dataset belongs under it. For organization-wide coverage, an aggregated sink at the folder or organization level beats per-project sinks you have to remember to replicate.
Querying: per-caller usage forensics
Once entries land in BigQuery, each row is a structured audit record whose payload carries the elements forensics needs: the authenticated caller's identity, the method invoked (e.g. a rawPredict call), the resource — which for Claude includes the publisher model path with the model name — the timestamp, and caller metadata. Exact column layout in BigQuery follows Cloud Logging's audit-entry export schema; inspect the auto-created tables in your dataset and pin your queries to what you find there rather than to a blog post's field paths. The questions worth templating as saved queries:
- Who is calling? Count of invocations per caller identity per day — your baseline for spotting a credential doing something new.
- What are they calling? Invocations grouped by model resource name, catching unapproved model usage.
- When did it change? Week-over-week deltas per identity; a quiet service account that suddenly makes thousands of calls is exactly what this table exists to catch.
token_count metrics, since console quota-page figures can be skewed by Anthropic's token estimation and refund system.Where to go next
The audit log query cookbook collects more query patterns, and the Cloud Audit Logs deep dive covers the log types in detail. For the cost side of attribution, see labels and cost attribution.