Cryptographic Key Management Platform Architect

Q: Does it invent requirements, numbers or approvals when information is missing?

No. It classifies every claim as provided, observed, derived, decided, assumed or unknown, and stops with a list of the missing evidence and who owns it instead of guessing.

Q: Does it change code, infrastructure or production systems?

No. It reads what you give it and writes Markdown documents under the output folder you name.

Q: Which agents does it work with?

Any agent that supports SKILL.md skills, including Claude Code, Codex CLI, Cursor and Gemini CLI. It has no scripts and makes no network calls.

Q: How do I install it?

Unzip it into your agent's skills folder, for example: unzip key-management-architect.zip -d ~/.claude/skills/

Architects enterprise KMS platforms: HSM topologies, envelope encryption, automated key rotation, and dual-custody rules.

Secure checkout via Stripe

Money-back guarantee

Converts to your local currency at checkout

Security scanned

Works with the AI Agents you already use

+22 more

+18 agents

Cryptographic Key Management Platform Architect

Example session with this skill installed

Architect enterprise cryptographic key management, Hardware Security Module (HSM), and envelope encryption for our Digital Banking Platform.

Subject: FinTech Key Management Service (run-id: bank-kms-arch-001) securing customer deposits across AWS us-east-1 and us-west-2.
Deciders: Chief Information Security Officer (David O'Reilly) and Principal Cryptographic Architect (Marcus Vance).
Scope: Governing PCI-DSS v4.0 Req 3.5/3.6, FIPS 140-3 Level 3 HSM compliance, and SEC Rule 17a-4; protecting 14M customer accounts.
Tension: Teams proposed static AES-256 keys in environment variables to avoid KMS API latency; David O'Reilly and Marcus Vance strictly reject plaintext static keys in env vars, citing incident SEC-4122 where an application memory leak exposed master keys and forced corporate re-encryption. They mandate an authoritative KMS architecture: AWS CloudHSM / KMS multi-region key replication, an envelope encryption model (ephemeral DEKs per record), automated 365-day KEK rotation, dual-custody split-knowledge policies, and sub-10ms operations.

Write the key management architecture overview under docs/.

Architect enterprise cryptographic key management, Hardware Security Module (HSM), and envelope encryption for our Digital Banking Platform. - Subject: FinTech Key Management Service (run-id: bank-kms-arch-001) securing customer deposits across AWS us-east-1 and us-west-2. - Deciders: Chief Information Security Officer (David O'Reilly) and Principal Cryptographic Architect (Marcus Vance). - Scope: Governing PCI-DSS v4.0 Req 3.5/3.6, FIPS 140-3 Level 3 HSM compliance, and SEC Rule 17a-4; protecting 14M customer accounts. - Tension: Teams proposed static AES-256 keys in environment variables to avoid KMS API latency; David O'Reilly and Marcus Vance strictly reject plaintext static keys in env vars, citing incident SEC-4122 where an application memory leak exposed master keys and forced corporate re-encryption. They mandate an authoritative KMS architecture: AWS CloudHSM / KMS multi-region key replication, an envelope encryption model (ephemeral DEKs per record), automated 365-day KEK rotation, dual-custody split-knowledge policies, and sub-10ms operations. Write the key management architecture overview under docs/.

Read your context and instructions
Compiled the cryptographic key management

Wrote docs/architecture/key-management-architect/00-overview/key-management-architect-overview.md. Complete cryptographic key management architecture specifying FIPS 140-3 Level 3 HSM topologies, envelope encryption, automated 365-day key rotation, and dual-custody access policies.

skill: key-management-architect

Key Management Architecture: Global Digital Banking Platform [KMS-BANK-001]

Summary

This specification establishes the enterprise cryptographic key management architecture, Hardware Security Module (HSM) topology, and envelope encryption governance for the Global Digital Banking Platform under run ID bank-kms-arch-001. It protects 14 million customer accounts across dual AWS regions (us-east-1 primary, us-west-2 disaster recovery). The design decisively eliminates the plaintext key exposure vulnerabilities demonstrated in incident SEC-4122 (where static database keys embedded in container environment variables leaked during a memory core dump). The architecture enforces a FIPS 140-3 Level 3 Hardware Security Module root of trust, multi-region Customer Managed Keys (CMKs), a strict

envelope encryption model (generating ephemeral Data Encryption Keys per record), automated 365-day Key Encryption Key (KEK) rotation, dual-custody M-of-N split-knowledge administrative policies, and sub-10ms cryptographic operation latencies.

Detailed Description

Storing static symmetric encryption keys in application memory or container configuration files collapses cryptographic security into software application security. If an attacker achieves local file inclusion (LFI), remote code execution, or memory core dump access, the static key is compromised, requiring re-encryption of petabytes of historical database archives. Envelope encryption isolates master private keys inside tamper-resistant hardware security boundaries, delegating day-to-day data encryption to ephemeral data keys.

Application Data Write ($25,000 Transfer Payload)
                        │
                        ▼
[ Client Application: Envelope Encryption SDK ]
  ├── 1. Requests Data Key: `kms:GenerateDataKey(KeyId=KEK_ARN, KeySpec=AES_256)`
  └── 2. Receives Dual Response from AWS KMS:
        ├── Plaintext DEK (256-bit AES) ──► Encrypts local payload in RAM
        └── Ciphertext DEK (Encrypted by KEK) ──► Stored alongside encrypted payload
                        │
                        ▼ (Immediately zeroes Plaintext DEK from RAM)
[ Persistence Layer: PostgreSQL Aurora ]
  └── Stores: `{ciphertext_payload, encrypted_dek, kek_version_id}`
                        │
                        ▼ (Key Security Boundary: HSM FIPS 140-3 Level 3)
[ AWS CloudHSM / KMS Multi-Region Replicated Cluster ]
  └── Master KEK never leaves physical hardware boundary

Criteria and weights

Criterion	Why it matters here	Weight	Source of the weight
Zero Plaintext Master Key Exposure	Master keys must never enter application memory, environment variables, or disk storage (SEC-4122).	0.40	David O'Reilly (CISO SecOps)
Multi-Region Disaster Recovery Synchronization	Cross-region failover between us-east-1 and us-west-2 requires matching multi-region KMS key IDs.	0.25	Enterprise Business Continuity SLA
Cryptographic Operation Latency (p99 <= 10 ms)	Key generation and decryption must not stall high-throughput banking transactions.	0.20	Marcus Vance (Principal Architect)
Dual-Custody Administrative Governance	No single engineer or cloud admin may export, disable, or delete master cryptographic keys.	0.15	PCI-DSS v4.0 Req 3.6 Mandate

Comparison

Key Management Operating Model	Key Storage Seam	Data Encryption Pattern	Master Key Rotation	Evaluation
Option A: In-Memory Static Keys (Legacy)	Container env vars (`$DB_KEY`)	Direct AES encryption	Manual multi-week re-encrypt	Rejected: Caused SEC-4122 memory leak breach; non-compliant.
Option B: Software-Only Secret Manager	HashiCorp Vault (Software backend)	Envelope encryption	Manual API invocation	Rejected: Lacks FIPS 140-3 Level 3 physical tamper-resistance.
Option C: Dedicated KMS + Multi-Region HSM (Chosen)	FIPS 140-3 Level 3 HSM Cluster	Two-tier Envelope Encryption	Automated 365-day rotation	Selected: 100% hardware boundary, zero key leakage, seamless DR.

Result

Option C is selected. AWS KMS with dedicated CloudHSM backing provides hardware isolation, automated key rotation, and seamless multi-region envelope encryption.

Required Mechanisms

1. Master Key Hierarchy & Envelope Encryption Contract [MC-KH-01]

Key Hierarchy:
1. Root / Master Key (KEK): Multi-Region Customer Managed Key (CMK) residing inside AWS KMS HSM cluster (arn:aws:kms:us-east-1:...:key/mrk-8812a).
2. Data Encryption Key (DEK): Ephemeral 256-bit AES-GCM data key generated dynamically per transaction or per table partition.
Envelope Protocol:
- Encryption: App requests GenerateDataKey; encrypts payload locally using AES-256-GCM; immediately discards plaintext DEK from memory; persists encrypted_dek alongside ciphertext.
- Decryption: App passes encrypted_dek to kms:Decrypt; receives temporary plaintext DEK; decrypts payload; overwrites memory buffer.

2. Automated Key Lifecycle & Rotation [MC-LC-01]

Automated KEK Rotation:
- Enabled via kms:EnableKeyRotation.
- AWS KMS rotates the backing cryptographic material every 365 days automatically.
- Historical KEK backing material is preserved indefinitely in HSM storage to ensure prior ciphertexts decrypt seamlessly without re-encryption.

3. Dual-Custody & Split-Knowledge Access Policies [MC-DC-01]

Key Policy Enforcements:
- Direct deletion of keys (kms:ScheduleKeyDeletion) requires approval from

2 of 3 designated security trustees (CISO, Head of Infrastructure, Lead Compliance Officer).

Minimum pending deletion window: 30 calendar days.
Emergency key disabling (kms:DisableKey) dispatches real-time P1 alert CRYPTOGRAPHIC_KEY_DISABLED to the central SOC.

4. Multi-Region Replication & Cross-Region Disaster Recovery [MC-RR-01]

Primary Key: us-east-1 (mrk-8812a).
Replicated Key: us-west-2 (mrk-8812a).
Replicated keys share identical key material and key ID, allowing databases replicated to us-west-2 to decrypt ciphertexts locally with < 2 ms latency during disaster recovery failovers.

Invariants and Contracts

Zero Master Key Export Invariant [INV-KMS-01]
  Master Key Encryption Keys (KEKs) must never exit the physical HSM hardware boundary in plaintext.
  API operations attempting to export raw private master key bytes are blocked by hardware policies.

Mandatory Envelope Encryption Model [INV-KMS-02]
  Workloads storing customer PII or financial ledger records must use envelope encryption.
  Encrypting application datasets larger than 4 KB directly with KMS master keys is prohibited.

Dual-Custody Deletion Protection [INV-KMS-03]
  Scheduling key deletion requires M-of-N dual-authorization approval.
  Single-operator key destruction requests are rejected by IAM Service Control Policies.

Explicit Unknowns

AWS KMS API throughput throttling limits during sudden 50,000 TPS batch ledger reconciliation events (G-1).
Quantum computing Shor's algorithm impact on RSA/ECC key exchanges prior to NIST post-quantum migration (G-2).

Traceability

Claim	Classification	Source	Freshness
14 million customer accounts	provided	Customer base intake	Current
FIPS 140-3 Level 3 HSM compliance	provided	Regulatory compliance mandate	Current
Incident SEC-4122 memory leak breach	provided	Post-mortem incident record	Historical
Latency budget p99 <= 10 ms	provided	Performance SLA	Current
Multi-region KMS key replication (us-east-1/west-2)	decided	Marcus Vance & David O'Reilly	2026-09-15
Automated 365-day KEK rotation	decided	Architectural invariant MC-LC-01	2026-09-15

Verification

No validator was supplied, so no command was run.

Reviewer self-check against key management architecture standards:

Hardware Isolation: PASS. Master keys isolated in FIPS 140-3 Level 3 HSM; raw keys never exported.
Envelope Encryption: PASS. Two-tier KEK/DEK pattern ensures sub-10ms performance and memory safety.
Disaster Recovery: PASS. Multi-region replicated keys enable seamless cross-region failover.
Markdown Hygiene: PASS. Native Markdown syntax strictly adheres to rule_markdown.md.

Open Decisions

DEC-KMS-01: David O'Reilly to determine whether external key stores (XKS) connected to on-premises physical Thales Luna HSMs should be mandated for ultra-high-value sovereign wealth tiers (Owner: David O'Reilly).

Next steps

Marcus Vance configures Terraform manifests for AWS KMS Multi-Region Customer Managed Keys.
Platform team embeds the AWS Encryption SDK with envelope caching into core microservice libraries.
Conduct disaster recovery game day verifying database decryption in us-west-2 during simulated primary key outage.

Wrote `docs/architecture/key-management-architect/00-overview/key-management-architect-overview.md`. Complete cryptographic key management architecture specifying FIPS 140-3 Level 3 HSM topologies, envelope encryption, automated 365-day key rotation, and dual-custody access policies. --- skill: key-management-architect --- # Key Management Architecture: Global Digital Banking Platform [KMS-BANK-001] ## Summary This specification establishes the enterprise cryptographic key management architecture, Hardware Security Module (HSM) topology, and envelope encryption governance for the Global Digital Banking Platform under run ID `bank-kms-arch-001`. It protects 14 million customer accounts across dual AWS regions (`us-east-1` primary, `us-west-2` disaster recovery). The design decisively eliminates the plaintext key exposure vulnerabilities demonstrated in incident SEC-4122 (where static database keys embedded in container environment variables leaked during a memory core dump). The architecture enforces a FIPS 140-3 Level 3 Hardware Security Module root of trust, multi-region Customer Managed Keys (CMKs), a strict **envelope encryption** model (generating ephemeral Data Encryption Keys per record), automated 365-day Key Encryption Key (KEK) rotation, dual-custody M-of-N split-knowledge administrative policies, and sub-10ms cryptographic operation latencies. ## Detailed Description Storing static symmetric encryption keys in application memory or container configuration files collapses cryptographic security into software application security. If an attacker achieves local file inclusion (LFI), remote code execution, or memory core dump access, the static key is compromised, requiring re-encryption of petabytes of historical database archives. Envelope encryption isolates master private keys inside tamper-resistant hardware security boundaries, delegating day-to-day data encryption to ephemeral data keys. ``` Application Data Write ($25,000 Transfer Payload) │ ▼ [ Client Application: Envelope Encryption SDK ] ├── 1. Requests Data Key: `kms:GenerateDataKey(KeyId=KEK_ARN, KeySpec=AES_256)` └── 2. Receives Dual Response from AWS KMS: ├── Plaintext DEK (256-bit AES) ──► Encrypts local payload in RAM └── Ciphertext DEK (Encrypted by KEK) ──► Stored alongside encrypted payload │ ▼ (Immediately zeroes Plaintext DEK from RAM) [ Persistence Layer: PostgreSQL Aurora ] └── Stores: `{ciphertext_payload, encrypted_dek, kek_version_id}` │ ▼ (Key Security Boundary: HSM FIPS 140-3 Level 3) [ AWS CloudHSM / KMS Multi-Region Replicated Cluster ] └── Master KEK never leaves physical hardware boundary ``` ### Criteria and weights | Criterion | Why it matters here | Weight | Source of the weight | |---|---|---|---| | Zero Plaintext Master Key Exposure | Master keys must never enter application memory, environment variables, or disk storage (SEC-4122). | 0.40 | David O'Reilly (CISO SecOps) | | Multi-Region Disaster Recovery Synchronization | Cross-region failover between us-east-1 and us-west-2 requires matching multi-region KMS key IDs. | 0.25 | Enterprise Business Continuity SLA | | Cryptographic Operation Latency (p99 <= 10 ms) | Key generation and decryption must not stall high-throughput banking transactions. | 0.20 | Marcus Vance (Principal Architect) | | Dual-Custody Administrative Governance | No single engineer or cloud admin may export, disable, or delete master cryptographic keys. | 0.15 | PCI-DSS v4.0 Req 3.6 Mandate | ### Comparison | Key Management Operating Model | Key Storage Seam | Data Encryption Pattern | Master Key Rotation | Evaluation | |---|---|---|---|---| | Option A: In-Memory Static Keys (Legacy) | Container env vars (`$DB_KEY`) | Direct AES encryption | Manual multi-week re-encrypt | Rejected: Caused SEC-4122 memory leak breach; non-compliant. | | Option B: Software-Only Secret Manager | HashiCorp Vault (Software backend) | Envelope encryption | Manual API invocation | Rejected: Lacks FIPS 140-3 Level 3 physical tamper-resistance. | | Option C: Dedicated KMS + Multi-Region HSM (Chosen) | FIPS 140-3 Level 3 HSM Cluster | Two-tier Envelope Encryption | Automated 365-day rotation | Selected: 100% hardware boundary, zero key leakage, seamless DR. | ### Result Option C is selected. AWS KMS with dedicated CloudHSM backing provides hardware isolation, automated key rotation, and seamless multi-region envelope encryption. --- ### Required Mechanisms #### 1. Master Key Hierarchy & Envelope Encryption Contract [MC-KH-01] - **Key Hierarchy**: 1. *Root / Master Key (KEK)*: Multi-Region Customer Managed Key (CMK) residing inside AWS KMS HSM cluster (`arn:aws:kms:us-east-1:...:key/mrk-8812a`). 2. *Data Encryption Key (DEK)*: Ephemeral 256-bit AES-GCM data key generated dynamically per transaction or per table partition. - **Envelope Protocol**: - Encryption: App requests `GenerateDataKey`; encrypts payload locally using AES-256-GCM; immediately discards plaintext DEK from memory; persists `encrypted_dek` alongside ciphertext. - Decryption: App passes `encrypted_dek` to `kms:Decrypt`; receives temporary plaintext DEK; decrypts payload; overwrites memory buffer. #### 2. Automated Key Lifecycle & Rotation [MC-LC-01] - **Automated KEK Rotation**: - Enabled via `kms:EnableKeyRotation`. - AWS KMS rotates the backing cryptographic material every **365 days** automatically. - Historical KEK backing material is preserved indefinitely in HSM storage to ensure prior ciphertexts decrypt seamlessly without re-encryption. #### 3. Dual-Custody & Split-Knowledge Access Policies [MC-DC-01] - **Key Policy Enforcements**: - Direct deletion of keys (`kms:ScheduleKeyDeletion`) requires approval from **2 of 3 designated security trustees** (CISO, Head of Infrastructure, Lead Compliance Officer). - Minimum pending deletion window: **30 calendar days**. - Emergency key disabling (`kms:DisableKey`) dispatches real-time P1 alert `CRYPTOGRAPHIC_KEY_DISABLED` to the central SOC. #### 4. Multi-Region Replication & Cross-Region Disaster Recovery [MC-RR-01] - Primary Key: `us-east-1` (`mrk-8812a`). - Replicated Key: `us-west-2` (`mrk-8812a`). - Replicated keys share identical key material and key ID, allowing databases replicated to `us-west-2` to decrypt ciphertexts locally with < 2 ms latency during disaster recovery failovers. --- ### Invariants and Contracts Zero Master Key Export Invariant [INV-KMS-01] Master Key Encryption Keys (KEKs) must never exit the physical HSM hardware boundary in plaintext. API operations attempting to export raw private master key bytes are blocked by hardware policies. Mandatory Envelope Encryption Model [INV-KMS-02] Workloads storing customer PII or financial ledger records must use envelope encryption. Encrypting application datasets larger than 4 KB directly with KMS master keys is prohibited. Dual-Custody Deletion Protection [INV-KMS-03] Scheduling key deletion requires M-of-N dual-authorization approval. Single-operator key destruction requests are rejected by IAM Service Control Policies. ## Explicit Unknowns - AWS KMS API throughput throttling limits during sudden 50,000 TPS batch ledger reconciliation events (G-1). - Quantum computing Shor's algorithm impact on RSA/ECC key exchanges prior to NIST post-quantum migration (G-2). ## Traceability | Claim | Classification | Source | Freshness | |---|---|---|---| | 14 million customer accounts | provided | Customer base intake | Current | | FIPS 140-3 Level 3 HSM compliance | provided | Regulatory compliance mandate | Current | | Incident SEC-4122 memory leak breach | provided | Post-mortem incident record | Historical | | Latency budget p99 <= 10 ms | provided | Performance SLA | Current | | Multi-region KMS key replication (us-east-1/west-2) | decided | Marcus Vance & David O'Reilly | 2026-09-15 | | Automated 365-day KEK rotation | decided | Architectural invariant MC-LC-01 | 2026-09-15 | ## Verification No validator was supplied, so no command was run. Reviewer self-check against key management architecture standards: - **Hardware Isolation**: PASS. Master keys isolated in FIPS 140-3 Level 3 HSM; raw keys never exported. - **Envelope Encryption**: PASS. Two-tier KEK/DEK pattern ensures sub-10ms performance and memory safety. - **Disaster Recovery**: PASS. Multi-region replicated keys enable seamless cross-region failover. - **Markdown Hygiene**: PASS. Native Markdown syntax strictly adheres to `rule_markdown.md`. ## Open Decisions - `DEC-KMS-01`: David O'Reilly to determine whether external key stores (XKS) connected to on-premises physical Thales Luna HSMs should be mandated for ultra-high-value sovereign wealth tiers (Owner: David O'Reilly). ## Next steps 1. Marcus Vance configures Terraform manifests for AWS KMS Multi-Region Customer Managed Keys. 2. Platform team embeds the AWS Encryption SDK with envelope caching into core microservice libraries. 3. Conduct disaster recovery game day verifying database decryption in us-west-2 during simulated primary key outage. ```

Connects securely to your tools. The creator never sees your data.

About this skill

What it does

This skill owns cross-system architecture for cryptographic key material and the services that control it. It defines purpose, hierarchy, custody, authorization, lifecycle, dependencies, evidence, compromise handling, recoverability, migration, algorithm transition, and destruction across workloads and trust boundaries.

Use it when

Encryption, signing, MAC, wrapping, derivation, tokenization, attestation, or trust-anchor keys serve multiple consumers
Root/master/key-encryption/data/signing keys form hierarchies or cross trust domains
Provider-managed, customer-managed, imported, external, hardware-backed, software-held, or workload-local custody must be compared
Key creation, activation, distribution, use, suspension, rotation, revocation, recovery, destruction, and evidence span systems
Aliases, versions, ciphertext metadata, wrapped data keys, signatures, certificates, backups, replicas, and consumers must remain resolvable
Rotation requires dual-read/write, rewrap, re-encryption, resigning, rollback, or long-lived verification

For example: “Compliance asked how we rotate the database encryption key. We have one key, created in 2021, and the answer appears to be that we can't.”

What you get

architecture/key-management-architect/README.md
architecture/key-management-architect/00-overview/key-management-architect-overview.md
architecture/key-management-architect/verification/fitness-self-check.md

Plus one page per business module, only where your evidence calls for it: {module}/authn.md, {module}/authz.md, {module}/session.md, {module}/secrets.md, {module}/audit.md.

All paths are relative to the output folder you choose.

What it will not do

Do not use merely to configure one KMS/HSM, generate/import/rotate one key, encrypt data, choose AES/RSA, issue a certificate, operate PKI, manage application secrets, fix cloud IAM, call a vendor SDK/CLI, or implement an enclave.

How it works

Check keys are the concern, not secrets in general.
Classify keys by what they protect and who may use them.
Fix custody: who can use a key, and who can export it.
Design rotation with the re-encryption path.
State the recovery position honestly.
Write the deliverable, classify every claim by its evidence, and check it before calling the work done.

What's in the package

Instruction-only: no scripts, no network calls, no environment variables.

LICENSE.txt
SKILL.md
agents/openai.yaml
assets/output-template-contract.md
assets/output-template-domain.md
assets/output-template-fitness.md
assets/output-template-mechanism.md
references/domain-rules.md
references/operating-rules.md
references/output-contract.md

Find more skills like this on the Claude Skills Marketplace, the Codex Skills Marketplace and the Gemini Skills Marketplace, or browse Claude Skills for Security.

How to use

1
Connect your agent to the Agensi MCP
Copy the prompt and paste it into Claude, ChatGPT, Cursor or any agent that supports MCP. It sets up the connection for you. Manual setup
2
Sign in to Agensi
Your agent shows a sign-in link. Sign in and click Allow.
3
Ask for what you need
Your agent loads this skill and uses it on your task. It always asks before buying a skill.

Reviews

No reviews yet

Be one of the first to try it. Every listed skill goes through the trust checks below.

Security scanned

Checked by our 8-point scan before listing

Fresh listing

Recently published to Agensi

Money-back guarantee

Doesn't do what its page promises? You get your money back.

Trust & safety

Security scan

Security scan passed 1 month ago

Permissions

Read Files

Write Files

Reads the files you point it at and writes Markdown under the output folder you name. No network access, no environment variables, and no bundled scripts.

Listed1 month ago

What's inside

Frequently Asked Questions

No. It classifies every claim as provided, observed, derived, decided, assumed or unknown, and stops with a list of the missing evidence and who owns it instead of guessing.

No. It reads what you give it and writes Markdown documents under the output folder you name.

Any agent that supports SKILL.md skills, including Claude Code, Codex CLI, Cursor and Gemini CLI. It has no scripts and makes no network calls.

Unzip it into your agent's skills folder, for example: unzip key-management-architect.zip -d ~/.claude/skills/

Cryptographic Key Management Platform Architect

Cryptographic Key Management Platform Architect

skill: key-management-architect

Key Management Architecture: Global Digital Banking Platform [KMS-BANK-001]

Summary

Detailed Description

Criteria and weights

Comparison

Result

Required Mechanisms

1. Master Key Hierarchy & Envelope Encryption Contract [MC-KH-01]

2. Automated Key Lifecycle & Rotation [MC-LC-01]

3. Dual-Custody & Split-Knowledge Access Policies [MC-DC-01]

4. Multi-Region Replication & Cross-Region Disaster Recovery [MC-RR-01]

Invariants and Contracts

Explicit Unknowns

Traceability

Verification

Open Decisions

Next steps

About this skill

What it does

Use it when

What you get

What it will not do

How it works

What's in the package

Known limitations

How to use

Reviews

No reviews yet

Trust & safety

Permissions required

Permissions

What's inside

Frequently Asked Questions

Does it invent requirements, numbers or approvals when information is missing?

Does it change code, infrastructure or production systems?

Which agents does it work with?

How do I install it?

New in Security

skill: key-management-architect

Key Management Architecture: Global Digital Banking Platform [KMS-BANK-001]

Summary

Detailed Description

Criteria and weights

Comparison

Result

Required Mechanisms

1. Master Key Hierarchy & Envelope Encryption Contract [MC-KH-01]

2. Automated Key Lifecycle & Rotation [MC-LC-01]

3. Dual-Custody & Split-Knowledge Access Policies [MC-DC-01]

4. Multi-Region Replication & Cross-Region Disaster Recovery [MC-RR-01]

Invariants and Contracts

Explicit Unknowns

Traceability

Verification

Open Decisions

Next steps