Skip to main content
HUMΛN
HUMΛN
←Community
Security
Security

Trust that survives cryptographic change

HUMΛN Team··9 min·Enterprise + technical

The RFP that asks the wrong question

Security questionnaires still land with a checkbox that reads like a spell: Are you quantum-proof?

Say yes and you have made a promise no protocol stack can keep on every device, every passkey ceremony, every legacy verifier overnight. Say no and the buyer hears “unready,” even when your actual architecture — identity continuity, signed provenance, algorithm agility — is what will keep their trust layer alive when the algorithms change.

The useful question is narrower and harder: can your trust layer survive cryptographic change without breaking Passport continuity, shredding HumanOS decision receipts, or trapping you in a single-algorithm corner?

What breaks when crypto is a slogan

When an agent acts under a delegation, the Monday morning review is not “which model.” It is: which Passport signed, under which grant, with which suite, and can we still verify the receipt five years from now?

If signatures are opaque blobs with no suite metadata, a forced algorithm migration orphans your audit trail. If every deployment silently shares one verifier policy, a regulated tenant’s upgrade becomes everyone else’s outage. If marketing sold “future-proof forever,” the first hybrid transition looks like a product lie.

That is the pain. Not physics posters about qubits — continuity of identity and provenance under suite change.

What HUMΛN does instead

We are crypto-agile by design — classical-secure today, migration-ready by construction:

  1. Classical-secure today — Production paths use modern, widely deployed algorithms appropriate to current threats and devices. Passport signing and day-to-day verification do not wait on experimental post-quantum UX.
  2. Explicit metadata — Signed objects carry enough information (suite / algorithm, key references, versions) to verify under documented policies across mixed eras. A receipt is not “trust us”; it is verify-under-policy.
  3. Profile-based policy — Consumer, enterprise, self-hosted regulated, and government-grade deployments do not share identical cryptographic requirements on day one. Stricter modes are opt-in; we do not silently tighten verifier behavior on upgrade.
  4. Hybrid and PQ-native are selective — Where trust must last many years (key wrapping, some service-to-service channels, high-assurance artifacts), we make room for hybrid and post-quantum transitions without forcing every passkey flow into experimental crypto.

Passport holds identity continuity. HumanOS and provenance hold the decision receipt story. Crypto agility is the substrate that keeps both meaningful when curves age out.

What we will not say

We avoid “quantum-proof,” “unbreakable,” and “future-proof forever.” Those claims age badly and mis-set expectations. We talk about migration readiness, trust continuity, and algorithm agility — the infrastructure properties serious enterprises actually need when the RFP checkbox is theater.

Scroll-stopper: Quantum theater asks if you are immune. Crypto agility asks if your Passports and receipts still verify after the suite changes.

Progressive honesty, not silent leaps

Intermediate steps — hybrid where it matters, classical where devices demand it, named deviation blocks when a path is still tightening — stay grepable. That is the same progressive honesty we apply to selective disclosure and guardian recovery: name the gap, schedule the burn-down, refuse marketing that pretends the migration is already done everywhere.

Where to read the normative spec

Internal and partner-facing Canon: kb/172 (strategy), kb/173 (suite registry and migration verbs), kb/174 (deployment profiles). Developer guides live under docs/post-quantum-*.md in the HUMΛN repository.

Bottom line

The trust layer between humans and AI has to last longer than any one elliptic curve. HUMΛN is building for that boring, hard requirement — without pretending the transition is already done everywhere.

So that the next RFP answer is honest: not “immune,” but ready to migrate without orphaning who acted under which grant.

Go deeper

Code & Docs

Verify Offline

Pattern