Crypto Agility Plane SDK
Declare what you protect — never how. A central policy resolves the algorithm, post-quantum posture, key and backend at runtime.
The idea in one sentence
Developers declare a business intent — what data they protect and why — and never the algorithm, mode or key. The Crypto Agility Plane (CAP) resolves intent to algorithm/posture/key/backend at runtime from your tenant's central policy, post-quantum by default, and an AI/MCP control plane operates the whole thing from source code to production.
Deprecating a cipher or flipping an entire fleet to post-quantum becomes a policy edit — no recompile, no application code change.
The five pillars
Intent-based cryptography
Crypto without crypto code. The developer declares an intent; policy resolves it to a concrete algorithm, key and backend. Deprecating an algorithm is a policy edit, zero recompile.
PQC-native and hybrid by default
Hybrid post-quantum posture out of the box (ML-KEM, ML-DSA). Reuse DuoKey CPM (Cryptographic Posture Management), the CBOM and Quantum Readiness Score to plan and prove your migration.
AI / MCP control plane
An agent — or your IDE copilot — operates crypto in natural language across dev, CI and runtime: scan, decide, remediate and open a pull request.
Vendor-agnostic backends
One policy resolves to any supported KMS or HSM — Securosys, Azure Key Vault, AWS KMS, Google Cloud KMS, HashiCorp Vault, OpenBao — via PKCS#11 and KMIP.
Closed CBOM-to-runtime loop
Runtime telemetry of the crypto that actually ran is reconciled against the declared intent and the static CBOM. Drift raises an alert and a remediation plan.
Assured backend classes
CAP never holds key material itself — every policy resolves to an assured backend class: a FIPS 140-3 validated HSM/KMS, a PQC-capable backend, or an in-process tokenizer. Multi-Party Computation is available as an optional vault backend for tenants that require threshold key custody.
Core concepts
| Term | Meaning |
|---|---|
Intent | A data class (pan, cvv, pii, phi, credential, confidential) + a purpose (storage, transport, tokenize, sign) + an optional residency (eu, us, ch, global). |
Policy | A tenant-scoped, versioned rule set the security team owns. Maps intents to algorithm / posture / key / backend. Start from a standard template. |
Decision | What CAP resolves an intent to: algorithm, posture (classical / hybrid / pqc_only), backend and key reference. |
Drift | A runtime-observed algorithm weaker than the decision — surfaced by the closed CBOM-to-runtime loop. |
How it works
Declare intent
The developer states a data class and purpose in code — no algorithm, mode or key. In Java that is an annotation such as @Protect(dataClass = PII, purpose = SIGN, residency = EU).
Policy resolves
The tenant policy maps the intent to a concrete decision: algorithm, post-quantum posture, key reference and backend. The security team owns and versions this policy centrally.
Run on the resolved backend
The operation executes on the chosen KMS or HSM — sovereign, vendor-agnostic and audited. The same application code runs unchanged regardless of the resolved algorithm.
Observe and close the loop
The application reports what actually ran. CAP reconciles it against the policy decision and the CBOM; any drift triggers an alert and a remediation plan.
A minimal example
The SDK surface today is a small, imperative client — you ask CAP to resolve an intent, run the operation, and observe what actually ran. The intent is a data class + a purpose (+ optional residency); you never name an algorithm or key.
// The plane resolves HOW, at runtime, from central policy:
CapClient cap = new CapClient(baseUrl, capKey);
CapDecision d = cap.resolve("pii", "sign");
// d.algorithm() -> "hybrid-ml-dsa65-ecdsa-p256"
// d.posture() -> "hybrid" (post-quantum ready)
// d.quantumResistant() -> true
// ... sign with d.algorithm() using the policy-referenced key ...
// Close the loop: report what actually ran (drift detection).
cap.observe("pii", "sign", "ecdsa-p256", "payments-svc");A posture flip to post-quantum-only is a policy edit by the security team — this
code never changes; the next resolve(...) simply returns ml-dsa65.
Start from a standard policy
The security team can bootstrap a tenant policy from a built-in compliance template instead of authoring rules by hand:
| Template | Use case |
|---|---|
pci_dss_4 | PCI DSS 4.0 baseline for cardholder data. |
finma_ch | FINMA (Swiss financial sector). |
enisa_eu | ENISA (EU) guidance. |
cnsa_2_0 | NIST CNSA 2.0 (government / defense). |
fips_fedramp | FIPS 140-3 / FedRAMP. |
gdpr_pii | GDPR-oriented protection of personal data. |
Who it is for
Regulated enterprises
Banks, insurers, healthcare and government teams that must evidence crypto governance and a post-quantum migration path.
Platform and security teams
Teams that want to own cryptographic policy centrally and enforce it across many applications without touching each codebase.
Developers under a PQC mandate
Application teams that need to become quantum-ready without the in-house cryptography expertise to rewrite their code.
Availability
cap.enabled feature (Enterprise / Free Trial editions).