background gif
eni6ma

Demos · Minting

Available for evaluation

Long-lived certificates and shared service secrets still become blast radius when one copy escapes. Watch how Foundry produces a batch of per-identity binaries, what comes out the other side, and how those identities become live at Gate through Control.

Minting a cohort of identities

Foundry is the ENI6MA equivalent of a certificate authority, except it manufactures per-identity binaries instead of issuing long-lived X.509 certificates. Each run produces a cohort of compiled twins that already carry their own entropy, configuration, and policy, so the identity travels with the artifact rather than sitting in a vault of transferable secrets. The four steps below trace one run from the initial job through activation in Control.

Mint cohort then enforce

Mint cohort steps then handoff to enforcement

Twin circuits / cohort

Twin entangled circuits from one cohort mint batch

1. Pick a variant and cohort size

A minting job in 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) starts by choosing a circuit (a compiled cryptographic identity that carries its own configuration, entropy, and policy inside the binary itself, so identity travels with the artifact rather than sitting in a vault of transferable secrets) variant and the number of identities you want in this batch. The mental model is a manufacturing run for a cohort of workloads, not an interactive user signup, so the form asks about the batch, not about a single user.

2. Embed policy and entropy per identity

Each binary in the cohort is compiled with its own entropy, its own configuration, and the policy it is allowed to speak for. For a developer, this means the identity travels with the artifact you deploy; there is no separate vault of transferable secrets to fetch at runtime and no shared signing key that a compromise would replicate across the cohort. For a sysadmin, it means secret rotation looks like a rebuild rather than a re-issue against a shared authority.

3. Emit the cohort package and manifests

The appliance produces a cohort package containing every compiled twin (the per-identity binary a workload runs to prove itself, produced by the Foundry minting appliance), a manifest (the metadata record for a minted binary: hash, size, timestamps, and self-validation state) per binary, and the handle (the stable identifier for an identity or workload; deactivating a handle in Control is how revocation happens as a single state change) each binary will claim once activated. This package is what you hand to your deployment pipeline.

4. Activate in Control

You upload the manifests to 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) and mark the cohort active. Activation is a single registry state change; revocation later is the same kind of state change in reverse, and it takes effect on the next request because Gate consults the registry on every call rather than trusting a cached bearer token.

After mint: enforcement

Minted circuits only start providing value once a 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) actually enforces them in front of a protected endpoint (a single API route or agent tool placed behind Gate; the unit of value on every commercial page). The diagram below is the gate order (the fixed eight-stage sequence of checks Gate runs on every untrusted request before application logic executes) that runs on every request an activated cohort will handle.

Gate order after activation

  1. 01

    Request hash

    Recompute digests; reject on mismatch

  2. 02

    Endpoint

    endpoint_id matches server constant

  3. 03

    Policy

    policy_hash from server POLICY_STRING

  4. 04

    Anchor

    Circuit handle active in registry

  5. 05

    Freshness

    tau within the call window

  6. 06

    Burn nonce

    Spend before twin validation

  7. 07

    Validate

    Twin proof check (local or registry)

  8. 08

    Serve

    Application policy, then resource

ENI6MA FoundryGate walkthrough