# KMS and Secrets Lifecycle Controls Guide

Use this reference for AWS KMS key policy, grants, aliases, rotation, multi-Region keys, imported key material, key deletion, Secrets Manager rotation, replication, VPC endpoints, resource policies, and application secret consumption.

## What people get wrong

The lazy story is:

> Encryption is enabled and secrets rotate, so crypto posture is fine.

Wrong. KMS and Secrets Manager failures are usually lifecycle failures: bad key policy, grant sprawl, broken rotation consumers, disabled replica keys, undecryptable backups, or irreversible key deletion.

Common bad assumptions:

- IAM policy alone controls KMS access.
- Key aliases are stable security boundaries.
- Automatic key rotation solves secret rotation.
- Secret replication is harmless metadata.
- VPC endpoints make secret retrieval private and authorized.
- Scheduled key deletion is a normal cleanup task.

## KMS/secrets failure modes

- Key policy omits account/root enablement, break-glass, or required service principals.
- Grants survive longer than workload need or permit unintended decrypt/data-key use.
- KMS key disabled/deleted/rotated blocks RDS, EBS, S3, Lambda, backups, or secret replication.
- Rotation Lambda updates the secret but not every consuming application or connection pool.
- Secrets Manager resource policy allows cross-account access without org/source conditions.
- Multi-Region key or replicated secret has asymmetric policy/KMS/VPC endpoint posture.

## Minimum safe workflow

1. Identify protected data, key/secret owners, consuming services, Regions, accounts, and recovery requirements.
2. Review KMS key policy first, then IAM policies, grants, aliases, rotation, multi-Region state, and deletion schedule.
3. Review secret lifecycle: creation, rotation, version staging labels, replication, resource policy, retrieval path, cache, and consumers.
4. Check endpoint and policy conditions: VPC endpoint, principal org, source account/ARN, encryption context, and service principal.
5. Verify recovery: break-glass, backup restore decryptability, replica key availability, and rollback of rotation.
6. Recommend reversible policy/rotation fixes; key deletion, disablement, or secret deletion require explicit approval and impact proof.
7. Separate configuration evidence from successful decrypt/restore/rotation evidence.

## Verification targets

- KMS key policy, IAM policies, grants, aliases, rotation, multi-Region key state, imported material, deletion schedule, and CloudTrail usage
- encryption context, ViaService/source conditions, cross-account principals, and service-linked usage
- Secrets Manager secret policy, KMS key, rotation Lambda, version staging labels, replication Regions, and last rotation status
- VPC endpoint policy, CloudTrail events, application retrieval path, cache TTL, and error handling
- RDS/EBS/S3/Lambda/ECS/EKS/AWS Backup dependencies on the key or secret
- break-glass access, recovery tests, backup restore decryptability, and consumer rotation validation

## When to push back

Push back if the user asks to:

- schedule KMS key deletion without dependency and restore proof
- rotate secrets without consumer readiness and rollback plan
- use broad decrypt permissions or wildcard key policies
- treat aliases as immutable trust anchors
- replicate secrets/keys without Region, KMS, and policy review
- remove CloudTrail/log evidence while fixing access

# Official sources

Use this reference only when you need source grounding for AWS service behavior or the detailed source list.

## AWS documentation

Use these as starting points, not as proof of the user's live AWS state:
- https://docs.aws.amazon.com/kms/latest/developerguide/overview.html
- https://docs.aws.amazon.com/kms/latest/developerguide/rotating-keys.html
- https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html
- https://docs.aws.amazon.com/secretsmanager/latest/userguide/mes-security.html

## Grounding rule

Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.

## Current MCP/documentation refresh (2026-06-02)

Service facts from official docs:
- Secrets Manager supports managing secret lifecycle and automating credential rotation instead of hard-coded secrets.
- Secrets Manager security guidance says rotation requires appropriate IAM policies and KMS/key trust policies, with scope that can vary by region.

Sampled live evidence:
- Read-only regional availability sampling reported AWS KMS and AWS Secrets Manager as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
- Sampled APIs `KMS+DescribeKey` and `Secrets Manager+DescribeSecret` were reported `isAvailableIn` in those regions.

Review implications:
- Do not claim secret safety without evidence for rotation status, KMS key policy/grants, resource policy, replica/region scope, access path, audit logs, recovery windows, and application cutover behavior.
- Key or secret existence does not prove least privilege, correct rotation, or safe deletion.

# Safety checklist

Use this reference before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting recommendations.

## Non-negotiables

- Never ask users to paste secrets, access keys, session tokens, private keys, customer identifiers, or sensitive account data into chat.
- Use read-only AWS MCP or read-only AWS CLI evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
- Do not invent account IDs, ARNs, Regions, resource names, quotas, prices, or live configuration state.
- Require explicit user approval before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting actions.
- Use current official AWS documentation for service behavior when the answer depends on AWS service details.
- Keep remediation least-privilege, reversible, and scoped to the requested workload or account boundary.

## Stress checks

- What can expose data?
- What can escalate privilege?
- What can break production or block rollback?
- What can create unbounded cost?
- What compliance or audit evidence is missing?
- What rollback or validation path is unproven?

## Evidence labels

Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live AWS state.

# Workflow and output contract

Use this reference only when performing the full review, implementation guidance, incident triage, or production-readiness pass.

## Review domains

Check these areas before giving a verdict:
- Key purpose, data classification, owning service, key policy, IAM policy, grants, aliases, tags, deletion window, and break-glass path
- Rotation strategy, multi-Region behavior, imported key material, replica policies, CloudTrail evidence, and service integration constraints
- Secret type, rotation pattern, Lambda permissions, retry/client caching, replication, resource policy, VPC endpoint condition, and monitoring
- Recovery risk: backups, cross-account restore, DR Region, disabled/deleted keys, stale credentials, and operator ownership

## Safe workflow

1. **Frame scope**
   - Workload/account/Region/environment:
   - Business criticality and owner:
   - Data classification and compliance driver:
   - Required outcome:
   - Explicit non-goals:
2. **Collect evidence**
   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
   - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
3. **Stress-test risk**
   - What can expose data?
   - What can escalate privilege?
   - What can break production or block rollback?
   - What can create unbounded cost?
   - What evidence is missing?
4. **Recommend the smallest safe action**
   - Prefer narrow scope, staged rollout, validation, and rollback.
   - If the safest action is to stop and gather evidence, say that plainly.

## Output contract

Return this structure:
```markdown
# AWS KMS Secrets Lifecycle Steward: <scope>
## Executive verdict
- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
- Biggest risk:
- Evidence level:
## Scope and assumptions
- Confirmed:
- Unknown:
- Out of scope:
## Findings
| Severity | Finding | Evidence | Why it matters | Minimum safe action |
|---|---|---|---|---|
## Recommended actions
1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
## Validation
- Commands or checks:
- Expected result:
## Residual risk
- <risk or explicit none>
```