Explore (579)Live Systems (52)Pricing
Log InGet API Key✓ Verify It Yourself
H33-VaultH33-ShareH33-ShieldH33-HealthH33-KeyH33-128H33-CKKSH33-256H33-FHE-IQH33-TFHEFHE OverviewH33-CompileZK LookupsBiometricsH33-3-KeyH33-MPCZK-TrustlessZK-PhishZK-VerifyPQC ArchitecturePQ Video

Your keys are one breach from becoming weapons. All of them.

Related · tier-1 reading. For what a portable artifact actually is, see Portable Artifact.

API tokens in .env files. SSH keys on disk. Database passwords in config. JWT signing secrets in systemd unit files. Stripe sk_live keys handed to thirty engineers via a Slack thread. Every key in your infrastructure sits one credential dump from catastrophic compromise — and once they leak, every subsequent use is indistinguishable from legitimate traffic.

H33-Key is not secret storage. It is authority control.
Storage asks: Where is the key?
H33-Key asks: What is this key allowed to do, under what state, for how long, for whom — and can every use be independently replayed?

Get an API Key

Available now · Node + Rust SDKs + hkey CLI

Most API key infrastructure is fundamentally broken.

Static secrets sitting in config files holding state secrets. Manual rotations — what century are we in? Global authority scopes with no replayability if something goes wrong. No proof of misuse. No cryptographic continuity across rotations. That model does not survive AI-scale systems or post-quantum threat environments — and quite frankly, it sucks without AI or quantum threats.

When the inevitable leak happens, the existing playbook is: rotate everything by hand on a Saturday, hope nothing was used, and accept that the audit trail is a centralized narrative you cannot independently verify.

So we fixed it. Because we can.

Ten primitives. One coherent authority model.

Every primitive is independently verifiable, post-quantum attested, and composable with the others. None of them require trusting H33’s narrative about what happened.

01 · Time-Bound
Authority Expires
Every authority object carries an explicit TTL. After expiration, the receipt corpus refuses to validate further use. No long-lived bearer tokens. No “forgot to rotate” failure mode.
02 · State-Scoped
Bound to Context
An authority is valid only within its declared state: tenant, route, region, environment, dataset. Same secret, used in the wrong state, fails the cryptographic check — not the policy layer.
03 · Computation-Bound
Authorizes One Operation
A signing authority authorizes signing. A charge authority authorizes a charge under specified bounds. Cross-use is mathematically rejected. Leaked authority cannot be repurposed.
04 · Delegation Chains
Least-Privilege Downstream
A service can issue a strictly narrower child authority to a worker, for a single route, for a single request. The chain is cryptographically provable end-to-end. The parent scope dominates — the child cannot exceed it.
05 · Break-Glass
Pre-Scoped Emergency
Emergency authority exists, but it is never unconstrained. Pre-scoped envelope, mandatory multi-party approval, fifteen-minute default TTL, and an automatic review fires the moment it issues. Break-glass is logged before it is used.
06 · Revocation Proofs
Provable Death
Rotation is not enough. Every revocation produces a cryptographic attestation: when the authority died, who killed it, and the receipt corpus refuses every subsequent attempt. Forensic narrative without trust.
07 · Negative Proofs
Provable Non-Use
Prove this authority has not been used at X. Critical after a leak: rather than panicking that a credential is compromised, you cryptographically demonstrate that no unauthorized use occurred in the exposure window.
08 · Continuity
Receipts Outlast Rotations
A receipt issued under JWT_SECRET v1 remains independently verifiable forever, even after v2, v3, v4 replace it. Rotation generates a continuity proof linking generations. Audit trails do not break on rotation — they extend.
09 · Independent Verifier
Don’t Trust Our Narrative
The conformance specification is published. Your auditor, your insurer, your regulator, a competing vendor — any of them can build a verifier that reconstructs any authority decision from the 74-byte receipts alone.
10 · Observe Mode
Policy Simulation
Run H33-Key in shadow before enforcing. Every authority decision is logged with its full receipt, but no upstream call is blocked. See exactly what would have been denied, rotated, scoped, or flagged. Then flip to enforce when you’re ready.

Here’s what happens every time a key is used.

Stage 01 — Authority Issued
A Q-Key authority object, not a static string
The issuing service declares the computation, the scope (tenant, route, counterparty, bounds), and the TTL. H33-Key emits a Q-Key authority object cryptographically committed to those declarations. The object is hostile to repurposing — same authority used outside its computation or state fails the cryptographic check, not the policy layer. Three independent post-quantum signature families (ML-DSA-65 + FALCON-512 + SPHINCS+-SHA2-128f) protect the issuance commitment.
The issuing service declares the computation, the scope (tenant, route, counterparty, bounds), and the TTL. H33-Key emits a Q-Key authority object cryptographically committed to those declarations. The object is hostile to repurposing — same authority used outside its computation or state fails the cryptographic check, not the policy layer. Three independent post-quantum signature families (ML-DSA-65 + FALCON-512 + SPHINCS+-SHA2-128f) protect the issuance commitment.
Stage 02 — Use Attested
Every use emits a 74-byte H33-74 receipt
When the authority is exercised, H33-Key writes a 74-byte H33-74 substrate commitment: 32 bytes on-chain, 42 bytes in the receipt corpus. The receipt binds the authority object, the actual operation performed, the counterparty, and the exact timestamp. 285× distillation of a 21KB ephemeral PQ signature bundle — small enough to log every single operation forever.
When the authority is exercised, H33-Key writes a 74-byte H33-74 substrate commitment: 32 bytes on-chain, 42 bytes in the receipt corpus. The receipt binds the authority object, the actual operation performed, the counterparty, and the exact timestamp. 285× distillation of a 21KB ephemeral PQ signature bundle — small enough to log every single operation forever.
Stage 03 — Anomaly Detected
Negative proofs flag misuse in real time
Every use is checked against the authority’s declared scope and against the global non-use proofs of all other authorities. If the use falls outside scope — wrong tenant, wrong computation, wrong counterparty, after expiry — the call is denied and an anomaly receipt fires. Real-time, not end-of-week SIEM review.
Every use is checked against the authority’s declared scope and against the global non-use proofs of all other authorities. If the use falls outside scope — wrong tenant, wrong computation, wrong counterparty, after expiry — the call is denied and an anomaly receipt fires. Real-time, not end-of-week SIEM review.
Stage 04 — Replay-Grade Audit
Independently reconstructable forever
The receipt joins the canonical replay frame — the immutable conformance corpus. Anyone with the published conformance specification can rebuild the verifier and independently reconstruct the entire authority decision: what was authorized, what was used, what was denied, when, by whom. H33’s narrative is verifiable, not load-bearing.
The receipt joins the canonical replay frame — the immutable conformance corpus. Anyone with the published conformance specification can rebuild the verifier and independently reconstruct the entire authority decision: what was authorized, what was used, what was denied, when, by whom. H33’s narrative is verifiable, not load-bearing.
< 0.5 ms
per authority issue + attest + verify cycle

Q-Key authority issue + H33-74 receipt + negative-proof check + replay-corpus commit — all under half a millisecond. Light enough to wrap every Stripe call, every JWT sign, every database write.

Four cryptographic stages — under half a millisecond.

STAGE 1  Authority Issued (Q-Key)
STAGE 2  Use Attested (74-byte H33-74 receipt)
STAGE 3  Anomaly Checked (negative proof)
STAGE 4  Replay Corpus Committed
Total: —
Authority Lifecycle Pipeline

We don’t pretend we control your counterparties.

Stripe’s API server requires sk_live_… in plaintext. Twilio requires plaintext. Google OAuth requires plaintext. They don’t speak Q-Key. Anyone claiming to FHE-wrap a Stripe charging key is selling theater — the decryption point still has to happen at call time.

So we drew a hard, honest line through the credential surface:

Internal Authority
Full Q-Key
Any credential you control end-to-end — JWT signing secrets, per-tenant API keys, admin tokens, internal service keys, signing materials — becomes a Q-Key authority object. Time-bound, state-scoped, computation-bound. Static strings disappear from your config.
External Counterparty
Envelope + Attested Use
Credentials a third party requires in plaintext (Stripe, Twilio, OAuth) get KMS envelope encryption at rest plus H33-74 receipt logging at every use. Plaintext exists only inside a TEE or in process memory for the milliseconds of the API call. Every use generates a 74-byte PQ receipt — leak abuse is detectable in real time.

The honesty is the differentiator. Vendors that overclaim get caught at audit time. H33-Key tells you which credentials are mathematically protected and which are operationally protected — and why the distinction matters.

Don’t trust our narrative. Reconstruct any action yourself.

Every other key-management vendor asks you to trust their dashboard. H33-Key publishes the conformance specification — your auditor, your insurer, your regulator, or a competing implementation can build their own verifier and reconstruct any authority decision from the 74-byte receipts alone.

Conformance Spec
Published & Frozen
The deterministic conformance verification specification is open. Receipt format, canonical replay frame, structured rejection semantics, replay-integrity classification — all documented. New independent verifier implementations are welcomed.
Immutable Corpus
Receipts Never Disappear
The canonical replay frame is append-only. Once a receipt enters the corpus, it stays. Compaction, rotation, even H33 going dark cannot remove receipts — they’re anchored across three independent PQ signature families that no single party can revoke.
Verifier Equivalence
H33 Has No Special Privilege
If H33’s substrate disagrees with an independent verifier on whether a receipt is valid — the receipt wins. The conformance specification is the canonical truth. H33 implements the same spec everyone else does, with no hidden side channel.

This is what “replay-grade attestation” actually means: not a log file H33 promises is real, but a cryptographic corpus that any independently competent party can verify without us.

Adoption in three stages. Reversible at every step.

No big bang. No enforcement before you understand what it would deny. No leaving an audit gap when you start.

Stage 01 — Observe
Policy Simulation, No Enforcement
Wire the SDK in observe mode. Every authority issue, attest, verify, and deny decision is logged with its full 74-byte receipt — but no upstream call is ever blocked. After a week, you have a complete shadow record of what would have been denied, rotated, scoped, or flagged. Tune the policy. No risk to production.
Stage 02 — Enforce
Deny Outside Scope
Flip the SDK to enforce. Authority objects now block out-of-scope uses cryptographically. The receipt corpus is the same one you built in observe mode — no audit discontinuity. Roll forward and back as needed; per-tenant, per-route, per-computation granularity means no all-or-nothing flag.
Stage 03 — Replay
Independently Reconstruct Any Action
After an incident, an audit, a regulator request — pull the receipts for the window and reconstruct exactly what happened. The independent verifier proves: which authority was used, for which operation, at which moment, against which counterparty, and whether anomaly checks fired. No log-tampering risk. No vendor-side narrative.

Three lines. Every key use becomes an attested authority action.

Node + Rust SDKs ship at GA. Python and Go follow. The hkey CLI is the same surface from your terminal — issue, attest, verify, observe, revoke, replay.

Node.js · @h33/keynpm i @h33/key
import { HKey } from '@h33/key';
const hkey = new HKey({ apiKey: process.env.H33_KEY });

// 1. Issue a time-bound, scope-bound, computation-bound authority object
const auth = await hkey.issue({
  computation: 'stripe.charge',
  scope:       { tenant: 'h33', amount_max_usd: 5000 },
  ttl:         '15m',
});

// 2. Use it. Every use emits a 74-byte H33-74 receipt.
const { result, receipt } = await hkey.attest(auth, async (key) => {
  return stripe.charges.create({ amount: 4200, source: 'tok_...' }, key);
});

// 3. Independent verifier — anyone can replay.
const ok = await hkey.verify(receipt);
console.log(receipt.bytes.length, ok); // 74, true
Rust · h33-keycargo add h33-key
use h33_key::{HKey, IssueRequest, Scope, Duration};

let hkey = HKey::from_env()?;

// Issue a time-bound, scope-bound authority object
let auth = hkey.issue(IssueRequest {
    computation: "stripe.charge",
    scope:       Scope::new().tenant("h33").amount_max_usd(5000),
    ttl:         Duration::minutes(15),
}).await?;

// Use it. Every use emits a 74-byte H33-74 receipt.
let (result, receipt) = hkey.attest(&auth, |key| async move {
    stripe::charges::create(&key, 4200, "tok_...").await
}).await?;

// Independent verifier — anyone can replay.
assert!(hkey.verify(&receipt).await?);
Terminal · hkeybrew install h33/tap/hkey
$ hkey issue --computation stripe.charge \
              --scope tenant=h33,amount_max_usd=5000 \
              --ttl 15m
auth_01h_x9p2qm8c7v3kfn5tg6d2yr8bw0...

$ hkey attest auth_01h_x9p2qm... -- stripe charges create --amount 4200
receipt: 0xab12cf... (74 bytes)
verified: ok

$ hkey verify 0xab12cf...
ok — issued 2026-05-25T03:14:00Z, used 2026-05-25T03:14:02Z,
     scope=stripe.charge[tenant=h33], anomalies=0

$ hkey observe --window 1h --tenant h33
would-have-denied: 3 (2 wrong-tenant, 1 expired authority)
attested-ok:      1,847
anomalies-flagged: 0

Every credential in your infrastructure deserves an authority object.

Database Credentials
Encrypt connection strings in-place. No application change. Your ORM reads the same config — H33-Key transparently decrypts at point of use.
SSH Keys & Certificates
Wrap private keys at rest with Kyber-1024 envelope. Decrypt on-demand at point of use. Compromised disk yields only ciphertext.
API Tokens & Service Accounts
PQ-encrypt CI/CD secrets, cloud provider keys, third-party tokens. Rotate envelopes without invalidating the underlying credentials.
TLS Certificate Private Keys
Protect cert private keys with Kyber envelope. Auto-rotate envelope on schedule. The certificate stays valid while the encryption layer refreshes.
Crypto Wallet & Signing Keys
Wrap blockchain private keys, HD wallet seeds, and signing keys with Kyber-1024 encryption. Hot wallets stay operational while keys stay quantum-safe. Threshold decryption (Key-3) adds k-of-n multisig-grade approval before any signing key is released.

Five minutes from npm install to your first attested authority.

No infrastructure to deploy. No agents to install. Start in observe mode — no enforcement until you flip the switch.

Step 01
Get Your API Key
Sign up at /pricing, select the Key tab, choose a unit pack. API key provisioned instantly. No credit card required for free tier.
Step 02
Encrypt Your First Key
One API call to POST /v1/key/encrypt with your key material. Store the returned ciphertext wherever the plaintext used to live — .env file, database column, CI/CD variable, Kubernetes secret.
Step 03
Decrypt at Point of Use
Call POST /v1/key/decrypt when your app needs the key. Set a TTL so plaintext auto-zeroes from memory after use. Your app code changes are minimal — one decrypt call at startup.
Step 04
Scale with SDKs
Production SDKs for Node.js, Python, Go, and Rust handle caching within TTL windows and provide framework middleware. Docker sidecar available for environments you cannot modify — intercepts env var reads and transparently decrypts.

Zero-Exposure Infrastructure

Every secrets manager on the market decrypts the key before handing it to you. H33-Key doesn’t.

H33-Gateway NEW

TEE proxy — your infrastructure never touches plaintext. Your app sends an encrypted key + request. Gateway decrypts inside a Trusted Execution Environment, forwards the API call to the third-party service, zeroes the plaintext, and returns the response. At no point does your infrastructure — or ours — see the key in the clear.

Healthcare
A hospital where an Epic EHR credential sits in plaintext in a Jenkins env var. Every CI/CD run exposes it. Every developer with pipeline access can read it. With Gateway, Jenkins stores the Kyber-encrypted credential. The API call routes through the TEE. The plaintext credential never exists outside the enclave.
Financial Services
A bank where Stripe API keys live in a config file that 40 engineers can read. One compromised laptop, one misconfigured S3 bucket, one leaked .env — and those keys are in the wild. With Gateway, the config stores ciphertext. Payment API calls route through the TEE. Zero engineers need plaintext access.
STEP 1  App sends encrypted key + request
STEP 2  TEE decrypts key (secure enclave)
STEP 3  API call forwarded to third-party
STEP 4  Plaintext zeroed, response returned
Total: —
Gateway Pipeline

The Ecosystem Vision: Key-FHE NEW

Both sides integrate the H33 SDK. BFV fully homomorphic encryption compares the key without decrypting it — not even inside a TEE. The plaintext key never exists anywhere during verification. This is the endgame: zero-exposure at the mathematical level.

Key-FHE requires both parties to integrate the H33 SDK. We position it honestly as the future — the highest-security option for organizations willing to coordinate with their partners.

STEP 1  Encrypted key sent (Kyber-1024 envelope)
STEP 2  BFV FHE comparison (homomorphic)
STEP 3  Match / No-match result returned
No decryption step — key never exists in plaintext
FHE Verification Pipeline — zero decryption

Revocation Proofs & Cryptographic Continuity

Rotation is table stakes. Revocation proofs are not. Every authority that retires leaves a cryptographic gravestone — provable death, with a window of negative-proof coverage on either side. Receipts persist across rotations.

Key Identity
Each encrypted key is assigned a unique identifier (hk_*). Track, audit, and manage every encrypted key across your infrastructure by ID. Full lifecycle visibility from creation to retirement.
Instant Revocation
Mark any key ID as revoked — all decrypt operations for that ID are refused immediately. No propagation delay. No key material to chase down. One API call and the key is dead across every system that references it.
Seamless Rotation
Generate a new Kyber envelope and key ID. The old ID is marked rotated with a configurable grace period — systems using the old ID continue to work during the transition window, then automatically cut over. Zero-downtime key rotation.

Built for Post-Quantum Key Security

Every layer of H33-Key is designed to protect key material against both classical and quantum threats.

ML-KEM + X25519
Hybrid Post-Quantum Encryption
ML-KEM + X25519 key exchange. Kyber lattice protection combined with classical ECDH. Defense-in-depth key wrapping ensures security even if one primitive is broken.
SHA3-256
HMAC-SHA3 Integrity
Every encrypted field verified with SHA3-256 HMAC. Tampering detected before decryption attempt. Zero false positives.
Zero-Downtime
Envelope Rotation
Automatic key rotation with zero-downtime re-encryption. Old ciphertexts remain readable. New writes use rotated keys immediately.
k-of-n Policy
Threshold Decryption
k-of-n policy enforcement. No single party can decrypt. Configurable thresholds per secret or per field.
ML-DSA-65
Dilithium Audit Trail
Every key operation — create, rotate, decrypt — signed with ML-DSA-65. Non-repudiable provenance chain. Verifiable by third parties.
Per-Field
Field-Level Granularity
Encrypt individual JSON fields, not entire documents. Mix encrypted and plaintext fields in one record. Selective decryption by field name.

Where H33-Key Fits

Post-quantum key encryption for every infrastructure pattern.

API Key & Secret Management
Encrypt API keys, database credentials, and signing keys at field level. Threshold policies for production secrets. Automatic rotation schedules.
Document Encryption
Encrypt sensitive document fields (SSN, account numbers) while keeping metadata searchable. Per-field access control with ZKP-verified policies.
Tokenization
Replace sensitive values with encrypted tokens. Detokenize with threshold approval. FHE encryption means tokens are mathematically bound to originals.
Regulatory Compliance
HIPAA PHI, PCI cardholder data, SOC 2 secrets. Field-level encryption satisfies data-at-rest requirements. Dilithium audit trail for examiner verification.

The more you attest, the less each operation costs.

Volume-tiered pricing — standardized across the H33 platform.

See pricing →

How H33-Key compares

H33-Key AWS KMS HashiCorp Vault Transit Azure Key Vault
Post-quantum encryption Kyber-1024 (NIST)
Latency < 0.5ms 5–15ms 2–8ms 10–25ms
Migration required None — transparent layer Full integration Complex setup SDK integration
Vendor lock-in None AWS-only Azure-only
Threshold decryption (k-of-n) Key-3
Dilithium-signed provenance Key-3
Zero-exposure infrastructure Key-Gateway (TEE proxy)
FHE key verification Key-FHE

All units fungible — same balance as H33-Auth, H33-Vault, H33-Share, H33-Shield, and H33-Health.

Frequently Asked Questions

How is H33-Key different from a secrets vault like HashiCorp Vault or AWS Secrets Manager?
Vaults store static secrets and hand them out. H33-Key replaces static secrets with time-bound, state-scoped, computation-bound authority objects, and emits a 74-byte post-quantum receipt for every use. The right question is no longer where is the key? but what is this key allowed to do, under what state, for how long, for whom — and can every use be independently replayed? Vaults answer the first question. H33-Key answers all five.
What is a Q-Key authority object?
A machine-verifiable authority object with seven primitives: time-bound expiration, state-scoped validity, computation-bound permissions, negative proofs of non-use, multi-party continuity across rotations, trust scoring, and survivability. Instead of holding a static string like sk_live_… that can do anything, your service holds an authority object that can only do exactly the operations it was issued for, only within its declared scope, only inside its TTL window. Misuse is cryptographically detectable, not just policy-flagged.
What does the 74-byte attestation receipt prove?
Every authorized use of a Q-Key emits an H33-74 substrate receipt — 74 bytes total, anchored across three independent post-quantum signature families (ML-DSA-65, FALCON-512, SPHINCS+-SHA2-128f). The receipt cryptographically commits to which authority was used, for which computation, against which counterparty, at which timestamp. Independent verifiers (yours, your auditor's, your insurer's) can reconstruct the action from the receipt alone, without trusting H33's narrative about what happened.
How does H33-Key handle external credentials like Stripe sk_live, Twilio tokens, or OAuth client secrets?
External counterparties (Stripe, Twilio, Google OAuth, etc.) require plaintext credentials at API-call time — they don't speak Q-Key. For those, H33-Key uses envelope encryption at rest plus substrate-attested use logging: the plaintext exists only inside a TEE (or in process memory for the milliseconds of the API call), and every use emits a 74-byte PQ receipt. We are explicit about this boundary: internal H33 authority becomes Q-Key; external counterparty credentials get envelope protection plus attested use. The distinction is published, not hidden.
What is policy simulation / observe mode?
Before H33-Key enforces any deny decision, you can run it in observe mode for any time window. It shadows every authority decision — issue, attest, verify, deny — and produces a report of what would have been denied, rotated, scoped, or flagged. You see the consequences of a policy before paying for them. Adoption path: observe (no enforcement) → enforce (deny outside scope) → replay (independent reconstruction of any past action).
What is a revocation proof?
Rotation alone is not enough. A revocation proof is a cryptographic attestation that an old authority object was revoked at a specific moment, by a specific principal, and that any subsequent attempt to use it was rejected. Combined with negative proofs (provable non-use across a window), a revocation proof gives you a complete forensic narrative after a leak: when the authority died, who killed it, and that nothing slipped through after.
What is the independent verifier?
H33-Key publishes a deterministic conformance specification. Anyone — your auditor, your insurer, your regulator, a competing implementation — can build a verifier that consumes 74-byte H33-74 receipts and independently reconstructs every authority decision. The conformance corpus is the canonical replay frame; if H33's substrate disagrees with an independent verifier on any receipt, the receipt wins. This is what “replay-grade attestation” actually means in practice.
What happens to past attestations when a key rotates?
Receipts persist. A token signed by JWT_SECRET v1 inside its valid window remains independently verifiable forever, even after v2, v3, v4 replace it. Rotation generates a continuity proof linking the old authority to the new, so the audit trail does not break across rotations. This is what cryptographic continuity means: rotations do not destroy verifiability, they extend it.
Why is FHE not the answer for protecting static credentials?
FHE shines for computation on encrypted user data — which is what our BFV biometric pipeline does. For static credentials, the consumer of the secret (Stripe's API server, Twilio's API, the HMAC sign step) requires the plaintext at call time. Wrapping the key in FHE just moves the leak surface to wherever the FHE decryption key lives. The right tools for static credential protection are authority delegation (Q-Key), envelope encryption (KMS), and substrate-attested use logging (H33-74). H33-Key uses all three.
Can H33-Key be deployed in observe mode without enforcement?
Yes — that is the recommended starting point. Wire the SDK in observe mode. Every authority issue, attest, verify, and deny is logged with a receipt, but no decision is enforced upstream. After a week or two, review the would-have-denied report and tighten scopes. Then flip to enforce mode. The same receipt corpus is valid in both modes — the only thing that changes is whether the deny decision blocks the call or only flags it.
What is the SDK and CLI surface?
Four primitive calls: hkey.issue() creates a new time-bound, scope-bound authority object; hkey.attest() wraps a call so every use emits a 74-byte receipt; hkey.verify() runs the independent verifier against a receipt; hkey.observe() shadow-runs policy without enforcing. Language SDKs ship for Node.js and Rust day one (Python second). The hkey CLI is the same surface from the terminal — issue, attest, verify, observe, revoke, replay. Designed so an SRE can run any operation by hand and a service can run the same operation programmatically.
What does delegation look like?
An authority can issue a strictly narrower child authority. The parent's scope envelope dominates: the child cannot exceed the parent in any dimension (time window, computation, state). A service holding a tenant-broad authority can issue a per-route, per-request, per-worker child authority that lasts for the duration of one operation and inherits a cryptographic chain back to the issuing parent. Every child use emits its own receipt linking to the parent — full delegation provenance from the originating principal down to the leaf operation.
How does break-glass work in H33-Key?
Emergency authority exists, but every break-glass action must be pre-scoped, post-quantum attested, time-limited, and reviewed automatically. There are no unconstrained break-glass tokens. Each break-glass authority is a Q-Key object with an explicit emergency scope, a maximum TTL (default 15 minutes), and a mandatory multi-party approval requirement that fires before issuance. The receipt explicitly flags break-glass mode and triggers automated review.
Is H33-Key available today?
Yes. H33-Key is generally available. Sign up via the pricing page to provision an API key, install the Node or Rust SDK or the hkey CLI, and start in observe mode immediately. Pricing tiers run from Key-0 (basic authority issue plus attested audit log) through Key-FHE (homomorphic verification with both-sides SDK integration). Volume-tiered pricing standardized at the H33 pricing page.
TECHNICAL DEEP DIVES

Go Deeper

🔑 KYBER
CRYSTALS-Kyber Key Encapsulation Explained
How ML-KEM works, why it replaced RSA key exchange, and how H33-Key uses Kyber-1024 to protect every key.
Read Full Article →
🗄️ KEY MGMT
FHE Key Management Best Practices
Key rotation, derivation, storage, and lifecycle — managing cryptographic keys at enterprise scale.
Read Full Article →
🔐 UNIVERSAL
H33-Key: Universal Post-Quantum Key Encryption
Encrypt any key format — SSH, TLS, env vars, wallet keys — with a single API call. Auto-detection built in.
Read Full Article →

The Manifesto

Most API key infrastructure is fundamentally broken.

We literally have static secrets sitting in config files holding state secrets.

Manual rotations? What century are we in?

Global authority scopes? No replayability if something goes wrong?

No proof of misuse? No cryptographic continuity?

That model does not survive AI-scale systems or post-quantum threat environments — and quite frankly sucks terribly without AI or quantum threats.

So we fixed it. Because we can.

  • — time-bound authority objects
  • — computation-scoped permissions
  • — tenant/state-scoped execution
  • — post-quantum attestations
  • — replay-grade attestation
  • — cryptographic continuity across rotations
  • — real-time anomaly detection on secret use

The future is not “better secret storage.”

The way it should be: verifiable authority infrastructure where every sensitive action can be independently reconstructed, attested, replayed, and audited without trusting a centralized narrative about what happened.

That’s what we built with Q-Key, H33-74, Agent Zero, and our replayable governance infrastructure.
This is grouped under our H33-Key product — available now.

Stop trusting static secrets. Start attesting every key use.

Free tier includes 1,000 attested operations. No credit card. Observe mode available immediately — no enforcement until you flip the switch.