Every API key. Every token. Every signing operation. H33-Key emits a verifiable receipt naming the agent or human, the authority that allowed them, and the original instruction it traces back to. Anyone can verify it — offline, no account, no login.
A new category. Distinct from password managers (storage) and vaults (management). H33-Key is the secret-use layer — built to answer the question only it answers: why was this agent allowed to use this secret?
Install in 30 seconds → Watch the proof →v0 standalone Rust crate · browse the source
Sign up with SMS. Run one command. No dashboard. Developers never think about H33-Key — they just prove who used a secret, when, and under whose authority.
H33-Key runs as a local background agent. It watches your clipboard, detects secrets the moment you copy them, and offers to swap the raw secret for a portable h33k_<id> reference — before you ever paste it into a tool, terminal, browser, ticket, repo, chat, or AI agent.
h33k_7F8C92KQ.Encrypted material lives in your OS keychain (macOS Keychain · Windows DPAPI · Linux Secret Service). The raw secret never appears in logs, telemetry, stdout, or receipts.
Layered detection: known prefix patterns + entropy scoring + clipboard context hints. UUIDs, invoice IDs, order numbers, and ordinary URLs are never auto-protected.
Never auto-triggered: UUIDs · invoice IDs · order numbers · unlabeled hashes · public keys · transaction IDs · strings under 20 chars · URLs without credentials.
Don't ask your team to migrate secrets to a new system. Bind H33-Key to the ones they already have. Your code never moves.
Same line of code. No SDK adoption. No refactor. H33-Key wraps the call site, emits the receipt, and steps out of the way.
Every agent action emits a SecretUsed receipt, a Read Attestation citation, and a Root lineage reference — without a single extra API call from your code.
No extra API calls. No receipt handling. No verification code. No developer involvement.
Not who has access. Not when it was used. The question only H33-Key answers — the one every auditor, regulator, insurer, and CFO actually cares about.
Anyone reads this and gets it. That's the test. Vaults answer "where is the key?". H33-Key answers "why was this agent allowed to use it?".
Every interaction with a secret — capture, use, denial — emits a verifiable receipt. The raw secret never appears in any of them.
Denials are first-class evidence. "We blocked this request" is as auditable as "we allowed this one" — the same way H33-74 treats required action not performed as a verifiable artifact.
Every receipt is verifiable by anyone who has it. Give it to your auditor today, your insurer next quarter, a regulator three years from now — they run one command, get a verdict, and never have to take H33's word for it.
That's the problem no other secrets layer solves. The cross-bind between Key, Attest, and Root is the foundation: secret use is proven, agent authority is verified, and authority is traced all the way back to the human who said "do this."
A secret with H33-Key can be referenced, proven, audited, rotated, transferred, revoked, and independently verified — without revealing the secret itself.
The result is a system where governance occurs around cryptographic references rather than secret disclosure. That's the difference between storing secrets and governing them.
Auditors and CISOs will understand the difference.
Three categories. Three different jobs. H33-Key fills a gap the other two never claimed to fill.
Storage and Management answer "where is the key?". H33-Key answers "how do I use it without anyone — including AI vision, screen recorders, accessibility APIs, and shell history — ever seeing the raw bytes?"
One sentence. If it passes, we ship. If anything leaks, we hold.
A user pastes an API key into a terminal.
H33-Key masks it.
The command succeeds.
A receipt is emitted.
The key never appears in terminal output, history, logs, clipboard, screenshots, or AI-visible text.
v0 standalone Rust crate verifies this end-to-end with integration tests · 31 of 31 passing.
The two commands you actually run. The raw secret never leaves the pipe.
# The raw secret is piped in — never on argv, never in shell history. $ printf %s "$STRIPE_LIVE_KEY" | h33-key wrap \ --tenant acme --id stripe-prod \ --purpose invoice_payment \ --allow-command 'node ./pay.js' \ --expires-in-days 90
h33key://v1/acme/stripe-prod#purpose=invoice_payment&policy=pol-df95cae6
&expires=1789307815867&root=local&terminal=local
&handle_id=172a43e38479ca661bdcc1a4
{"type":"SecretWrapped",
"handle_hash":"adfc00e82a44408aac6315df...",
"created_at_unix_ms":1781531815867}
# H33-Key injects the unwrapped secret into the child's env — # then zeroizes the parent's copy the moment the child exits. $ h33-key run \ --handle "$HANDLE" \ --env STRIPE_SECRET \ -- node ./pay.js
{"type":"SecretUnwrappedForProcess",
"handle_hash":"adfc00e82a44408aac6315df...",
"purpose":"invoice_payment",
"unwrapped_at_unix_ms":1781531815885,
"use_count":1}
{"type":"SecretUsed",
"handle_hash":"adfc00e82a44408aac6315df...",
"used_at_unix_ms":1781531815887,
"command_summary_hash":"339f3ba799b29c24"}
sk-live-... never appeared on the command line.~/.bash_history, ~/.zsh_history, or any other shell history.A handle is not just a pointer. It carries the entire authority context that governs its own use.
h33key://v1/acme/stripe-prod#purpose=invoice_payment &policy=pol-df95cae6 &expires=1789307815867 &root=<root_hash> ← LOCK 1 · Root Participant &terminal=<terminal_certificate_id> ← LOCK 1 · Root Participant &handle_id=<content-addressed-id>
Mirrors the Root Activation Matrix. Five states. Authority exists only at the end of the chain.
Possession of a handle is not authority. Authority exists only when an agent has cryptographically signed a Read Attestation under its TerminalCertificate-bound key. The substrate enforces this on every use.
The Finance Manager doesn't hand the Invoice Agent the Stripe key. The Manager hands the Agent a capsule — a narrow, time-boxed, purpose-bound right to invoke a specific handle.
handle_ref: h33key://v1/acme/stripe-prod#... purpose: invoice_payment max_uses: 10 expires: 24h narrowed: cannot widen scope beyond parent's authority
When the Agent invokes the capsule, H33-Key consults the Root + Q-Sign chain, verifies the delegation lineage, decrypts the secret, injects it into the approved process, and zeroizes. The agent never sees the bytes.
Eight steps in v0. The first five are shipping today as a standalone Rust crate. The last three need the H33-Root receipt substrate — we will not fake those receipts.
~/.h33-key/kek.bin (mode 0600, auto-generated).h33key://v1/<tenant>/<secret_id>#purpose=... with day-one Root + Terminal binding fields.h33-key wraprpassword). Never argv, never echo.h33-key runDenyReason variants. No silent fall-through.terminal_cert_hash + root_hash + policy_hash.H33-Key prevents plaintext display and minimizes exposure to visual capture systems. Receipts prove what was protected.
We do not claim immunity to AI vision. Browsers, operating systems, screenshot tools, remote-desktop streams, and accessibility APIs all have edge cases. What we guarantee: the raw secret is not in any stream H33-Key controls — not on argv, not in stdout/stderr we emit, not in shell history, not in our event logs. The child process is the documented boundary; what the child does with the env var is the child's job.
No scif-backend dependency. No remote substrate required for steps 1–5. Build it, run it, audit it.
# Clone the branch (v0-standalone) $ git clone -b h33-key/v0-standalone \ git@gitlab.com:drata5764111/h33/scif-backend.git # Build the crate $ cd scif-backend/h33-key $ cargo build --release # Wrap your first secret $ printf %s "$YOUR_SECRET" | ./target/release/h33-key wrap \ --tenant me --id first-secret --purpose test \ --allow-command 'echo'
No. Password managers store secrets and hand them to you on request. H33-Key is the secret-use layer — it lets your code, agents, and humans use a secret for a specific purpose without the raw bytes ever appearing on screen, in logs, in shell history, or in AI-visible text.
No. Vaults like HashiCorp Vault or AWS Secrets Manager handle storage + management + distribution. They answer "where is the key?" and "who can get it?". H33-Key answers a different question: "how do I let an agent invoke the key for a specific purpose without ever showing the raw bytes to anyone — including the agent itself?"
No to both. H33-Key's job is secret-use control — letting an actor use a key without exposing it. It does not govern the decision the agent makes (that is Agent-008), does not render the verdict on a produced artifact (that is Verification), does not produce the portable evidence primitive (that is H33-74), and does not preserve who holds which authority (that is Authority Center). H33-Key emits a receipt at each use; the other layers govern, verify, carry, and preserve around it. Controlling the use of a key is not the same as holding the authority to sign: H33-Key governs whether a secret may be used and records that it was — whether the actor was permitted to act is preserved by Authority Center and decided by Agent-008.
Yes — that is the documented boundary. The whole point of h33-key run is to inject the unwrapped secret into the child's environment so the child can call Stripe / OpenAI / Postgres / whatever. What H33-Key controls: the raw secret never appears on argv, never in shell history, never in stdout/stderr we emit, never in our event log. After the child exits, the parent zeroizes its copy.
Every handle carries Handle Freshness fields (last_used / last_verified / rotation_epoch). The policy evaluator refuses use of a handle past its max-unverified-age cap. When the H33-Root receipt substrate ships (step 6), Root Revocation Records will immediately invalidate handles tied to a compromised Root — the same effective_at semantics Root uses.
For pure storage, ML-KEM + AES-GCM envelope encryption is sufficient and faster. TFHE pays its cost when you need operations applied to the secret state without decrypting — masked comparison, encrypted policy checks, secret presence validation, encrypted key-use gates. v0 keeps storage on envelope encryption; TFHE lands when those operation surfaces are required.
H33-Key is part of H33-Agent-008, not a separate product. The Agent-008 onboarding wizard's Step 5 Terminal Binding already names H33-Key as the identity anchor — v0 makes that binding real. TerminalCertificates bound during onboarding are H33-Key handles. Read Attestations signed by an agent's terminal are H33-Key sign-with-key operations. The Root authority chain (Human → Root → Q-Sign → H33-Key → Agent) routes through H33-Key for every credential operation.
Yes. v0 is a standalone Rust crate at scif-backend / h33-key/v0-standalone. 31 of 31 tests pass (25 unit + 6 integration, including no-leak tests that pipe a marker string and assert it never appears in any stream H33-Key emits).
Three views of the same product. What you get. What you'll pair it with. What runs underneath.
Your systems use credentials without owning or seeing them. Every secret use produces a receipt. Wrong purpose, wrong command, wrong agent — denied at the gate, before plaintext is ever assembled.
Agent-Zero classification at capture · Signed-policy gate · Verified-purpose binding · Receipt-bound use · Re-wrap on rotation