Kill the key. Long live the proof.
Reusable credentials (passwords, tokens, certificates) authorize until they are rotated or revoked. ENI6MA binds one-shot, request-bound proofs so a verifier observes allow or deny for that request alone. Gate runs a fixed eight-stage check order on every untrusted request before application logic; stage 5 spends the nonce in the durable ledger before proof validation (burn-before-validate), so a captured envelope cannot replay even after a reject. Scope: Public, Cloud, and Sovereign deploy packages under the reference architecture and model-scoped claims — not lasting stealable capability from a captured secret.
Reusable credentials authorize until rotated or revoked. One-shot proofs bind a single request; the verifier observes allow or deny under the reference architecture and claim model.
Stored secret vs one-shot proof
Read left-to-right: the stored-secret column shows ambient credentials that keep working after copy; the one-shot column shows a request-bound envelope that burns after accept. Takeaway: stolen possession is not lasting authority when the proof dies with the moment.
Applied Scenarios
Browse all scenarios
Illustrative scenarios. The organizations named and the logos shown are publicly documented reference organizations, not ENI6MA customers. No commercial relationship, deployment, or endorsement is claimed or implied.
Ambient credentials are the breach
Every API key, bearer token, and service certificate in your estate is a secret that works from anywhere until you notice it is gone. ENI6MA makes authority expire at the end of each request: Gate binds method, endpoint, and policy into the envelope, burns the nonce before validation, and the verifier observes allow or deny for that request alone under the reference architecture.
Ambient credentials invite breach
Ambient API keys, bearer tokens, and certificates as stealable tokens leading to breach
Possession is not authority
Token-copy chain showing possession mistaken for authority at agent scale
Capture is not knowledge
Follow the observer path: a full transcript fills the notebook while the vault for the secret stays closed. Surface bits are recordable; effective mutual information with the secret stays empty under the model. Takeaway: capture of the channel is not knowledge of the secret.
Every API key, bearer token, and service certificate is a secret that works from anywhere until you notice it is gone.Ambient credentials authorize by possession alone; ENI6MA replaces that model with one-shot, request-bound proofs.
An API key, bearer token, or service certificate works from any network path that can present it. Theft equals lasting request capability until rotation catches up. ENI6MA binds authority to one request envelope so a captured secret cannot authorize a second call under the reference architecture.
Revoking ambient credentials means chasing every workload that embedded them. Miss one and the breach continues. With circuit handles in Control, deactivation is one registry state change that every consulting Gate observes on the next proof.
MCP tools, autonomous agents, and machine-to-machine callers mint long-lived secrets faster than humans ever did. Per-call envelopes wrap each tool invocation so Gate/policy authorizes world-changing tool calls once; a captured agent secret does not grant lasting request authority (claim: authority-expires-per-request).
Technology · Math
Two kinds of security. Computational hardness is not information-theoretic posture.
Today's web mostly bets that math stays hard — that computers stay too slow under a computational hardness assumption. Information-theoretic authorization asks a sharper question: does the public channel even carry secret-relevant information? Under the named model, an observer can record the transcript while effective mutual information with the secret stays empty; claim strength follows the claims registry.
That computational bargain is a race against hardware and algorithms under a hardness assumption: secrecy holds while the problem stays hard. Information-theoretic security asks whether an observer who records every bit of the public transcript can still learn nothing about the secret — an empty effective channel under the named model, not a longer race. Two roads: computational hardness assumptions versus information-theoretic posture. New Dimensions in Zero-Information Cryptography states the formal relocation thesis; download the white paper or open the Math hub for axioms, bounds, and claim scope.
Download New Dimensions · Math hub
Two kinds of security
Two columns contrast a computational hardness assumption with empty-channel authorization. Takeaway: not every security claim is the same kind of guarantee.
This plate contrasts a computational public artifact whose inverse exists but is hard with a zero-information channel whose public scaffold displays every path while the private selector remains outside the observable boundary.
Read left-to-right: computational hardness assumptions bound the adversary; the zero-information panel relocates confidence to transcript emptiness. Takeaway: long-horizon security moves from recoverable-archive cost to the information content of the channel.
Flagship zero-information claim: I of J semicolon O given C equals I of phi semicolon O given C equals I of sigma semicolon O given C equals I of M semicolon O given C equals 0. Download the white paper PDF.
Math
The formal case: perfect secrecy under the named model, empty effective channels, and parameterized bounds.
Open Math hub →Why not all proofs are equal
Hardness-assumption proofs and empty-channel proofs answer different questions; do not treat them as interchangeable guarantees.
Explore →Axioms, theorems, and bounds
The reference stack mathematicians and cryptographers expect: axioms → theorems → model-scoped bounds.
Explore →How a Gate decides
Eight fixed checks run on every untrusted request before application logic executes: policy, binding, freshness, ledger consult, burn, validate, and downstream allow or deny. Stage 5 (burn-before-validate) spends the nonce in the durable ledger before the proof is checked, so a second submission of the same envelope fails even after a validation reject (claims: burn-before-validate, replay-impossible).
Recompute the request hash
The gate hashes the body it actually received and compares it to the envelope.
Rejects: A body that was altered after the proof was made.
Check endpoint and policy
The envelope names the endpoint and the policy it was made for; both must match this route.
Rejects: A valid proof relayed to a different endpoint.
Confirm the circuit is active
The handle is resolved against the registry and must be active. Deactivating a handle is how revocation happens.
Rejects: A proof from a revoked identity.
Check freshness
The envelope timestamp must fall inside the freshness window configured for the route.
Rejects: A captured envelope replayed after the window closed.
Burn the nonce
The nonce is spent here, before the proof is validated. Every submission spends it, including one that is about to fail validation.
Rejects: Any second use of the same envelope. This is where replay dies.
Validate the proof
Only now is the proof itself checked, against the local binary or the registry. Both modes are equivalent at the envelope layer.
Rejects: A forged or malformed proof.
Apply application policy
Ordinary authorization runs in the post-proof zone: arguments, limits, and business rules.
Rejects: A well-proved request asking for something it is not allowed to ask for.
Serve the request
The application does its work, and the response is bound back to the request that earned it.
How a Gate decides
Read the pipeline left-to-right: each Gate stage checks binding, freshness, and burn order before allow. Gold highlights burn-before-validate so replay dies at the ledger, not after crypto. Takeaway: enforcement order is part of the security claim, not a UX detail.
Replay dies at the ledger
Duplicate ceremony rejected at ledger via burn-before-validate
Burn-before-validate is the structural reason a second submission of the same envelope always fails.ShippingGate stage 5 spends the nonce in the durable ledger before stage 6 validates the proof.Holds under the reference architecture
Replay is impossible by design.ShippingThe nonce is burned before validation in a durable ledger; it is spent even when validation later fails.Holds under the reference architecture
Burn-before-validate spends the nonce before twin validation so the sealed verifier can emit only a residue bit Y in the set zero one — not a reusable authorizer; see axioms and the New Dimensions PDF.
How attacks fail
Classical and modern attack families try to convert observation or theft into usable authority. One-shot proofs deny that conversion — family by family.
Burn-before-validate stops replay
How to read: second-submit myths fail; ledger burn then reject. Takeaway: spent nonces do not authorize again.
Replay
Burn-before-validate: spent nonces do not authorize a second submission.
See how we stop it →No reusable vault on channel
How to read: transferable-secret conversion myths fail; circuit identity and burn succeed. Takeaway: identity in circuits, not a secret store.
Vault breach
Stolen vault material is not a reusable authorizer on the channel.
See how we stop it →Nothing reusable to harvest
How to read: lasting-credential myths fail; one-shot proof fragment is request-bound. Takeaway: no lasting credential; binding holds.
Phishing
Stolen ceremony fragments do not replay as ambient credentials.
See how we stop it →Flat marginals deny counting
How to read: broken compass on the left; uniform bearings and empty MI on the right. Takeaway: P2 uniformity removes the letter compass.
Frequency analysis
Flat synonym marginals deny letter-counting compasses.
See how we stop it →Session independence holds
How to read: stitch myths fail left; fresh challenge and ambiguity hold right. Takeaway: transcripts do not become the secret.
Correlation
Session independence stops transcripts from stitching into secrets.
See how we stop it →Keylog captures spent work
How to read: password-reuse myths fail; bearings → burn → already spent. Takeaway: surface only; authority spent.
Keylogging
Captured input does not become lasting request authority.
See how we stop it →Authority dies with the request
How to read: ambient myths fail; per-request proof and burn succeed. Takeaway: no long-lived bearer on the channel.
Agents & MCP
Per-call tool authority without reusable ambient secrets.
See how we stop it →Info bounds ≠ computational hardness
How to read: wrong targets crossed out; empty channel, burn, scoped claims. Takeaway: quantum myths versus information bounds.
Quantum cryptanalysis
Quantum myths versus model-scoped information bounds.
See how we stop it →Four products. One authorization plane.
Foundry mints identity into per-identity circuit binaries and cohort packages. Control registers circuits, runs the durable nonce ledger, and exposes burn and access visibility. Gate enforces the eight-stage order as proxy, SDK middleware, MCP wrapper, or sidecar. Verify runs customer-owned adversary harnesses against that deployment before production traffic does.
Four authorization planes
Read top-to-bottom through Foundry (mint twins), Control (registry and ledger), Gate (request boundary), and Verify (adversary harness). Each band is a different ops job that ships the same proof family. Takeaway: the product stack separates integrity tooling from the empty-channel authorization thesis.
Full catalog and form factors on Products.
Product capabilities
Cloud. Agent. Human.
One family of one-shot proofs, Gate on estates and MCP tools, Pass+ ceremony for people, the same burn-before-validate contract underneath.
One proof family
Three surfaces (cloud, agent, and human) share one envelope primitive rather than three incompatible credential schemes. Read the shared core first, then the surface-specific ceremony wrappers. Takeaway: Channel Zero is one proof job expressed across form factors.
Cloud
Protect the estate without rewriting it
Put Gate in front of the routes that matter. PKI and mTLS stay for transport identity; ENI6MA replaces the reusable API keys and bearer tokens that authorize requests.
Explore →Agent
Per-call authority for tools that change the world
MCP and agent runtimes decide which tool to call. ENI6MA decides whether that call may produce a side effect, without ambient API keys sitting in the agent host.
Explore →Human
Prove knowledge without broadcasting a secret
Pass+ turns human memory into a dynamic interactive proof. The Private Synonym Map decouples what appears on screen from what the user communicates, so observers, cameras, and keyloggers see ambiguous tokens, not a reusable password.
Explore →Start where credentials fail first
Three buyer tracks: AI agents and MCP tools, high-risk APIs and endpoints, and PKI authorization coexistence. Agent and MCP security leads because ambient tokens and long-lived tool secrets proliferate fastest there; each track maps to Gate-enforced one-shot envelopes under the same claim model.
Buyer tracks
Three buyer rails: agents and MCP, APIs, and PKI coexistence
Secure your AI agents and MCP servers
Wrap tools so each invocation carries a one-shot envelope. Gate/policy authorizes world-changing tool calls; a captured agent secret does not grant lasting request authority under claim authority-expires-per-request.
Explore →Secure your APIs and endpoints
Put Gate in front of high-risk routes. Method, body hash, endpoint_id, and policy bind into every proof so the verifier observes allow or deny for that binding alone; replay and relay fail under the claim model.
Explore →Replace or augment PKI authorization
Replaces the part of PKI that keeps breaching you (the credentials that authorize requests). Certificates stay for transport identity; ENI6MA owns request authority via one-shot envelopes on protected routes.
Explore →What changes when authority is one-shot
Mechanism claims, stated plainly against ambient credentials: one-shot envelopes, request-hash binding, circuit identity instead of vaulted secrets, and registry revocation. Each absolute claim assumes the reference architecture and cites its claim ID.
One-shot vs reusable credentials
Compare the reusable-credential lifetime on the left with the per-request one-shot proof on the right. Reuse invites steal-and-replay; one-shot authority dies after burn. Takeaway: the same word “proof” can mean lasting possession or momentary ceremony work.
Envelope authorizes one request, then the nonce is spent
Authority expires at the end of each request.The envelope binds method, endpoint_id, request hash, policy hash, tau, and nonce (one message, one use).Holds under the reference architecture
endpoint_id and request-hash binding reject relays
Immune to phishing.No reusable credential exists to harvest; endpoint_id binding means a relayed proof fails on any other route.Holds under the reference architecture
Identity lives in compiled circuits, not a secret store
Immune to credential-vault breach.No vault of reusable secrets exists; identity is compiled into the circuit binary, not stored as a transferable credential.Holds under the reference architecture
One registry state change deactivates the circuit handle
Revocation is one state change.Deactivating a circuit handle in the registry revokes the identity; there is no rotation campaign across every workload.Holds under the reference architecture
Full mechanism detail on Security architecture. Guarantees assume the reference architecture. Compare security systems in depth on the Math comparison matrix.
Applied scenarios
Illustrative architectures against publicly documented reference organizations — role-based access, financial API binding, regulated workload control — not customer engagements or endorsements.
Scenario reference architecture
Generic applied-scenario reference architecture template
Global technology
Role-based access without ambient MFA tokens
Reference organization: Microsoft
Illustrative ScenarioBanking
Request-bound authorization for financial APIs
Reference organization: JPMorgan Chase
Illustrative ScenarioAerospace and defense
Mandatory access control for regulated workloads
Reference organization: Boeing
Illustrative ScenarioIllustrative scenarios. The organizations named and the logos shown are publicly documented reference organizations, not ENI6MA customers. No commercial relationship, deployment, or endorsement is claimed or implied.
Live capture
Security guided tour
Twenty-nine screens from a live DEMO-HACK red-team run, burn-before-validate, envelope binding, and every reject stage, with hotspot callouts and payload excerpts.
Security guided tour
Guided tour stack: health, allow, attacks, mint
See a proof happen
Walk the DEMO-HACK cloud host→client→server tour with hotspot evidence, then the Gate happy path and every reject stage on a live Gate, or try the Pass+ teaching UI: six zones, bearing-only responses, one verdict after six witnesses.
Single-request proof path
Host to Client to Server to Burn to Validate single-request path
Security guided tour
Primary path: twenty-nine live DEMO-HACK screens with hotspots, payload excerpts, burn-before-validate, and every reject stage on the cloud host→client→server path.
Open →Gate walkthrough
Happy path and every reject stage on a live Gate: binding mismatch, spent nonce, stale tau, and policy deny — observable allow or deny codes.
Open →Verify walkthrough
Watch the attack suite exercise burn-before-validate and replay rejection against a deployed Gate before production traffic does.
Open →Pass+ ceremony
Teaching UI: six zones, bearing-only responses, one verdict after six witnesses — one-shot knowledge proof without teaching the channel the secret.
Open →Technology · Fundamentals
When the channel reveals nothing
Record the public transcript. Learn nothing about the secret under the named model. Start with the empty effective channel, then see how Rosario proves knowledge once without teaching the channel what you know — the Fundamentals path into Math, axioms, and the published corpus.
When the channel reveals nothing, capture is not knowledge. You can record the public transcript and still leave the secret untouched under the named model. That empty effective channel is the Fundamentals path: prove you know something once, without teaching the channel what you know. Rosario makes that one-shot proof concrete for authorization transcripts; Overview, Channel Zero, and Papers collect the pedagogy and published corpus.
Fundamentals path · channel reveals nothing
A fundamentals path plate: when the channel reveals nothing, capture is not knowledge. Takeaway: Channel Zero sits beside familiar crypto primitives with a different job.
Overview
The Technology manifesto: what this section teaches, in what order, and how Math and Fundamentals connect.
Explore →When the channel reveals nothing
Empty-channel pedagogy: record the public transcript, learn nothing about the secret under the named model.
Explore →How Rosario works
One-shot knowledge proofs without teaching the channel the secret — mechanism, witnesses, and verifier outcome.
Explore →Research papers
Abstracts and audience tags over the published corpus, including New Dimensions.
Explore →Protect an endpoint
Start with Gate on a single high-risk route: eight-stage checks, burn-before-validate, and request-bound envelopes you can observe in allow or deny. Or request a Foundry evaluation for licensed cohort manufacturing and Control at your perimeter under Public, Cloud, or Sovereign packages.
Protect an endpoint
Minimal wrap-this-route diagram for protecting an endpoint
Need executive delivery alongside the product? Fractional CAISO lives under Services. Services
Evaluate Gate against a real high-risk route with burn-before-validate and envelope binding visible in the accept/reject path, or talk to us about Foundry-licensed cohort manufacturing and Control at your perimeter under Public, Cloud, or Sovereign packages.