AI Security Maturity Model·AWS v1.0.0

Drag to explore · pinch to zoom

Enhanced Data ProtectionDefense-in-depth layer: Identity & Data Capability 6 · AI applicationsUse 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.

c6.6 Store application credentials in Secrets Manager

Keep application credentials and API keys in a managed secret store with encryption and rotation, so they are never embedded in code or configuration.

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

Implementation guidance

How to implement on AWS

Store application credentials and API keys in AWS Secrets Manager encrypted with a customer managed KMS key, enable automatic rotation where supported, and use fine-grained IAM policies to control which users and applications can retrieve specific secrets.

Never hardcode the app's secrets

AI applications accumulate credentials: third-party model API keys, database passwords, OAuth client secrets, webhook signing keys. The moment any of these is pasted into source, an environment variable in a build script, or a container image layer, it becomes something you cannot rotate cleanly, audit precisely, or revoke without a redeploy — and it may leak through your own model's output or logs. AWS Secrets Manager stores these encrypted with KMS, rotates them on a schedule, audits every read in CloudTrail, and hands the value to your workload at runtime over an IAM-authenticated API call.

Store the secret, encrypted with your key

Create the secret encrypted with a customer managed key so you control access to the key as well as the secret:

aws secretsmanager create-secret \
  --name "prod/ai-app/model-provider-api-key" \
  --description "Third-party model API key for the AI app" \
  --secret-string '{"apiKey":"REPLACE_ME"}' \
  --kms-key-id "arn:aws:kms:us-east-1:111122223333:key/<key-id>"

Retrieve at runtime, never at build time

The application fetches the secret when it runs, using its IAM role — the value is never baked into the image or config:

aws secretsmanager get-secret-value \
  --secret-id "prod/ai-app/model-provider-api-key" \
  --query SecretString --output text

Scope the app role's secretsmanager:GetSecretValue to this specific secret ARN, and add a resource policy on the secret so only that role can read it.

Turn on rotation

A secret that never changes is a standing risk. Enable automatic rotation so a leaked value has a limited lifetime:

aws secretsmanager rotate-secret \
  --secret-id "prod/ai-app/model-provider-api-key" \
  --rotation-rules '{"AutomaticallyAfterDays": 30}' \
  --rotation-lambda-arn "arn:aws:lambda:us-east-1:111122223333:function:RotateModelApiKey"

For AWS-native credentials (like RDS), Secrets Manager provides managed rotation; for third-party API keys you supply a small rotation Lambda that calls the provider's key-rotation API.

Naming note: use a clear path-style secret name (env/app/purpose), a customer managed KMS key, and scope both the IAM policy and the secret's resource policy to the one app role. Replace the key and Lambda ARNs.

Acceptance criteria

App credentials live in Secrets Manager (CMK-encrypted) with rotation; retrieval is restricted by fine-grained IAM; no secrets in code/config.

Practical implementation

How this control is implemented in each reference architecture:

Application credentials and API keys live in Secrets Manager (CMK-encrypted, rotated) in the Application account, retrieved only by the roles that need them — never in code or config.

  1. Store application credentials and API keys in AWS Secrets Manager encrypted with a customer managed KMS key.
    Application account Secrets Manager AWS KMS
  2. Enable automatic rotation where supported.
    Application account Secrets Manager
  3. Use fine-grained IAM policies to control which users and applications can retrieve specific secrets.
    Application account IAM

How to validate: App credentials live in Secrets Manager (CMK-encrypted) with rotation; retrieval is restricted by fine-grained IAM; no secrets appear in code/config.

Avoid: API keys in environment variables or a config file in the repo. Store them in Secrets Manager and retrieve at runtime.

Generative AI OU (multi-account) →

Secrets Manager (CMK-encrypted, rotated) holds app credentials in the account, with fine-grained IAM controlling retrieval.

  1. Store credentials and API keys in Secrets Manager encrypted with the customer managed key.
    Application tier (IAM role) Secrets Manager AWS KMS
  2. Enable automatic rotation where supported.
    Application tier (IAM role) Secrets Manager
  3. Restrict retrieval with fine-grained IAM policies.
    Application tier (IAM role) IAM

How to validate: Credentials live in Secrets Manager (CMK-encrypted) with rotation; retrieval is IAM-restricted; no secrets in code/config.

Avoid: Hardcoding secrets 'just for now'. Put them in Secrets Manager from the start and rotate them.

Single account (entry point) →

Threats addressed

  • Credentials or API keys exposed in code or environment variables.
  • Stale, long-lived credentials that cannot be rotated.

AWS services

AWS Secrets Manager AWS KMS

Pricing

Free trial · 30 days

AWS Secrets Manager bills per secret per month plus per 10,000 API calls, with a 30-day free trial. Cache the secret in the application (with a short TTL) rather than calling GetSecretValue on every request to keep both cost and latency low. See Manage API keys for security-sensitive workloads.

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 Well-Architected Generative AI Lens (Security)

  • GENSEC01-BP03 Implement least privilege access to data stores

Learning resources

References

  • AWS SRA for AI — Capability 6, Data protection