When an enterprise moves Claude workloads onto Google Vertex AI, the audit story has two halves. The first half is familiar: Cloud Audit Logs record actions taken by your own principals — users, groups, service accounts — against Vertex AI, under the service name aiplatform.googleapis.com. The second half is the one that surfaces in vendor security reviews: under what circumstances could Google personnel access content associated with our environment, and would we know? Access Transparency is Google Cloud's mechanism for that second half — a log stream that records actions taken by Google staff, for example when accessing your content in the course of resolving a support case you opened.
What Access Transparency is, in one paragraph
Access Transparency is an organization-level Google Cloud capability that produces log entries when Google operators access customer content, typically including who (at a role level), when, what resource, and a justification such as a support ticket reference. It complements, rather than replaces, Cloud Audit Logs: audit logs are about your identities; Access Transparency is about Google's. Availability and enablement depend on your organization's Google Cloud configuration and support arrangement, and the covered-services list is maintained by Google — confirm current eligibility, the enablement steps, and whether the specific Vertex AI surfaces you use are covered in the official Access Transparency documentation before you promise this control to an auditor.
Reading the entries alongside your other logs
Access Transparency entries land in Cloud Logging, next to the audit log streams you already route — Vertex audit logs live under names like projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access, and logs can be exported to Cloud Storage, BigQuery, or Pub/Sub. Practically, that means you can treat provider-access visibility as one more feed into your SIEM (security information and event management system): route it with a log sink, alert on any entry if your policy demands review of provider access, and store it with the same retention as your audit trail. For most organizations the correct baseline expectation is that these entries are rare; each one should be explainable, usually by a support case your own team opened. The plumbing is the same as in log sink export.
What these logs do not capture
Three boundaries matter, because overstating this control is worse than not having it.
They are not a record of your Claude traffic. Who in your organization called Claude, when, and from which service account is answered by Data Access audit logs — which are disabled by default on Vertex AI and must be explicitly enabled. If you want that record, start with the audit logs deep dive.
They are not a prompt archive. Neither audit logs nor Access Transparency capture prompt and completion content. If you need content-level records, Vertex offers a separate, opt-in request-response logging capability; Anthropic recommends enabling 30-day rolling logging to track any model misuse, and Google's documentation states that turning on this service does not give Google or Anthropic any access to your content.
They do not, by themselves, define the data-sharing boundary. That boundary is set by the platform's data-governance terms — Google's partner-model documentation states that customer prompts and responses are not shared with third parties, and data handling for Claude on this platform is governed by Google Cloud. Access Transparency is evidence supporting a posture, not the posture itself; compliance conclusions should be confirmed with your provider.
Where to go next
For the your-side-of-the-house record, continue with the audit log query cookbook. For the preventive controls that reduce how much you ever need to investigate, see VPC Service Controls and data flow basics.