This is a Foundation deep-dive. Read P1 first for the bigger picture. Here we look closely at one specific safety feature: the encryption keys that lock our data, and why we have three of them instead of one.
A KMS key is a master encryption key that AWS holds inside hardened hardware (you cannot extract it; not even AWS staff can read it directly). When we say "the data is encrypted with KMS," every read of that data goes through AWS asking, "is this caller allowed to use this key?" If yes, AWS decrypts on the fly and hands back the data. If no, the caller gets garbage bytes. The key itself never leaves the AWS vault.
This gives us four things for free:
| What we get | What it means in practice |
|---|---|
| Defense in depth | Even if someone got network access to our S3 bucket, they would see ciphertext. They would need separate IAM permission to use the KMS key to make it readable. Two locks on one door. |
| Audit trail | Every key use is logged in CloudTrail. "On Tuesday at 14:32, role X used key Y to decrypt object Z." Auditors love this. |
| Operator separation | The people who can read data are not the same as the people who manage the key. The data engineer cannot grant herself decrypt; that needs the KMS policy and an admin to change it. |
| Compliance hook | Auditors can point at the KMS key policy and see exactly who can decrypt. They do not have to trust our application code. |
Back to the playground. Imagine three safes inside the maintenance shed. Each safe has its own lock. Each lock has its own list of who can open it.
Things our AI agents work with: cartridge state, chatbot conversation logs, narrative drafts, scheduled job history. Anything where it is OK for an agent to see plaintext while doing its job.
Who can open it: the cartridge Lambdas, running as the agent role.PII tokens. When we eventually accept regulated data, the actual PII lives here. Agents never get the key to this safe; they work on tokens that point at PII without containing it. The token can travel; the PII cannot leave the safe without an explicit audited request.
Who can open it: a separate, audited service whose only job is to swap tokens for PII on authorized calls.The security camera footage. CloudTrail destinations, GuardDuty findings, the immutable record of who did what. Even the platform operators cannot quietly tamper with this.
Who can open it: only systems that write the audit logs, and only auditors who read them.The whole point of having three is that the agent role cannot open the lockbox safe, and the lockbox role cannot open the audit safe. If we used a single key for all three, a compromise of any one role would expose everything.
The three keys also let us tell three different stories:
A single-key shop has to defend "yes, anyone with that one key can decrypt anything." Auditors push back hard on that, and rightly so.
A bigger shop might have one key per data class, per environment, per tier. That sounds responsible until you realize key sprawl produces incidents of its own: rotation gaps, access policy drift, "which key did we use for this object" confusion.
Three keys is what we need to enforce the trust boundaries we actually have. More would be ceremony without marginal safety.
Mostly yes, with one specific thing AWS is upgrading industry-wide on our behalf. Quick mapping back to the playground:
Quantum-resistant today. The locks themselves use AES-256, which the best published quantum analysis says is safe for long-term storage. Even if someone built a quantum computer tomorrow, the locks would hold.
Quantum-resistant today. The master keys never leave AWS's tamper-resistant hardware. There is nothing for a quantum attacker to grab. No exposed public key to factor.
Industry-wide upgrade in flight. Today the hallway uses classical TLS, which a quantum computer could in principle eavesdrop on far in the future. AWS is already rolling out hybrid post-quantum TLS (ML-KEM / Kyber) on the services we use. We do not write any of this code ourselves; we get the upgrade automatically as AWS deploys it.
Nobody has a useful quantum computer today, and estimates for when (or whether) one arrives range from a decade to never. The realistic concern is that someone records our encrypted traffic now and decrypts it in 20 years when quantum is available. That's the threat AWS's hybrid-PQ rollout addresses for everything in transit. For everything at rest, AES-256 already covers us.
The summary an executive can deliver in one sentence: the safes are post-quantum safe; AWS is upgrading the hallways and we get those upgrades for free; PayCargo is not custodian of any cryptographic key whose break would put us at risk.
So no, this is not too complicated. It is the simplest design that protects what we have to protect. If anything, defend it when someone asks why we did not "just use defaults."
| If we skipped | What would happen |
|---|---|
| Three keys, used one | A single compromised role exposes every data class. A bad day becomes a catastrophic day. |
| Customer-managed, used AWS-managed | Auditors ask "show me who decrypted what." We say "we cannot, AWS owns those keys." That answer fails. |
| Encrypted at rest at all | Either compliance refuses to certify us, or one network misstep exposes plaintext data across S3, DynamoDB, Secrets Manager. Either way the answer is the same. |
The three keys cost us about $3 per month. Pennies for a non-negotiable audit and isolation story.
When someone asks "why do you have three keys," the short version: "Three trust zones, three locks. Agents can read agent data. Lockbox can swap tokens for PII through an audited gate. Auditors can write to the audit log but cannot read sensitive data. Each zone is independently locked, so a compromise of one role does not leak the others. Costs us $3 a month and saves us in every audit."
KMS engineering depth lives in Step 4.5.a (data governance CMKs: the tier × org grid), which spells out the key policies, IAM grants, and the lockbox pattern. The quantum-resistance audit answer is in Step 4.5.a section 12 with the per-layer AES-256 / TLS / JWT analysis. P1 Foundation covers the rest of the safety features that surround the locks.