Security
Security architecture
Evaluators need the threat model, the fixed Gate check order, burn-before-validate evidence, and the operational surface before they pick a Public, Cloud, or Sovereign package. The mechanisms a skeptical security architect looks for before picking a SKU: the fixed eight-stage Gate order, burn-before-validate on a durable nonce ledger, envelope field binding, hybrid post-quantum key exchange where configured, circuit-handle revocation through Control, and an honest compliance roadmap with no unearned certification claims.
ENI6MA replaces reusable credentials with one-shot, request-bound proofs. Authority expires with the request under the reference architecture (claim: authority-expires-per-request).
An envelope is a one-time cryptographic authorization for a single request: method, endpoint_id, request-hash, policy hash, tau, and nonce bind into the proof so the verifier observes allow or deny for that binding alone. Gate is the enforcement component that runs a fixed eight-stage check before application logic. Burn-before-validate means the durable nonce ledger records a nonce as spent before the cryptographic proof is checked, so a captured request cannot be re-submitted even if validation later rejects it. For PKI and IdP coexistence, see Coexistence with PKI. The mathematics behind empty-channel authorization under the named model lives under Technology → Math.
Live capture
Security guided tour
A click-through of the live cloud host, client, and server exchanging one request-bound envelope, with hotspot callouts, payload excerpts, burn-before-validate on the durable ledger, and every reject stage an adversary can hit. Plan on about ten minutes; absolute claims still assume the reference architecture.
Eight-stage gate order
Every untrusted request hits the same ordered checks before application logic runs: policy and binding, freshness, ledger consult, burn, cryptographic validate, then allow or deny. Stage 5 is load-bearing - the nonce is spent before the proof is checked so replay cannot race validation.
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.
Burn-before-validate
The nonce is spent in the durable ledger before the proof is checked. A second submission of the same envelope always fails, including after a validation reject. Absolute replay claims require that durable ledger and the other reference-architecture requirements (claim: burn-before-validate, replay-impossible).
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
Envelope binding
Authority is not lasting speakership from a reusable credential. An envelope binds method, endpoint_id, request body hash, policy hash, tau, and nonce so the verifier observes allow or deny for that single request binding alone. A proof minted for one route cannot authorize another; after burn, the same envelope cannot proceed again under the reference architecture (claims: envelope-request-binding, authority-expires-per-request).
Envelope binding
Binding formula visual linking request fields to proof
Every envelope is bound to a specific method, endpoint, request body, policy, freshness window, and nonce.Shippingsha256(method || endpoint_id || request_body_hash || policy_hash || tau || nonce_uuid)Holds under the reference architecture
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
- Bound fields: method, endpoint_id, request body hash, policy hash, tau, nonce UUID - each checked before allow.
- A proof minted for one route cannot authorize another; endpoint_id and request-hash binding reject relays under claim immune-phishing / envelope-request-binding.
- After burn, the same nonce cannot authorize a second submission even if the first validation rejected (claim: burn-before-validate).
Post-quantum posture
Hybrid classical and lattice key exchange where configured: X25519 + Kyber768 on Gate ↔ Control and client ↔ Gate channels. Transport confidentiality upgrades do not replace one-shot request authority; they protect the channel that carries envelopes (claim: pqc-hybrid-handshake).
Post-quantum hybrid ladder
Read the hybrid ladder as classical plus post-quantum transport (X25519 with Kyber-class KEMs) stacked for channel integrity. It upgrades computational hardness assumptions for packets in transit, not the empty-channel authorization claim. Takeaway: PQ hybrid is the right tool for transport; Channel Zero emptiness remains a different authorization job.
Transport posture combines classical X25519 with Kyber768 for post-quantum readiness.Design targetHybrid key exchange on control-plane and gate channels where configured.
Deeper technical notes under Developers → Post-quantum posture. For the computational hardness assumption (glossary: hardness clock) versus information-theoretic empty-channel posture under the named model, see Technology → Math and Quantum myths vs real bounds. Transport PQC upgrades confidentiality; they do not replace one-shot request authority.
Circuit lifecycle and revocation
Identity is a circuit handle in Control’s registry, not a vaulted reusable secret. Deactivate the handle and every Gate that consults Control rejects subsequent proofs from that identity - one registry state change instead of a fleet-wide credential rotation (claim: revocation-one-state-change).
Circuit lifecycle
Mint register active revoke one-state-change lifecycle
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
Immune to keylogging.ValidatedNothing typed has lasting value; bearings are one-shot and already burned by the time an observer could reuse them.Holds under the reference architecture
Immune to phishing.ValidatedNo reusable credential exists to harvest; endpoint_id binding means a relayed proof fails on any other route.Holds under the reference architecture
Compliance roadmap
Certifications are binary facts procurement verifies. We publish progress toward SOC 2, FedRAMP, and FIPS where work is underway, and we do not claim status we have not earned. Conformance evidence from Verify is separate from auditor certification.
Compliance / DSP roadmap
Compliance and DSP packaging roadmap strip
SOC 2 / FedRAMP / FIPS
No SOC 2, FedRAMP, or FIPS certification status is claimed on this site.
Deployment Security Package
Threat model, attack-to-reject-stage mapping, residual risk under each deployment profile (Public, Cloud, Sovereign), scope boundaries against the reference architecture, and conformance suite results. Released to deployment customers and qualified evaluators under NDA - not a public absolute-claim expansion.