AI Security Maturity Model·AWS v1.0.0

Drag to explore · pinch to zoom

Foundational Data ProtectionDefense-in-depth layer: Identity & Data Capability 1 · Model inferenceUse case: AI that answers 👤 CustomerAWS Shared Responsibility Model: who implements and operates this control. Customer = you own it; AWS = AWS operates it and you inherit it; Shared = both have obligations.

c1.2 Encrypt inference data with customer managed KMS keys

Encrypt prompts, completions, and any stored inference data with a customer managed key you control, rather than relying only on default AWS managed keys.

Foundational
Enhanced
Advanced
Effort: Low Impact: High GenAI scopesFrom the AWS Generative AI Security Scoping Matrix.: 3 · Pre-trained models

Implementation guidance

How to implement on AWS

Create a customer managed KMS key for inference data and reference it when configuring Bedrock, guardrails, and any S3 storage for prompts/logs. Use key policies plus IAM to restrict who can decrypt, and enable key rotation.

Why a customer managed key

By default Amazon Bedrock encrypts data with an AWS managed key, which you cannot inspect, restrict, or audit at the policy level. A customer managed key (CMK) lets you decide exactly which principals and which services may use the key, rotate it on your schedule, and see every use in CloudTrail. For regulated inference workloads this control over the key — not just the data — is usually the requirement.

Scope the key to Bedrock with a key policy

The key policy is the root of trust for a KMS key. Grant the Bedrock service principal only the operations it needs, and constrain them to Bedrock with the kms:ViaService condition so the key cannot be used through other services:

{
  "Sid": "AllowBedrockToUseTheKey",
  "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" }
  }
}

Bedrock creates a grant on the key (via kms:CreateGrant) so it can use the CMK for long-running work such as model customization; keep that permission in the policy above.

Encrypt the data that leaves the model too

Prompts and completions are also written wherever you send model invocation logs. Point that logging at an S3 bucket or CloudWatch Logs group that is itself encrypted with the same CMK, so the stored copy of the inference data is protected with the key you control, not the default aws/s3 key. See Monitor model invocation using CloudWatch Logs and Amazon S3.

Turn on rotation and least-privilege decrypt

  • Enable automatic annual key rotation on the CMK.
  • In the key policy, separate key administrators (who manage the key) from key users (who may Decrypt); the runtime role should be able to decrypt, not administer.
  • Watch KMS usage from Bedrock with CloudTrail — see Monitoring your encryption keys for the Amazon Bedrock service.
Naming note: replace us-east-1 in the kms:ViaService value with your Region. Use a distinct CMK (and separate kms:ViaService line) per Region rather than a single shared key.

Acceptance criteria

Inference data at rest is encrypted with a customer managed key; the key policy limits decrypt to approved roles; rotation is enabled.

Practical implementation

How this control is implemented in each reference architecture:

A customer managed key lives in the Generative AI account and encrypts guardrails, model-invocation logs, and prompt/response storage; its key policy grants decrypt only to approved roles.

  1. Create a customer managed KMS key in the Generative AI account and reference it when configuring Bedrock guardrails, model-invocation logging, and any S3 bucket that stores prompts or completions.
    Generative AI account AWS KMS Amazon Bedrock Amazon S3
  2. Write a key policy that grants kms:Decrypt only to the specific invoke and logging roles, and enable automatic annual key rotation.
    Generative AI account AWS KMS
  3. Grant the Log archive account's reader role the minimal decrypt permission it needs to process centralized logs, via a grant or key-policy statement.
    Generative AI account → Log archive AWS KMS

How to validate: All inference-related storage shows the customer managed key (not aws/bedrock default); the key policy lists only approved decrypt principals; rotation is enabled.

Avoid: Relying on the default AWS managed key so encryption is 'on' but you cannot restrict or audit who decrypts. Use a customer managed key with a tight key policy.

Generative AI OU (multi-account) →

One customer managed key in the account encrypts all inference data, with a key policy scoped to the runtime and logging roles only.

  1. Create a dedicated customer managed KMS key and set it on Bedrock guardrails, model-invocation logging, and the S3 buckets holding prompts/responses/logs.
    Generative AI tier (IAM role) AWS KMS Amazon Bedrock Amazon S3
  2. Restrict kms:Decrypt in the key policy to the model-invocation role and the logging role; deny it to broad principals; enable key rotation.
    Generative AI tier (IAM role) AWS KMS
  3. Keep the KMS key administrators separate from the runtime roles so the app cannot change or disable the key.
    Application tier (IAM role) AWS KMS IAM

How to validate: Inference storage is encrypted with the customer managed key; only the invoke/logging roles can decrypt; rotation is enabled; the app runtime role cannot administer the key.

Avoid: One key shared across unrelated workloads with a wide-open key policy. Use a dedicated key and scope decrypt to the roles that actually process inference data.

Single account (entry point) →

Threats addressed

  • Sensitive prompt or response data readable if a default key or storage is compromised.
  • Unauthorized modification of guardrail or model configuration.

AWS services

AWS KMS Amazon Bedrock

Pricing

Each customer managed key costs a small monthly fee, plus a per-request charge for KMS API calls made during encrypt/decrypt operations. There is no charge for AWS managed keys, so the CMK cost is the price of the extra control and auditability.

Framework mappings

OWASP GenAI/LLM Top 10 (2026)

  • LLM02 Sensitive Information Disclosure

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

  • Bedrock.1 Amazon Bedrock data sources should be 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 1, Data security