c2.1 Encrypt the customization job, data, and model with a CMK
Encrypt training/validation data, output metrics, and the resulting custom model with a customer managed KMS key you own, so customization artifacts are never readable with a default key.
Implementation guidance
How to implement on AWS
Create a customer managed KMS key and specify it when you launch the Bedrock (or SageMaker) customization job so input files, output metrics, and the custom model are encrypted with it. Use the key policy to grant use only to the roles that run the job and invoke the model.
What to encrypt in a customization job
A customization job touches several sensitive artifacts: the training and validation data in S3, the output metrics, and the resulting custom model. By default the custom model is encrypted with an AWS owned key you cannot inspect. Passing your own customer managed key (CMK) puts all of these under a key whose access you control and audit — important because a fine-tuned model can memorize and later reveal fragments of its training data.
Let Bedrock use your key for the job
Bedrock creates a grant on your CMK so the asynchronous job can encrypt/decrypt artifacts while it runs. Your key policy must allow the Bedrock service principal the necessary operations, scoped to Bedrock with kms:ViaService:
{
"Sid": "AllowBedrockCustomizationUseOfKey",
"Effect": "Allow",
"Principal": { "Service": "bedrock.amazonaws.com" },
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": { "kms:ViaService": "bedrock.us-east-1.amazonaws.com" }
}
}
Reference the key when you create the job
Pass the CMK as the customModelKmsKeyId on the customization job so the resulting model is encrypted with it:
aws bedrock create-model-customization-job \
--job-name "finetune-support-bot" \
--custom-model-name "support-bot-v1" \
--role-arn "arn:aws:iam::111122223333:role/BedrockCustomizationRole" \
--base-model-identifier "arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-text-express-v1" \
--custom-model-kms-key-id "arn:aws:kms:us-east-1:111122223333:key/<key-id>" \
--training-data-config '{"s3Uri":"s3://my-bedrock-training-data/train.jsonl"}' \
--output-data-config '{"s3Uri":"s3://my-bedrock-custom-output/"}' \
--hyper-parameters '{"epochCount":"2"}'
Don't forget the data buckets
Encrypting the model is only half the job — the training data bucket should use the same CMK for server-side encryption, and the customization service role needs kms:Decrypt on that key (a common cause of "access denied" job failures). Match the key across the data, the job, and the output so nothing falls back to a default key.
Naming note: replace the key ARN, role ARN, account id, and Region. Use a Region-local CMK matching the kms:ViaService value.Acceptance criteria
The customization job, its S3 buckets, and the custom model are encrypted with a customer managed key; the key policy limits decrypt/use to approved roles.
Practical implementation
How this control is implemented in each reference architecture:
A customer managed key in the Generative AI account (or a dedicated training account of the OU) encrypts the customization job inputs, outputs, and the resulting custom model.
- Create a customer managed KMS key and pass it to the Bedrock (or SageMaker) customization job so input files, output metrics, and the custom model are all encrypted with it.
- Scope the key policy so only the customization service role and the invoke role can use the key, and enable rotation.
- Encrypt the training/validation S3 buckets with the same key and keep the key administrators in the platform team, separate from the job role.
How to validate: The job, its S3 buckets, and the custom model all show the customer managed key; the key policy limits use to the job and invoke roles; rotation is enabled.
Avoid: Encrypting the buckets but letting Bedrock use the default key for the model artifact. Encrypt the whole chain — inputs, metrics, and the model — with your own key.
One customer managed key in the account encrypts the customization job, its data, and the custom model, with use scoped to the job role only.
- Create a dedicated customer managed KMS key and set it on the customization job so inputs, output metrics, and the custom model are encrypted with it.
- Restrict key use in the key policy to the customization service role and the invoke role; enable rotation.
- Keep key administration separate from the runtime and job roles so they cannot disable or change the key.
How to validate: The customization job, buckets, and custom model use the customer managed key; only the job/invoke roles can use it; rotation is enabled.
Avoid: Reusing a general-purpose key with a broad policy for training artifacts. Use a dedicated key scoped to the customization and invoke roles.
Threats addressed
- Sensitive training data or custom model artifacts readable if default keys or storage are compromised.
- Unauthorized use of the custom model for inference.
AWS services
Pricing
The CMK carries a small monthly fee plus per-request KMS charges during the job. These are minor next to the customization compute cost; the benefit is that training data and the fine-tuned model stay under a key you control and audit. See Encryption of model customization jobs and artifacts.
Framework mappings
OWASP GenAI/LLM Top 10 (2026)
- LLM05 Data and Model Poisoning
NIST AI Risk Management Framework (AI 100-1)
- MANAGE.1 AI risks are prioritized, responded to and managed
AWS Security Hub — AI Security Best Practices
- SageMaker.17 SageMaker feature group offline stores should be encrypted with AWS KMS keys
- SageMaker.18 SageMaker feature group online stores with standard storage should be encrypted with AWS KMS keys
- SageMaker.21 SageMaker notebook instances should be encrypted with customer managed AWS KMS keys
- SageMaker.23 SageMaker inference experiments should have instance storage volume encrypted with customer managed AWS KMS keys
- SageMaker.24 SageMaker inference experiments should have data storage encrypted with customer managed AWS KMS keys
AWS Well-Architected Generative AI Lens (Security)
- GENSEC01-BP03 Implement least privilege access to data stores
Learning resources
References
- AWS SRA for AI — Capability 2, Data protection
AI Security Maturity Model