Products
The platform, then the catalog
Ambient credentials are still the breach path most estates live with. ENI6MA sells four planes that replace reusable authorization with one-shot proofs: read the category and moat first, walk capabilities by audience, then open an individual product page for integration and deployment detail.
ENI6MA replaces reusable credentials with one-shot, request-bound proofs, so a stolen secret is not a stolen capability.
PKI and tokens prove who may speak for a while. ENI6MA envelopes prove that this message may change the world once.
Platform → catalog wedge
Platform to catalog wedge and moat diagram
Category, wedge, moat
For readers who are here for the business shape rather than the code.
Category
Post-credential authorization
Every API key, bearer token, and long-lived JWT is a reusable secret that works from anywhere until it is noticed missing. ENI6MA replaces the authorization layer with an envelope (a one-time cryptographic authorization for a single request, replacing the reusable bearer token or API key), so authority expires at the end of each request instead of at the end of a rotation window.
Wedge
Agent traffic and long-lived keys
Autonomous agents now call tools and mutate systems of record on behalf of humans, and the credentials they hold are the same reusable API keys that leak out of laptops and CI logs today. Protecting agent tool calls is the point of first pain, and it is why the MCP wrapper form factor exists.
Moat
Mechanism plus supply chain plus ledger
The moat is three layers stacked: the mechanism itself (one-shot request-bound proofs), the minting supply chain that produces per-identity circuits, and the durable nonce ledger (a durable append-only log that hands out single-use request tokens and records the moment each one is spent) that makes replay a mathematical impossibility rather than a policy hope.
ENI6MA replaces the authorization layer (Bearer tokens, API keys, long-lived JWTs). It coexists with authentication (OIDC, SAML, mTLS) and sits behind an existing reverse proxy, API gateway, service mesh, or WAF, so a buyer does not throw away their identity provider or their edge to adopt it.
Who this page is written for
Software developers
You want to see what changes in your code. Short answer: your callers stop sending a static Authorization header and start producing a request-bound (cryptographically tied to this exact HTTP method, endpoint, body hash, policy, and timestamp) proof per call, and Gate rejects anything that is not fresh.
Security engineers and sysadmins
You want deployment shape, failure mode, and where this sits relative to your gateway, mesh, and PKI. Gate is a small enforcement process you place behind your existing reverse proxy, API gateway, service mesh, or WAF, and it talks to Control for lifecycle and the ledger.
Investors and business readers
You want the category and the defensibility in plain language. See the block above for both. Individual product pages carry the technical detail that supports those claims.
Capabilities
One product family (one-shot, request-bound proofs) expressed for three audiences: cloud estates, AI agents, and live humans. The same primitives (compiled identity, envelopes, burn-before-validate) span all three.
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.
One primitive, three surfaces
Humans prove through a Private Synonym Map ceremony (Pass+). Machines and agents prove with compiled twins and envelopes from Foundry. Every path still hits Gate’s ordered checks and Control’s ledger (authority expires at the end of each request).
Absolute claims assume the reference architecture. Deep links: Cloud, Agent, Human.
Systems · APIs · workforce endpoints
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.
Features & functions
Gate form factors
Reverse proxy, SDK middleware, and roadmap sidecar, enforce the eight-stage order at the request boundary without changing upstream service code.
Per-endpoint policy
endpoint_id, policy_hash, method allow-list, TTL, and use count scoped to each protected route.
Durable nonce ledger
Control burns nonces before twin validation so identical envelopes cannot be spent twice, even after a validation reject.
Circuit lifecycle
Foundry mints per-identity binaries; Control activates and revokes with one registry state change.
Benefits
- A stolen secret is not a stolen capability (authority is request-bound and one-shot).
- Replay fails by design under the reference architecture.
- Revocation is one handle deactivation, not a rotation campaign across every workload.
- Coexists with certificates: keep the PKI hierarchy; fix the credentials that authorize requests.
Workforce API behind Gate
An existing REST service keeps its TLS certs and network path. Gate sits as reverse proxy on /api/orders. Each call carries a one-shot envelope bound to method, endpoint, body hash, and policy. A captured envelope cannot authorize a second call or a different route.
How ENI6MA sits on existing architecture
Leave load balancers, service mesh, and mTLS in place. Gate becomes the authorization plane for protected endpoints. Ambient API keys and long-lived bearer tokens come off those routes; certificates continue to prove channel identity. Migrate one endpoint at a time (see coexistence with PKI).
Mechanism claims
Authority expires at the end of each request.ShippingThe 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.ShippingThe nonce is burned before validation in a durable ledger; it is spent even when validation later fails.Holds under the reference architecture
Revocation is one state change.ShippingDeactivating a circuit handle in the registry revokes the identity; there is no rotation campaign across every workload.Holds under the reference architecture
Immune to credential-vault breach.ValidatedNo vault of reusable secrets exists; identity is compiled into the circuit binary, not stored as a transferable credential.Holds under the reference architecture
Verify
Customer-runnable attack suite against a live Gate. Demonstration artifact for evaluation: kept as a product page, not a Products dropdown item.
Verify (a customer-runnable attack suite that exercises a Gate deployment with adversarial traffic before real users do) is how a buyer sees burn-before-validate refuse replay, retarget, and body-tamper before signing anything. Point it at your own Gate; watch which stages reject which attacks.
Four planes
The site is organized around four product names rather than repository names. Foundry manufactures identity, Control manages lifecycle and nonces, Gate enforces at the request boundary, and Verify attacks the Gate so a buyer can watch which stages reject which attacks.
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 plane
Foundry
Foundry (the minting appliance that manufactures per-identity circuit binaries in cohorts; the ENI6MA equivalent of a certificate authority, but for one-shot identities instead of long-lived X.509 certs) is licensed as an appliance and can run air-gapped for sovereign estates.
Open the Foundry page →Control plane
Control
Control (the control plane: a registry of active identities plus the durable nonce ledger; conceptually the token-issuer, revocation registry, and audit log for one-shot proofs combined) is where you activate a handle, revoke it, reserve a nonce, and see it burn.
Open the Control page →Enforcement plane
Gate
Gate (the enforcement component: a reverse proxy, SDK middleware, MCP wrapper, or sidecar that sits between callers and a protected route and requires a valid envelope for each request) is the flagship and the piece that runs the fixed eight-stage check on every untrusted request.
Open the Gate page →Developer surface plane
Verify
Verify (a customer-runnable attack suite that exercises a Gate deployment with adversarial traffic before real users do) is how a buyer sees the mechanism refuse to be replayed before signing anything.
Open the Verify page →Foundry ships cohort material into Control. Control activates a handle (the stable identifier for an identity or workload; deactivating a handle in Control is how revocation happens as a single state change) and later revokes it. Gate consults Control to reserve a nonce, then emits a burn event and an access log back to Control. Verify and the Reference Kit integrate against Gate so a buyer can watch all of this happen against a real deployment.
The eight-stage gate order
Every untrusted request runs through this fixed sequence before application logic sees it. Stage 5 is burn-before-validate (the ledger records the nonce as spent before the cryptographic proof is checked, so a captured request cannot be re-submitted even if validation later rejects it), which is why replay does not survive the boundary.
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.
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.
The Control ledger reserves and burns nonces before proof validation, so every submission spends the nonce.Shippingledger-service reserve/response/commit with NONCE_TTL_SECONDS 300.Holds under the reference architecture
ENI6MA Gate is the enforcement plane: it runs the eight-stage check order at the request boundary before application logic executes.Shipping
Absolute mechanism claims hold under the reference architecture, which pins the ledger, the freshness window, and the fail-closed default.
Product catalog
Availability badges reflect a single product status source. Anything marked Design, Roadmap, Demo, or Research is described honestly and has no purchase path from this page.
Primary
ENI6MA Gate
Enforcement at the request boundary. Ships as reverse proxy, SDK middleware, and MCP wrapper today, with sidecar on the roadmap.
- Runs a fixed eight-stage check on every untrusted request before application logic executes.
- Applies per-endpoint policy for route, methods, and freshness so one Gate can protect many APIs.
- Keeps one envelope contract across four form factors, so callers do not learn a new proof shape per packaging.
ENI6MA Foundry
Minting appliance for per-identity circuit binaries. Licensed separately from the Gate subscription and air-gappable for sovereign estates.
- Produces cohort zip batches so operators can issue many per-identity binaries in one manufacturing run.
- Supports seven circuit variants so posture can change without changing the envelope contract Gate enforces.
- Is available through evaluation engagements when an estate needs to mint identities before production cutover.
ENI6MA Control
Registry, durable nonce ledger, and visibility. Activate a handle, revoke it, reserve a nonce, watch it burn.
- Holds the identity registry so a handle can be activated or revoked as a single state change.
- Runs the durable nonce ledger that makes burn-before-validate possible on every request.
- Gives operators visibility into reserves, burns, and access decisions without reading application logs alone.
ENI6MA Verify
Customer-runnable attack suite against a live Gate. Demonstration artifact for evaluation, not a purchase SKU.
- Ships as an adversary harness you point at your own Gate before real users arrive.
- Exercises a documented attack suite so evaluation criteria are falsifiable, not slideware.
Pass+ and companion tools
Human ceremony client and browser extension, plus Codebook, Desktop, and E6 Vault companion tools.
- Provides the human ceremony client for people who must authorize a high-risk action interactively.
- Packages that ceremony as a browser extension so the proof can finish at the edge without a long-lived cookie.
- Absorbs Codebook (CLI), Desktop (roadmap), and E6 Vault (.r6 seal/verify/open) on one page.
Secondary
E6 Vault
Companion tool that seals, verifies, and opens .r6 envelope files for offline proof material in labs and air-gapped reviews.
Learn moreCodebook
Command-line tool for ENI6MA codebook artifacts (puzzle and synonym-map inputs that support Pass+). Ships today as CLI v0.2.0.
Learn moreDesktop
Planned workstation client for Pass+ ceremonies. Roadmap only; no purchase path today.
Learn moreCircuit-ASM
Active research on lower-level circuit assembly. Not a supported product and not for purchase; production minting is Foundry.
Learn moreSSO-PII
Paper design for SSO-oriented PII handling with ENI6MA proofs. No runtime code yet and no purchase path.
Learn moreDeploy with Services
Fractional CAISO engagements cover architecture review, credential inventory, migration, Gate integration, and compliance evidence, so an estate does not have to figure out the rollout from a docs page alone.