Vertex AI Model Registry models stored without a customer-managed key
What does ZopNight detect here?
Vertex AI models registered without `encryptionSpec.kmsKeyName` keep their uploaded model files and evaluation results under Google default encryption. ZopNight flags each such model as a low-severity compliance finding; the key is set in the training pipeline or upload request that creates the model, so fixing it means producing a new model version under your Cloud KMS key.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1346 |
| Category | compliance |
| Severity | low |
| Metric | none — pure configuration read |
| Threshold | no kmsKeyName in encryptionSpec |
| Source | ZopNight |
| Permissions used | aiplatform.models.list · aiplatform.models.get |
Where it applies
Model weights are intellectual property
A trained model is the most expensive thing an ML team produces, and its weights can leak details of the training data. Google’s Vertex AI CMEK page lists what a key protects for a model: the uploaded model files and the evaluation results of the trained model, including AutoML-trained models. Metadata such as the model’s display name stays under Google encryption either way.
Without a customer key there is no Cloud KMS audit trail of use and no way to make the stored artifact unreadable by disabling a key.
Finding models with no key
gcloud ai models list --region=REGION \ --format="table(name, displayName, encryptionSpec.kmsKeyName)"Models with nothing in the key column use Google default encryption.
How ZopNight tests a model
ZopNight inventories models in the Model Registry and records whether each model’s encryption settings include a Cloud KMS key. A confirmed absence of a key raises the finding. Deployment status, framework and model size play no part.
What passes
Models created with a key are silent, and a model whose encryption setting was not collected produces nothing. A model that is registered but never deployed is a separate housekeeping signal, GCP Vertex AI Model Not Deployed.
A key-control gap, not a cost
There is no saving. The consequence is model artifacts outside the key controls your CMEK policy promises auditors.
Producing a keyed model
- Create a key in the model’s region and grant the Vertex AI service agent the Cloud KMS CryptoKey Encrypter/Decrypter role on it.
- For AutoML or custom training, set the key on the training pipeline so the resulting model is
encrypted with it. For imported models, include an
encryptionSpecwithkmsKeyNamein the upload request. - Store the source artifacts in a Cloud Storage bucket that also uses the key; Google notes CMEK on Vertex AI does not configure it for other products.
- Deploy the new model, retire the old version, and delete it once nothing references it.