How minting works

Today most estates authorize workloads with something that can be copied: a bearer token in an environment variable, an API key in a secrets manager, a long-lived service certificate treated as a capability. Developers wire those secrets into every caller. Investors see the same pattern at scale in agent traffic. Sysadmins inherit rotation campaigns that miss one replica and leave the breach open. Possession is authorization, and the vault is the blast radius.

That model fails under replay and under lateral movement. A stolen secret works from any network path that can present it. Revocation means chasing every consumer that embedded the secret. Agents and CI systems mint long-lived credentials faster than humans ever did, so the inventory grows while the rotation window stays the same.

ENI6MA replaces the vaulted secret with 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). The circuit is addressed by a handle (a stable identifier for an identity or workload; deactivating a handle in Control is how revocation happens as a single state change) and by the SHA-256 of the binary, so what you deploy is what your registry says is active. The compiled twin (the per-identity binary a workload runs to prove itself, produced by Foundry, the minting appliance) is the dual of that identity at Gate (the enforcement component that sits between callers and a protected route). The prover produces challenge and response material; the verifier accepts or rejects. Possessing a prover host is not the same as possessing authority for a specific request, because the envelope still has to bind method, endpoint, body, policy, tau, and nonce for that one call.

For developers, compromise looks different: there is no shared secret to lift from a vault and reuse across workloads. A stolen binary is bounded by the durable nonce ledger and by the handle in Control. A stolen envelope is already spent. For operators, revocation is one state change: deactivate the handle and new envelopes fail the anchor check at Gate. Rotation means minting a successor binary and activating it through the registry lifecycle, without redistributing long-lived secrets across every consumer. Authentication (OIDC, SAML, mTLS) and your existing PKI can stay; what changes is the authority object Gate accepts for state-changing calls.

One binary posture does not fit every estate: constrained devices, agent callers, and post-quantum requirements diverge. Foundry produces cohorts across three circuit variants so you can match posture to environment without changing the envelope contract Gate enforces. All variants satisfy the same envelope binding formula; only the compile-time posture of the binary differs.

Variant choice does not change what a client SDK sends over the wire. Clients assemble the same fields; the circuit binary changes how challenge and response material is produced under the hood.

Workloads cannot prove per-request authority if identity is still a shared secret handed out by ticket. 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 the production pipeline; the artifacts it emits are what your workloads actually run at the edge.

Minting turns policy and identity intent into artifacts you can ship. Operators (or evaluation tooling such as DEMO-MINT) request a cohort for a circuit variant, and Foundry emits a zip of per-identity binaries plus manifests suitable for import into Control.

For sovereign and classified estates, Foundry runs air-gapped: mint offline, move the resulting artifacts across an approved boundary, and enforce with Model A local verification or a self-hosted Control. For connected estates, the same mint path feeds managed Control without changing the artifacts themselves.

Operational surface

Restrict access to Foundry, treat cohort requests as a change with an approver, and record the manifest for every binary you ship. Bring the manifests into Control so the operational view matches what is actually running on hosts. Foundry is licensed separately from a Gate subscription; see Pricing for commercial packaging.

Identity that cannot be rotated or revoked cleanly becomes permanent blast radius. A circuit binary moves from Foundry mint through Control activation to retirement as auditable state changes. Operators use that lifecycle to plan rotations; developers use it when a request suddenly fails at the anchor check.

Every binary carries a manifest that Control uses to index and verify artifacts. Lifecycle transitions are intentional state changes on a handle, and every transition is auditable.

• Mint: Foundry produces a cohort zip of per-identity binaries for a chosen variant.
• Register: manifests land in Control; each handle resolves to the current artifact.
• Activate: the handle becomes eligible to mint envelopes that Gate will accept at runtime.
• Rotate: mint and activate a successor, then retire the predecessor, without redistributing long-lived secrets.
• Revoke: one state change deactivates the handle, and new envelopes fail the anchor check at Gate.

Because identity is compiled into the artifact, there is no vault of reusable API keys you must rotate across every workload when one identity is compromised. You deactivate the handle and, if needed, mint a replacement circuit and activate it. Already-burned nonces stay burned; already-issued envelopes cannot be re-spent.

Captured HTTP traffic is reusable authority whenever a nonce can be spent twice. The durable nonce ledger is the component that makes a captured request a fossil after one use. Developers care because it defines when an envelope dies; operators care because ledger durability is what earns the absolute replay claim.

The nonce ledger hands out single-use request tokens and records the moment each one is spent. Your client reserves a nonce_uuid when it assembles the envelope; Gate spends it before doing anything expensive. Ordering is what buys the guarantee, not the burn on its own.

Concretely, Gate applies burn-before-validate: the ledger records the nonce as spent before the cryptographic proof is checked. If the nonce was already spent, Gate rejects at the nonce stage and never touches your handler. If twin validation later fails, the nonce is still spent, so an attacker cannot use failed validation as a free probe.

// Gate path (simplified)
assert request_hash matches recomputed binding
assert endpoint_id / policy_hash / anchor / freshness
burn(nonce_uuid) // BEFORE validate
validate_proof(twin) // expensive check second
apply application policy
perform side effect

In production this means a real datastore behind Control, with backups, replication, and access controls consistent with an audit log. Demo packs may use in-process burn sets so a laptop can teach the mechanism, but that is an ops difference and does not change the envelope contract at the gate. As a developer, retry queues must reserve a new nonce per attempt; you cannot cache an envelope and replay it after a network blip.

The same envelope can be validated next to the workload or through a registry control plane. Client code stays unchanged across both models; what changes is where the verifier and the durable nonce ledger live.

Connected Team and Enterprise deployments typically run managed or self-hosted Control with a durable nonce ledger. Sovereign deployments license Foundry, host Control themselves, and often prefer Model A at the edge with registry sync over approved paths. Kubernetes, Envoy, and Istio sidecars are not first-class products today; use the reverse proxy or SDK middleware form factor and track sidecar as roadmap.

Waiting for a future PQ migration leaves harvest-now-decrypt-later risk on the identities that mint authority. Hybrid circuits ship X25519 combined with Kyber768 for key agreement today under the same Gate envelope contract. That is a concrete posture, not a roadmap slide, and it is not a claim that every layer of the stack is quantum-safe.

A hybrid circuit combines classical X25519 with Kyber768 for key agreement, uses a four-shard prime, and includes agent mode for machine-to-machine callers. Teams that need post-quantum readiness on the prover path mint hybrid cohorts from Foundry and enforce the same envelope contract at Gate.

Post-quantum readiness here means one specific thing: the key-agreement material used by hybrid circuits already includes a PQ KEM. It does not mean every classical primitive elsewhere in your estate is obsolete, and it does not dictate your transport TLS choices. Keep TLS and mTLS where you have them; layer request-bound envelopes on top for the routes that matter.

The absolute mechanism claims (replay impossible, authority expires per request) rest on burn-before-validate and on envelope binding. They are independent of which KEM the circuit uses, and they still require the reference architecture: a durable ledger, TLS, integrity checks on the binary, and a real lifecycle in Control.