Beyond ML-KEM and ML-DSA
10 capabilities most PQC vendors don't talk about
Anyone can call an ML-KEM library. The hard work is the platform around it: attack-path graphs, Shamir-share key escrow, JIT access, federated audit chains, AI security layers, dual-provider cross-verification. Each capability below cites the file path that implements it — verify in the public mirror.
Public mirror: github.com/cuilabs/qnsp-public. Every file path on this page resolves there.
01 · Security monitoring
Attack-path graph analysis with automated remediation playbooks
Builds a directed graph of identities, roles, keys, and resources, then computes blast-radius for any compromise scenario. Each high-risk path can attach a playbook — invalidate sessions, rotate keys, quarantine workloads — that runs as a dry-run or live execution.
- Graph nodes: tenants, users, roles, service identities, KMS keys, vault secrets, storage buckets, AI workloads.
- Exploitability scoring uses real edge data — group memberships, role bindings, capability grants — not theoretical CVSS.
- Playbooks support a dry-run mode for change-control approval before live execution.
Code reference
apps/security-monitoring-service/src/routes/attack-path-analysis.ts + automated-response.ts
Available on
Business Advanced and above
02 · Audit & forensics
Merkle-tree audit ledger with federated aggregation
27 audit routes covering events, ledger checkpoints, receipts, retention, streaming, conformance, HIPAA evidence, and compliance reports. Every event hashes into a Merkle tree; checkpoints are signed with ML-DSA so a future investigator can prove the chain has not been tampered with — even if the storage backend is compromised.
- Merkle checkpoints on a configurable interval; checkpoint roots co-signed with ML-DSA-65 by default, ML-DSA-87 on Maximum tier.
- Federated audit aggregation across SAML / OIDC identity providers — events from multiple IdPs land in one tamper-evident timeline.
- Replay-from-receipt: any single audit receipt can be presented to the audit-service and the full surrounding ledger range is reconstructed and re-verified.
Code reference
apps/audit-service/src/routes/{events,ledger,checkpoints,receipts,streaming,retention,conformance,hipaa}.ts
Available on
All tiers (retention windows scale with tier)
03 · AI security
AI security layer — prompt injection, bias monitoring, model registry, cost budgeting
AI orchestrator routes for prompt-injection detection, model bias monitoring, model registry with provenance, inference + training cost budgeting, and enclave-isolated execution. Built for teams running LLM workloads who need the same audit and policy posture as the rest of the platform.
- Prompt-injection detection runs before inference; flagged prompts can be blocked, sandboxed, or sent for human review per tenant policy.
- Bias monitoring records per-model disparity ratios across protected classes and surfaces drift in the bias-monitoring summary endpoint.
- Model registry enforces signed-artifact provenance — only models with verifiable signatures can be promoted to production.
- Cost budgeting at inference and training time prevents tenant-level runaway spend.
Code reference
apps/ai-orchestrator/src/routes/{prompt-injection,bias-monitoring,model-registry,cost-optimization,enclaves,inference,workloads}.ts
Available on
Dev Pro and above (enclave AI on Enterprise)
04 · Crypto inventory
Quantum readiness scoring with peer benchmarking
Discovers cryptographic assets across the connected fleet, scores quantum readiness per asset, aggregates to an overall tenant score, and benchmarks anonymously against industry peers in your sector and size band.
- 23 inventory routes including agents, asset discovery, host-agent reports, TLS observations, certificate lifecycle, algorithm deprecation, and migration planning.
- Readiness score factors in algorithm strength, key length, rotation cadence, and known weaknesses (e.g. SHA-1 still in use).
- CycloneDX-format CBOM exports for security-team consumption and SBOM tooling integration.
Code reference
apps/crypto-inventory-service/src/routes/{pqc-readiness-score,nist-compliance,cbom,migration-plan,algorithm-deprecation,tls-observations}.ts
Available on
Business Team and above
05 · Cryptographic Bill of Materials
Comprehensive CBOM in CycloneDX format
Most vendors ship a list of TLS-cipher-suites and call it a CBOM. QNSP discovers cryptographic assets across application code, container images, runtime processes, TLS endpoints, signed artifacts, KMS-managed keys, vault secrets, and connected cloud accounts — and emits CycloneDX-compatible JSON your existing SBOM tooling can consume.
- Discovery agents run inside the customer's environment and report findings back via signed channels.
- Migration planning uses the CBOM to sequence which assets to migrate first based on data-lifetime risk.
- Evidence pack route bundles CBOM + readiness score + audit receipts into a single signed artifact suitable for compliance reviews.
Code reference
apps/crypto-inventory-service/src/routes/{cbom,evidence-pack,host-agent-reports,connected-sources,connector-configs}.ts
Available on
Business Advanced and above
06 · Platform reliability
Multi-tier L1/L2 cache, self-tuning scheduler, chaos testing
Three internal packages most platform vendors don't bother shipping: a multi-tier cache (in-memory L1 + Redis L2) with consistency guarantees, a self-tuning scheduler that tracks p99 and adjusts work-shape, and a chaos-testing harness used in CI to confirm services degrade gracefully.
- Multi-tier cache supports write-through, write-behind, and refresh-ahead modes — picked per call site based on staleness tolerance.
- Self-tuning records p50 / p95 / p99 latency per work category and re-balances batch sizes / concurrency.
- Chaos-testing harness injects latency, partial failures, and dependency outages during integration tests.
Code reference
packages/cache/src/multi-tier-cache.ts + packages/self-tuning/src/index.ts + packages/chaos-testing/src/index.ts
Available on
Internal — every customer benefits transparently
07 · Access control
Policy simulation engine — test before you ship
Before a policy change goes live, simulate it against the last N days of real access events and see exactly which requests would have been allowed or denied. Catches over-permissive draft policies and accidental denial-of-self before they reach production.
- Replay against historical access events — last 24h, 7d, 30d windows.
- Per-principal impact summary: how many requests this principal would lose access to.
- Diff view between current and proposed policy with the access-event delta inline.
Code reference
apps/access-control-service/src/routes/policy-simulation.ts + apps/cloud/app/api/access/simulation/{run,impact,history}/route.ts
Available on
Policy Simulation Pack add-on (or Business Advanced and above)
08 · Access control
Just-in-time access with ephemeral grants
Standing privileges are the largest single source of breach blast-radius. JIT access lets a principal request a time-bounded elevation; the grant is signed, scoped to a minimal capability set, and auto-expires. Every grant is a first-class audit event.
- Approval workflows: auto-approve for low-risk capabilities, multi-party for high-risk.
- Default TTL ceilings per capability tier — long-lived grants require sign-off and emit a high-severity audit event.
- Grant revocation propagates within the cache TTL across all PDP instances.
Code reference
apps/access-control-service/src/routes/jit-access.ts + apps/access-control-service/src/routes/zero-trust.ts
Available on
Business Advanced and above
09 · Key management
Key escrow + Shamir M-of-N recovery
For high-value root keys (vault unseal keys, tenant master keys, signing keys for long-lived audit chains) QNSP supports Shamir secret sharing — split into N shares, require M to reconstruct, distribute to your governance officers. Recovery is auditable and requires explicit M-of-N approval, not a single break-glass admin.
- Configurable N (total shares) and M (threshold) per escrowed key.
- Share holders can be human governance officers, HSM-backed identities, or partner-organisation custody.
- Recovery process emits high-severity audit events and requires PQC-signed approval from each share holder.
Code reference
apps/kms-service/src/routes/key-escrow.ts + apps/kms-service/src/routes/byohsm.ts
Available on
Enterprise Standard and above
10 · Cryptographic assurance
Cross-verification between two independent PQC providers
QNSP runs two independent PQC implementations side-by-side: liboqs (native C, 89 algorithms across 14 families) and @noble/post-quantum (pure-JavaScript, 18 NIST-finalised algorithms). On Maximum and Government tiers, every signature operation is verified by both implementations and the result is recorded in the audit ledger. A bug in one implementation is caught by the other.
- 18 algorithms overlap between liboqs and noble — 3 KEMs (ML-KEM-512/768/1024) and 15 signatures (ML-DSA-44/65/87, FN-DSA, all SLH-DSA variants).
- Cross-verification is mandatory on Maximum and Government tiers, optional on Strict, and can be enabled per-key on lower tiers.
- Provider attestation — which provider signed, which verified — flows into the audit event so a future investigator can reproduce the operation.
Code reference
packages/cryptography/src/cross-verification.ts + packages/cryptography/src/providers/{liboqs,noble}.ts + packages/security/src/crypto-policy.ts
Available on
Optional on Strict; mandatory on Maximum and Government
See the platform
Every capability above is in the codebase you can read
The QNSP platform isn't just a PQC library wrapper. It's the audit chain, the access model, the AI security layer, the chaos-tested platform packages, and the operational muscle around them — all in one place, all auditable.