Customer-Managed Encryption Keys (CMEK) is Google Cloud's mechanism for putting encryption of stored data under keys that you control in Cloud Key Management Service (Cloud KMS), rather than Google's default keys. Google encrypts data at rest either way; what CMEK adds is control — you can rotate the key on your schedule, restrict who can use it, and disable it, which renders the protected data unreadable. For teams bringing Claude on Vertex AI through a security review, the important work is mapping exactly which parts of a Claude workload CMEK can and cannot touch.
What an inference call actually stores
Claude on Vertex is a serverless, fully managed model API. A synchronous messages.create call sends your prompt to a Vertex endpoint, the model generates a response, and the response comes back. Google's partner-model documentation states that data at rest is stored within the selected region or multi-region, and that customer prompts and responses are not shared with third parties. But the defining property of the online inference path is that it is transient processing: encryption of data moving to and from the endpoint is a TLS/in-transit matter, and no customer-managed key is involved in the act of inference itself. CMEK is an at-rest control; it does not protect in-flight inference, and no configuration will change that. If your requirement is control over the network path instead, that is what Private Service Connect and VPC Service Controls address.
Where CMEK genuinely applies in a Claude workload
Look at everything your architecture persists, because each of those stores is where key control lives:
- Batch inputs and outputs. Google's Vertex batch prediction for Claude reads from a BigQuery table or JSONL files in Cloud Storage and writes results back to those services. BigQuery datasets and Cloud Storage buckets are classic CMEK-capable resources — configure keys there and your bulk prompts and completions at rest are under your keys.
- Exported logs. Vertex AI audit logs can be routed to Cloud Storage, BigQuery, or Pub/Sub; if you build the BigQuery audit export, the destination dataset is yours to protect with CMEK.
- Your application's own stores. Conversation history, RAG document indexes, caches of Claude outputs — whatever your app writes to databases and buckets is squarely CMEK territory.
- Request-response logging. If you enable Vertex's optional prompt/completion logging (Anthropic recommends a 30-day rolling window for misuse tracking), that captured content is stored data — include it in your key-scoping conversation.
Which Vertex AI resource types support CMEK, and how keys are attached to each, is documented in Google's Vertex AI CMEK reference and changes over time — verify the current supported list there rather than assuming coverage, especially for partner-model-specific features.
Configuration shape and operational cautions
The general pattern is consistent across Google services: create a key ring and key in Cloud KMS (in the matching location), grant the relevant service's agent permission to use the key, and reference the key when creating the resource — the bucket, the dataset, the resource that will hold data. Keep three cautions in view. First, location discipline: keys are regional resources, so a CMEK strategy interacts with your choice of Vertex endpoint and region (see EU residency). Second, availability risk: disabling or destroying a key makes the protected data unreadable by design — treat key lifecycle changes with production-change rigor. Third, scope honesty in documentation: write down for auditors exactly which stores are CMEK-protected and state plainly that inference is transient processing. Claude on Vertex inherits your cloud provider's compliance posture — confirm certification and regulatory specifics with Google rather than inferring them from encryption settings.
Where to go next
Pair this with the audit logs deep dive for the "who accessed what" half of the story, and data privacy basics for the broader picture across platforms.