The post-credential era starts here

Kill the key. Long live the proof.

Passwords, tokens, and certificates keep working until someone rotates or revokes them - including an attacker who already has a copy. ENI6MA replaces that lasting authority with one-shot proofs: each approval authorizes one action once, across apps, agents, and paper. Captured proofs do not replay; authority ends with the request. Deploy as Public, Cloud, or Sovereign stacks under the reference architecture and model-scoped claims.

Book a live demo Try the Proof Security tour Download the white paper Download Paper Identity Proof

One-shot proofs across digital systems and paper. Authority expires with the request - under the reference architecture and claim model.

Identity

Your password is already in someone else’s database.

Identity today is a reusable record in someone else’s system: a password hash, a private key, or a biometric template that keeps authorizing until it is rotated or revoked. ENI6MA mints identity as a one-shot circuit you hold and spend for a single action. There is no standing secret left for a vault breach to hand over. Deploy under Public, Cloud, or Sovereign stacks with claim-scoped outcomes the verifier can observe.

See the identity products Book a live demo

Claim scope: immune-vault-breach, authority-expires-per-request. Holds under the reference architecture

Sovereign authentication

Locked out of your own identity by whoever holds the account.

You approve one action, on any screen, and the verifier observes a single allow or deny for that request alone. No platform sits in the middle holding a reusable secret that makes you you. The approval is spent when used, so an operator cannot replay it as standing permission. Scope is the published ceremony and reference architecture. This is not a new identity silo.

How sovereign identity works Try the Proof

Claim scope: authority-expires-per-request. Holds under the reference architecture

Privacy

They recorded your entire login and got nothing.

The approval you send is not your secret material. Under the published channel model, a recording of the public exchange does not teach an observer what you know. The same recording cannot be replayed as a second approval once the proof is spent. This is a mechanism claim with named scope. It is not a legal privacy policy.

Read the privacy mechanism Security tour

Claim scope: replay-impossible, immune-keylogging. Holds under the reference architecture

Personal data

Every check you pass leaves another copy of you to steal.

An ENI6MA approval binds to the request: this action, this moment, once. It does not carry your name, date of birth, or a biometric template as the thing being checked. The verifier observes allow or deny for that binding alone, so a captured approval is not a reusable copy of you. Use across people, cloud workloads, and agents under the same envelope model.

See capabilities for people, cloud, and agents Book a live demo

Claim scope: envelope-request-binding. Holds under the reference architecture

Paper

Stolen mail and photocopied documents stop working.

The same one-shot approval works on a phone, a shared kiosk, or a printed sheet you mail or file. Mint, validate, and burn: a spent sheet is spent, and photocopying it does not recreate the authority it carried. No biometric template enrollment is required as a lasting factor. Paper and digital share one request-bound model under the Codebook carrier.

Open Paper Identity Proof Download Paper Identity Proof

Claim scope: burn-before-validate. Holds under the reference architecture

Agents

One leaked agent key should not spend your whole account.

Agents and machine services accumulate long-lived keys faster than people do, and those keys keep working until someone notices. Each tool call can carry its own one-shot approval instead, so a stolen agent credential is not standing permission to act again. The verifier sees allow or deny for that call under the stated model. Fits MCP tools, APIs, and workload gates without replacing every IdP you already run.

Secure AI agents and MCP tools Try the Proof

Claim scope: authority-expires-per-request. Holds under the reference architecture

Circuit Authority

On the roadmap

Proving who you are should not depend on who you can pay.

Circuit Authority is the planned civic baseline: mint an identity, prove it for a specific action, online or on paper, without enrolling a biometric template as lasting factor. Status today is roadmap-honest: institutional pilots first, free civic baseline when that tier opens. It does not claim production availability yet. Read the roadmap for scope, waitlist, and what a verifier would observe when the civic tier ships.

Read the Circuit Authority roadmap Book a live demo

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.

Identity

The database holding your password will be breached.

For fifty years, digital identity meant storing something stealable: a password, a private key, a biometric template in a shared database. ENI6MA mints identity as a one-shot circuit and spends it as a proof that dies with the request. There is no reusable secret in a vault, so a database breach does not hand over the people inside it.

Explore identity products

Claim scope: immune-vault-breach, authority-expires-per-request. Holds under the reference architecture

Split diagram: stored secret equals authority versus one-shot envelope that dies after accept

Sovereign authentication

Locked out because someone else holds your keys.

You answer a fresh challenge, and the verifier sees one allow or one deny for that single action. Nobody in the middle has to hold the secret that makes you you, and nobody can spend your approval a second time.

How the proof works

Claim scope: authority-expires-per-request. Holds under the reference architecture

Rosario ceremony flow: fresh challenge, local private map, bearing witnesses, burn nonce, twin verdict

Privacy

Recorded in full. Still worth nothing.

An observer can capture the entire public exchange: every screen, every keystroke, the whole transcript. Under the published model that recording does not teach them your secret, and replaying it does not produce a second approval.

When the channel reveals nothing

Claim scope: replay-impossible, immune-keylogging. Holds under the reference architecture

Observer captures transcript bits while hidden knowledge remains zero

Personal data

Every check leaves another copy of you behind.

An ENI6MA approval is bound to the action: this method, this endpoint, this request, this moment, once. It is not a copy of your name, your birth date, or your fingerprint template, so the artifact being checked is not a record that can leak or be resold.

Capabilities by audience

Claim scope: envelope-request-binding. Holds under the reference architecture

Binding formula visual linking request fields to proof

Portability

Lost phone, no signal, borrowed screen. Still you.

The same one-shot approval works on your phone, on a borrowed kiosk, and on a printed sheet you put in the mail. Validation spends the sheet; a photocopy of a spent sheet does not recreate the authority it carried.

Paper Identity Proof

Claim scope: burn-before-validate. Holds under the reference architecture

Codebook sheet as a carrier projection of the public structured-ambiguity scaffold

Surveillance

Filmed, keylogged, shoulder surfed. Still not reusable.

Shoulder surfers, screen recorders, and keyloggers capture what you sent, not what you know. What they captured was already spent by the time they could try it, and a proof minted for one action cannot be pointed at another.

Why attacks fail

Claim scope: immune-keylogging, immune-phishing, replay-impossible. Holds under the reference architecture

Duplicate ceremony rejected at ledger via burn-before-validate

Recovery

Your phone was stolen. Your identity was not.

Identity is a handle in a registry, not a seed phrase you can lose or a key file you can copy. Deactivating a handle is one state change, and every verifier that consults the registry rejects the next proof from it.

Registry and revocation

Claim scope: revocation-one-state-change. Holds under the reference architecture

Mint register active revoke one-state-change lifecycle

Where it applies

A stolen password becomes someone else’s mortgage.

Opening a credit line. Passing a KYC check. Casting a ballot. Approving a transfer. Getting back into a wallet. These are the moments where a stolen password becomes someone else’s life. An approval that only works once changes the outcome.

See where it lands

Generic applied-scenario reference architecture template

Where a one-shot approval changes the outcome

The moments where a stolen credential does the most damage are the moments an approval that only works once is worth the most.

Credit applications

Someone opens a credit line in your name and you find out months later. Apply for credit without handing a lender a reusable secret: each step is approved once, bound to that application, and the approval expires with it.

Financial services →

KYC and onboarding

Every onboarding check leaves your passport scan in one more company’s storage, waiting to leak. Satisfy the check by proving you can answer instead of shipping copies of your documents into another database.

Applied scenarios →

Government identity

A benefits letter taken from a mailbox is enough to claim what belongs to someone else. Prove entitlement at a counter, a kiosk, or through the mail, with paper sheets that work when there is no network.

Paper Identity Proof →

Ballots

A photocopied ballot that gets counted is a vote nobody cast. A ballot packet carries a one-shot sheet. Validation spends it, so the same sheet cannot be counted twice.

Codebook sheet lifecycle →

Financial transactions

One intercepted payment approval should not move your money twice. A transfer is approved for that exact amount and destination, once, so a captured approval cannot be re-sent for a second transfer.

APIs and high-risk routes →

Crypto wallet access

Lose the seed phrase and the wallet is gone; let someone copy it and the wallet is theirs. Recover and unlock without one, because access is proved per action instead of stored in a phrase.

Consumer use cases →

Illustrative scenarios describing where one-shot approvals apply. Named sectors are not customer deployments or endorsements.

Six things, in plain language

Pass+

Beta

The way a person proves themselves: a short puzzle only you can answer, on any screen.

Codebook

Available (CLI v0.2.0)

Printed identity sheets for mail, deeds, and ballots. Each sheet works once.

Foundry

Available for evaluation

The mint. It manufactures identities as one-shot circuits, and it can run fully disconnected.

Control

Available

The registry and the ledger: what is active, what was spent, what is revoked.

Gate

Beta

The doorman in front of an app or an API. It requires a valid one-shot approval before anything happens.

Verify

Demo

The attack rehearsal. It tries to break your own deployment before real attackers do.

Four ideas behind it

One-shot approval.

Each approval authorizes one action once, then it is gone.

Spend before check.

The approval is marked used before it is verified, which is the structural reason a second submission always fails.

Claim scope: burn-before-validate. Holds under the reference architecture

Nothing to steal.

Identity is compiled into a circuit, not filed as a reusable secret, so there is no vault to dump.

Claim scope: immune-vault-breach. Holds under the reference architecture

Same idea on paper.

A printed sheet follows the identical mint → validate → burn path as a web request.

Enigma: Eliminate Stored Secrets

Whiteboard walkthrough: lasting stored credentials fail open to theft; one-shot request proofs authorize one action once. Covers ceremony, deployment topologies, and what a verifier observes under the stated model.

Watch on YouTube

Enterprise installs it. People feel it.

Fewer support fires. Fewer lasting break-ins.

Forgot password is a cost center

Fewer tickets. Less lasting access after a steal. Less time restoring systems.

Cut reset & recovery tickets →

Stop the attack before recovery starts

Prevention — not a weekend of resets.

Prevent stolen logins from lasting →

Companies install it to save time and money. People get safer logins where they already are.

What you stop relying on - and what you keep

Retire the reusable-credential breach surface. Keep the IdP, mTLS, and application systems you already run; Gate layers one-shot request authority on top.

Public Cloud Sovereign

Eliminate

Reusable passwords as lasting authority
Standing API keys and bearer tokens
OTP MFA as lasting authorization factor
Biometric templates as lasting secrets

Deny (scoped)

Replay (claim: replay-impossible)
Phishing-for-capability (claim: immune-phishing)
Vault-breach-as-takeover (claim: immune-vault-breach)
Keylogging of a reusable secret (claim: immune-keylogging)
Learning the secret from the public channel under the named model

Works across

AI agents and MCP tool calls
APIs and workloads behind Gate
Mobile and desktop web
Air-gapped Foundry and Control deployments
Physical Paper Identity Proof sheets

Trust rests on three controls

Pinned digest. Authority binding. Proof ceremony. A plausible URL and the reputation of a hosting platform are not on that list.

Pinned digest

The relying service records the verifier’s SHA-256 digest and recomputes it over the exact bytes used on every validation, with matching byte length.

Tampering at the host produces a digest mismatch and fails closed. Host reputation is not a trust control.

Authority binding

Expected digest comes from Circuit Authority or the verified sidecar path your product defines. The client’s handle, URL, or digest claim is an untrusted hint for lookup only.

First contact is meaningful: an attacker cannot simply present their own circuit and become the pin.

Proof ceremony

A single-use, nonce-bound interactive proof authenticates one specific request. The nonce is burned so the same proof cannot authorize again under the reference architecture.

Capture of the public channel is not lasting authority (claims: authority-expires-per-request, burn-before-validate, replay-impossible).

Digest mismatch → halt, quarantine, report. Never treat as a transport retry.
Never pin a client-supplied digest.
Hosting outage is availability; digest mismatch is integrity — keep those separate.
Sandbox third-party code; a correct digest proves expected bytes, not safe behavior.

See coexistence →

Optional topologies — pick ops clothes, keep the digest

Local cache, hosted executor, enterprise self-hosted, or one-shot metered. Same challenge–prove–burn loop; different who runs the circuit and who bears cost.

Topology A

Local cache

Choose for high volume, edge latency, and air-gap tolerance after first pull.

Topology B

Hosted executor

Choose when you will not execute third-party native code or need fast integration.

Topology C

Enterprise self-hosted

Choose for regulated, residency, or sovereign estates that cannot depend on a third-party control plane.

Topology D

One-shot metered

Choose for first-contact commerce, checkout, or entitlement checks. Billing scaffolding may be roadmap-honest where StatusBadge applies.

Compare topologies

Config stacks — situation to package

BYOI, org twin, dual XOR, hosted BFF, sovereign, agent, wallet, and more. Same protocol; different entry points.

BYOI (Path B)

Users or partners publish their own public verifier and authenticate on your site.

Open →

Dual XOR login

Production login that offers org twin or BYOI without dangerous mixes.

Open →

Hosted login BFF

Teams want a deployable auth origin with ordinary HTTP challenge / prove / validate routes.

Open →

Sovereign / air-gapped

Execution and ledger must stay inside the customer boundary.

Open →

Agent / workload

Automation must call APIs without static bearer tokens in environment files.

Open →

Browse stacks Book a live demo

How the tech works

Identity is a content-addressed verifier. Access is a one-shot proof against a burned challenge.

Publish a digest-pinned twin-circuit verifier. Onboard with either an org handle or a BYO verifier URL. Run a ceremony that yields a short-lived session and/or a request-bound Gate envelope. Keep your IdP, mTLS, and apps — replace the secret-matching layer, not the stack.

Publish
Onboard (XOR)
Ceremony

Matched prover and verifier twin circuits sharing a sealed private map while the public channel carries only witnesses — Matched pair · sealed map · per-event work
Mirror the prover and verifier twins: they share a sealed private map relationship that never rides the public channel. Only witnesses and challenges travel between them. Takeaway: identity lives in matched circuits and per-event work, not in a reusable ambient secret.

Publish

Mint and register a content-addressed verifier — digest plus location. Relying parties resolve by digest, not by a reusable shared secret.

Details →

Onboard (XOR)

Bind either a Circuit Authority org handle or an external verifier URL — not both. Reject dual binding so the relying party has one resolution path.

Details →

Ceremony

Nonce → prove → verify → burn → grant. Outcome: short-lived session/cookie and/or a request-bound Gate envelope for that action once.

Details →

Digest mismatch fails closed. A captured public transcript is not lasting authority under the named model. Grant outcomes are a short-lived session/cookie and/or a request-bound Gate envelope.

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

Replay is impossible by design.The 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 is the structural reason a second submission of the same envelope always fails.Gate stage 5 spends the nonce in the durable ledger before stage 6 validates the proof.Holds under the reference architecture

How the tech works

Happy path to adopt

Keep your stack. Replace the secret-matching layer on one route first.

Start with one high-risk route. Choose where verification runs. Shadow, then require proof. Confirm allow, deny, and replay-fail before you expand.

First protected endpoint
First protected endpoint quickstart steps

Proof before sign

For agents and APIs: authorize the call with a one-shot envelope before the side effect runs. APIs & endpoints · Gate

Quickstart Demos Talk to Sales

Ambient credentials are the breach

Every API key, bearer token, and service certificate in your estate works from anywhere until you notice it is gone. ENI6MA closes that open: a stolen key is not lasting capability, and revocation is one registry state change under the reference architecture - the verifier observes allow or deny for that request alone.

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

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.

Theft expires with the request

An API key, bearer token, or service certificate works from any path that can present it. ENI6MA binds authority to one request so a captured secret cannot authorize a second call under the reference architecture.

Revoke once in the registry

Ambient revocation is a fleet rotation campaign. With circuit handles in Control, deactivation is one registry state change every consulting Gate observes on the next proof.

Each agent tool call is one-shot

MCP tools and autonomous agents mint long-lived secrets faster than humans. Per-call envelopes wrap each tool invocation so Gate/policy authorizes world-changing side effects once - not lasting request authority under the reference architecture.

Product capabilities

Cloud. Agent. Human.

One family of one-shot proofs: stolen secrets stop granting lasting capability, agents authorize each tool call once, and people prove without a reusable password or biometric template as lasting authority.

Public Cloud Sovereign

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.

A stolen secret is not a stolen capability (authority is request-bound and one-shot).

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.

Per-call authority matches how agents actually operate (many short hops, not one long-lived token).

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.

No reusable credential to phish or harvest from a fake portal.

Explore →

All capabilities Security guided tour

Status quo vs ENI6MA outcomes

What lasting credentials force you to accept versus what one-shot authority changes: captured secrets stop granting lasting power, replay fails under the reference architecture, and revocation is one registry change. Each absolute cites its claim ID.

Reusable credential lifetime versus per-request one-shot proof — 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.

Status quo

ENI6MA

Secrets, tokens, and vaults grant lasting power

No lasting power from a captured secret

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

Replay is a hygiene problem

Replay fails under the reference architecture

Replay is impossible by design.The nonce is burned before validation in a durable ledger; it is spent even when validation later fails.Holds under the reference architecture

Phishing harvests a lasting credential

No reusable credential to harvest for lasting capability

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

Vault dump equals takeover

Identity is not a vault of reusable secrets

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

Revocation is a fleet-wide rotation

One registry state change deactivates the 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

Agent and MCP ambient keys authorize tool side effects

Per-call authorization for tool side effects

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

No paper or offline identity path

Paper Identity Proof without biometric templates as lasting authority

Air-gapped minting is rare

Foundry sovereign and air-gap capable minting for estates that cannot leave the network

Full mechanism detail on Security architecture. Guarantees assume the reference architecture. Compare security systems in depth on the Math comparison matrix.

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

Lead track

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 the reference architecture.

Explore →

Secure your APIs and endpoints

Put Gate in front of high-risk routes. Method, body hash, endpoint, 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 →

Applied scenarios

Illustrative architectures against publicly documented reference organizations - role-based access, financial API binding, regulated workload control - not customer engagements or endorsements.

Browse all scenarios →

Global technology

Role-based access without ambient MFA tokens

Reference organization: Microsoft

Illustrative Scenario

Banking

Request-bound authorization for financial APIs

Reference organization: JPMorgan Chase

Illustrative Scenario

Aerospace and defense

Mandatory access control for regulated workloads

Reference organization: Boeing

Illustrative Scenario

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.

Start the tour Security architecture

Security guided tour
Guided tour stack: health, allow, attacks, mint

See allow, deny, and replay fail

Watch a live path accept a valid proof, reject a replay, and surface every Gate reject stage - then try Pass+ for a human one-shot proof without teaching the channel the secret.

Single-request proof path
Host to Client to Server to Burn to Validate single-request path

Security guided tour

See allow/deny and replay fail across the live DEMO-HACK host→client→server path with hotspot evidence and every reject stage.

Open →

Gate walkthrough

Happy path plus reject stages on a live Gate: binding mismatch, spent nonce, stale timing, and policy deny - observable allow or deny.

Open →

Verify walkthrough

Watch the attack suite show replay fail 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 proof without teaching the channel the secret.

Open →

Want this walked with your routes? Or book a live walkthrough.

Book a live demo

How a Gate decides

Eight fixed checks run before application logic: bind the request, spend the nonce, then allow or deny. A second submission of the same envelope fails under the reference architecture (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.

Eight-stage Gate pipeline with burn-before-validate highlighted in gold — 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.

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

The verifier observes allow or deny for that request alone - not a reusable authorizer. Formal model and axioms live on Technology · Axioms.

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.

Ledger burn spends nonce before validate; second submission rejected — 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 →

Compiled circuit identity and burned one-shot envelope with no reusable vault — 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 →

One-shot proof fragment with endpoint binding rejecting relay — 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 synonym marginals and empty effective MI denying letter-counting compasses — 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 and fresh challenges stopping transcript stitch into φ — 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 →

Bearings submit then nonce burn; second attempt hits already spent — 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 →

Per-request proof with burn-before-validate and no leftover channel key — 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 →

Empty effective channel and one-shot burn versus quantum omnipotence myths — 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 →

Browse all attacks Run Verify Security tour

Mint. Revoke. Enforce. Prove.

Foundry mints identity. Control revokes with one registry state change. Gate enforces one-shot authority on the request path. Verify proves the reject stages before production traffic does.

Foundry, Control, Gate, and Verify stacked authorization planes — 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.

Manufacturing

ENI6MA Foundry

Available for evaluation

Mint identity: compile per-identity circuit binaries into cohort packages that ship licensed and air-gapped. Gates and Control consume those packages for one-shot proofs - not a store of reusable secrets.

Cohort production
Per-identity binaries
Air-gap capable

Learn more

Control

ENI6MA Control

Available

Revoke and lifecycle: activate, deactivate, reserve, and burn circuit handles in one registry and durable nonce ledger. Gate consults Control so replay and post-revoke proofs fail under the reference architecture.

Circuit registry
Nonce ledger
Burn and access logs

Learn more

Enforcement

ENI6MA Gate

Beta

Enforce on the request path: proxy, SDK middleware, MCP wrapper, or sidecar runs the same ordered checks - bind the request, spend the nonce, then allow or deny. Per-endpoint policy chooses which routes require a valid envelope.

Per-endpoint policy
Burn-before-validate
Request-bound envelopes

Learn more

Assurance

ENI6MA Verify

Demo

Prove before production: customer-runnable attack suite exercises Gate reject stages - replay, binding mismatch, post-burn reuse - and produces conformance evidence on your deployment.

Adversary harness
Reject-stage coverage
Conformance evidence

Learn more

Full catalog and form factors on Products.

Technology · Math

The formal case, when you need it

Public transcripts can be recorded without teaching the secret under the named model. Open Math for axioms, bounds, and claim scope - this page stays on buyer outcomes.

When you need the formal case: under the named model, recording the public channel need not teach the secret. Download New Dimensions or open Math for axioms, bounds, and claim scope.

Download New Dimensions · Math hub · Read the Math

Two kinds of security: computational hardness assumption versus empty-channel authorization — 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.

Relocation thesis: computational public artifact versus zero-information channel scaffold — 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.

Primary

Math

Axioms, bounds, and claim-scoped formal posture - outbound from the homepage outcomes above.

Open Math hub →

Why not all proofs are equal

Different proof classes answer different questions; do not treat them as interchangeable guarantees.

Explore →

Axioms, theorems, and bounds

The reference stack: axioms → theorems → model-scoped bounds.

Explore →

Technology · Fundamentals

Prove once without teaching the channel

Capture is not knowledge under the named model. Fundamentals walks the empty effective channel into Rosario, Overview, and the published corpus.

Prove knowledge once without teaching the channel what you know. Overview, Channel Zero, Rosario, and Papers collect the pedagogy and published corpus.

Fundamentals path: when the channel reveals nothing, capture is not knowledge — 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

What Technology teaches, in what order, and how Math and Fundamentals connect.

Explore →

When the channel reveals nothing

Record the public transcript; leave the secret untouched under the named model.

Explore →

How Rosario works

One-shot knowledge proofs - mechanism, witnesses, and verifier outcome.

Explore →

Research papers

Abstracts and audience tags over the published corpus, including New Dimensions.

Explore →

Protect a high-risk route — with a guided walkthrough

Book a live demo to walk Gate allow / deny / replay-fail and a stack that matches your estate. Or try the self-serve proof first, then request a Foundry evaluation for licensed cohort manufacturing under Public, Cloud, or Sovereign packages.

Protect an endpoint
Minimal wrap-this-route diagram for protecting an endpoint

Book a live demo Try the Proof

Need executive delivery alongside the product? Fractional CAISO lives under Services. Services

Kill the key. Long live the proof.

Your password is already in someone else’s database.

Locked out of your own identity by whoever holds the account.

They recorded your entire login and got nothing.

Every check you pass leaves another copy of you to steal.

Stolen mail and photocopied documents stop working.

One leaked agent key should not spend your whole account.

Proving who you are should not depend on who you can pay.

Applied Scenarios

The database holding your password will be breached.

Locked out because someone else holds your keys.

Recorded in full. Still worth nothing.

Every check leaves another copy of you behind.

Lost phone, no signal, borrowed screen. Still you.

Filmed, keylogged, shoulder surfed. Still not reusable.

Your phone was stolen. Your identity was not.

A stolen password becomes someone else’s mortgage.

Where a one-shot approval changes the outcome

Credit applications

KYC and onboarding

Government identity

Ballots

Financial transactions

Crypto wallet access

Six things, in plain language

Pass+

Codebook

Foundry

Control

Gate

Verify

Four ideas behind it

One-shot approval.

Spend before check.

Nothing to steal.

Same idea on paper.

Enigma: Eliminate Stored Secrets

Fewer support fires. Fewer lasting break-ins.

What you stop relying on - and what you keep

Eliminate

Deny (scoped)

Works across

Trust rests on three controls

Pinned digest

Authority binding

Proof ceremony

Optional topologies — pick ops clothes, keep the digest

Local cache

Hosted executor

Enterprise self-hosted

One-shot metered

Config stacks — situation to package

BYOI (Path B)

Dual XOR login

Hosted login BFF

Sovereign / air-gapped

Agent / workload

Identity is a content-addressed verifier. Access is a one-shot proof against a burned challenge.

Publish

Onboard (XOR)

Ceremony

Keep your stack. Replace the secret-matching layer on one route first.

Pick one high-risk route

Choose an execution topology

Shadow, then proof-required

Prove allow, deny, replay-fail

Ambient credentials are the breach

Cloud. Agent. Human.

Protect the estate without rewriting it

Per-call authority for tools that change the world

Prove knowledge without broadcasting a secret

Status quo vs ENI6MA outcomes

Start where credentials fail first

Secure your AI agents and MCP servers

Secure your APIs and endpoints

Replace or augment PKI authorization

Applied scenarios

Role-based access without ambient MFA tokens

Request-bound authorization for financial APIs

Mandatory access control for regulated workloads