How it works

Protocol

A stolen bearer token works for every replay until you rotate it. Gate runs a fixed sequence on every untrusted request so a captured call dies after one use. The wire shape stays ordinary REST or JSON; what changes is the authority object Gate accepts in place of a bearer token.

Protocol happy path

Challenge respond envelope burn protocol happy path

Envelope fields

Core envelope fields Gate trusts versus ignores

Envelope binding

Binding formula visual linking request fields to proof

A traditional API accepts a bearer token and trusts it until it expires. ENI6MA treats the request body as untrusted until an envelope proves that this specific method, on this specific endpoint, with this specific body hash, under this specific policy, at this specific τ (tau), with this specific nonce, is allowed to change the world once. That property is what we call request-bound.

What you add as a developer: an SDK call before your request goes out to assemble the envelope, and a Gate in front of your route to enforce it. If the envelope is missing, malformed, or does not match what Gate recomputes from server-side constants, the request never reaches your handler and returns a 4xx that names the reject stage.

Protocol sequence

Happy path

The client canonicalizes the request (method, endpoint_id, body digest, policy) so both sides hash the same bytes.
Challenge: the client asks its circuit binary for a fresh tau-bound challenge.
Respond: the circuit produces twin proof material (bearings, proof_hash, and shards as required by the variant), where a bearing is the atomic unit of the response.
Assemble the envelope from the published binding fields and reserve a nonce from the nonce ledger.
Gate runs burn-before-validate, then twin validation, then application policy, then the side effect.

Gate check order

The gate order is deliberate. Each independent check runs before the application side effect, and each has a named reject stage the client can see and log:

Recompute request_hash from server-side inputs and reject on any mismatch with the envelope.
Check endpoint_id and policy_hash against server constants; the client cannot loosen either by claim.
Confirm the anchor or handle is active in the registry (or in the local stub, for Model A deployments).
Enforce freshness: the difference between server time and tau must fall inside the configured window.
Burn nonce_uuid in the ledger before any proof validation runs.
Validate the twin against the local binary or the registry HTTP path.
Apply application policy, then fetch or mutate as the handler would normally.

What breaks when you get it wrong

The most common integration errors are hashing the wrong bytes (client canonicalization drifts from the server), sending a stale envelope from a retry queue, or forgetting to reserve a fresh nonce per attempt. All three surface as named rejects at the recompute, freshness, or nonce stage. Run the Conformance suite against your Gate to falsify each case explicitly before you consider a route migrated.

Composite binding (conceptual)

request_hash = sha256(
  method || endpoint_id || request_body_hash
  || policy_hash || tau || nonce_uuid
)

Mechanism claims

Every envelope binds method, endpoint_id, request body hash, policy hash, tau, and nonce_uuid into one composite digest.Shippingrequest_hash = sha256(method || endpoint_id || request_body_hash || policy_hash || tau || nonce_uuid).Holds under the reference architecture

The nonce is burned before twin validation, so a failed or replayed submission cannot be spent twice.ShippingGate order spends nonce_uuid prior to validate-proof; spent nonces reject at the nonce stage.Holds under the reference architecture

Authority expires at the end of the request (a captured envelope is a fossil, not a reusable credential).ShippingOne-shot nonce plus request binding; capture does not authorize a second call.Holds under the reference architecture

Protected routes do not rely on a reusable API key, bearer token, or service certificate as the authority object.ValidatedThe gate accepts a per-call envelope; agents and MCP faces are not configured with a bypass secret.Holds under the reference architecture

Envelope specification

Clients and gates fail integrations when the authority object is underspecified. The envelope fields below are the contract both sides agree on. Publishing the schema openly costs nothing: security rests on the embedded circuit, not on the schema being secret.

An envelope is a small structured object your client assembles before every state-changing call. Get the fields right and your request passes; get one wrong and Gate rejects at a named stage that tells you exactly which check failed.

Binding formula

Canonical request_hash preimage

request_hash = sha256(
  method
  || endpoint_id
  || request_body_hash
  || policy_hash
  || tau
  || nonce_uuid
)

Fields are concatenated with || as the delimiter and hashed with SHA-256. Gate recomputes this digest from server-side constants and the received body; it does not trust the client to self-describe endpoint or policy. This is what makes an envelope request-bound.

Core fields

method: the HTTP method or logical verb the endpoint policy allows.
endpoint_id: the stable identifier for the protected route (a server constant, not a client claim).
request_body_hash: the digest of the canonical request body your client is actually sending.
policy_hash: the digest of the server policy string bound to this route.
tau: τ (tau, the microsecond timestamp the ledger records when a nonce is reserved).
nonce_uuid: the ledger-issued single-use identifier from the nonce ledger.
proof material: twin fields (bearings, proof_hash, and shards as required by the circuit variant).
child_handle or anchor: the handle Gate checks for activation.

What Gate does not trust

Self-descriptive fields inside the envelope are inputs to verification, not authority. Swapping endpoint_id in the envelope, or loosening policy_hash, while keeping every other field consistent, still fails, because Gate compares against its own server-side constants. That is why lifting the schema does not help an attacker: they still need a fresh nonce and a valid twin proof for a specific route.

How to verify your assembly

The Conformance suite exercises the exact reject stages that will fire when a client mis-assembles an envelope. Run it against a staging Gate before you flip proof-required on a real route. If your integration passes allow, replay-reject, body-tamper-reject, endpoint-retarget-reject, and policy-loosen-reject, your envelope assembly is right.

Mechanism claims

An envelope minted for one endpoint_id cannot authorize a different route.ShippingThe gate recomputes digests against its own endpoint_id and policy constants, not the client’s self-description.Holds under the reference architecture