Vertex AI writes Cloud Audit Logs under the service name aiplatform.googleapis.com. Claude inference calls — the online prediction operations endpoints.predict and endpoints.rawPredict — are recorded as Data Access (DATA_READ) entries, and that is the catch every forensics exercise trips over: Admin Activity and System Event logs are always on, but Data Access audit logs are disabled by default. If you did not explicitly enable them for Vertex AI before the incident, there is no record of the calls to query. Enable them now, in every project that can reach Claude, before you need this cookbook.
Two more prerequisites. Reading Data Access logs requires the Private Logs Viewer role (roles/logging.privateLogViewer) — plain Logs Viewer only covers Admin Activity, Policy Denied, and System Event logs. And note what audit logs contain: caller identity, timestamp, method, resource — not prompt or response content. Content-level records are a separate, opt-in Vertex request-response logging feature.
Log Explorer recipes
Data Access entries live in the log named projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access. A base filter for Claude-relevant traffic:
logName="projects/my-project/logs/cloudaudit.googleapis.com%2Fdata_access"
protoPayload.serviceName="aiplatform.googleapis.com"
protoPayload.methodName=~"[Rr]awPredict|[Pp]redict"Who called Claude? Add a grouping eye: audit entries carry the authenticated principal in protoPayload.authenticationInfo.principalEmail. Pull one matching entry first and confirm the field paths and method names against what your project actually writes — audit schemas are stable, but verifying against a live sample beats trusting a cookbook.
Was it Claude, or another Vertex model? Prediction calls target a publisher model resource; Claude requests go to paths of the form projects/…/locations/…/publishers/anthropic/models/…, so filtering the entry's resource/request fields for publishers/anthropic separates Claude traffic from the rest of Vertex. Again, confirm on a sample entry which field carries the path in your entries.
Only service accounts, only production: append protoPayload.authenticationInfo.principalEmail=~"gserviceaccount.com$" and scope the time picker. An unfamiliar principal here — or a human account calling production — is your lead.
BigQuery recipes for scale questions
Log Explorer is for looking; BigQuery is for counting. Route the Data Access log to BigQuery with a log sink (audit logs can be routed to Cloud Storage, BigQuery, or Pub/Sub — setup in log sink export). Sinks only capture entries from creation onward — another reason to set this up on day one. Table names follow your sink configuration; the query below assumes a dataset audit_logs:
SELECT
protopayload_auditlog.authenticationInfo.principalEmail AS caller,
DATE(timestamp) AS day,
COUNT(*) AS calls
FROM `my-project.audit_logs.cloudaudit_googleapis_com_data_access`
WHERE protopayload_auditlog.serviceName = 'aiplatform.googleapis.com'
AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY caller, day
ORDER BY day DESC, calls DESC;Variations that answer real tickets: group by hour to bracket an incident window; add a HAVING calls > N clause to surface anomalous volume; join against your team's service-account inventory to flag callers nobody owns. Column names in exported audit tables depend on the export format — run a SELECT * on one row first and adjust.
token_count metrics in Metrics Explorer or the token counting API — Google notes that console quota-page token usage can be inaccurate — and for what was said, you need request-response logging to have been enabled beforehand.Make the answers mean something
Forensics is only as good as your identity hygiene. If five applications share one service account, every query above returns the same useless email. One dedicated service account per application (see the local dev workflow and least-privilege patterns) turns these queries into an actual attribution system. Alerting on the same filters — new principal, volume spike, off-hours human access — converts the cookbook from reactive to proactive; see the audit logs deep dive.
Where to go next
For provider-side access visibility, read Access Transparency logs. For the spend view of the same traffic, budget alerts and cost attribution.