Use AWS KMS EncryptionContext as additional authenticated data to bind ciphertext to its context
domain: docs.aws.amazon.com · 6 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Design an EncryptionContext map whose key-value pairs uniquely identify the data being protected (e.g., {"purpose": "user-record", "userId": "<identifier>"}); avoid embedding sensitive values in context because it appears in CloudTrail logs
Supply the EncryptionContext in every Encrypt, GenerateDataKey, or GenerateDataKeyWithoutPlaintext call
Store the EncryptionContext alongside the ciphertext (it is not secret) so that decryption code can reconstruct and pass it to Decrypt
At decrypt time, pass the identical EncryptionContext; KMS will reject the request if the context does not match, preventing ciphertext misuse across contexts
Use CloudTrail to audit that all KMS calls include expected EncryptionContext keys; alert on calls missing the context
Document the EncryptionContext schema as part of your data format versioning so future code changes do not break decryption
Known gotchas
EncryptionContext is logged in plaintext in CloudTrail; never include passwords, tokens, or PII as context values
The context is order-insensitive for cryptographic purposes but must contain the exact same key-value pairs; a missing or extra entry causes decryption failure
EncryptionContext does not encrypt the context itself; it is additional authenticated data bound to the ciphertext, not a secret
Give your agent this knowledge — and 15,600+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?