background gif
eni6ma

Developers · Get started

Get started

Reusable API keys, bearer tokens, and long-lived JWTs still authorize from anywhere until someone rotates them. Put a Gate in front of your first endpoint, migrate high-risk routes with shadow mode, then open the protocol and minting deep-dives when you need to explain the mechanism to a security reviewer.

First protected endpoint

First protected endpoint quickstart steps

Single-request proof path

Host to Client to Server to Burn to Validate single-request path

ENI6MA replaces the authorization layer (Bearer tokens, API keys, long-lived JWTs) with an envelope (a one-time cryptographic authorization for a single request, replacing the reusable bearer token or API key). It coexists with authentication (OIDC, SAML, mTLS) and sits behind an existing reverse proxy, API gateway, service mesh, or WAF. Nothing about your TLS story, your identity provider, or your service mesh changes; what changes is what you accept as authority for a state-changing call.

Developer hubs

Protect your first endpoint

A stolen bearer token against one route is reusable authority until you rotate. In about thirty minutes you can put a Gate (a reverse proxy, SDK middleware, MCP wrapper, or sidecar) in front of that route, have your client assemble an envelope, and confirm a valid request passes while a replay rejects at the nonce stage.

After this quickstart, a captured request is a fossil (the bytes exist but no longer authorize anything), because Gate refuses to re-spend the nonce ledger entry that authorized it. You do not have to touch your framework, your transport, or your identity provider to get there.

Prerequisites

  • Docker (or a Node host) available for the evaluation Gate or Reference Kit path.
  • An evaluation circuit binary (from the Foundry eval program or the DEMO-HACK pack), which is the compiled twin your client will use to respond to challenges.
  • One high-value POST or PUT route you are comfortable placing behind proof-required (payments, admin, data export, or an agent tool with side effects).

Steps

  1. Pick the form factor. If you own the application process, use the SDK middleware. If you do not want to change the app, run Gate as a reverse proxy. Either way the enforcement contract is identical.
  2. Define endpoint policy. Assign an endpoint_id for the protected endpoint, pin the method allow-list, freeze a policy_hash source string, choose a freshness window, and decide fail-closed versus break-glass behavior for outages.
  3. Wire Control or a local ledger. Point Gate at Control, or at a local ledger stub if you are only running a laptop demo. Anything beyond a demo needs a durable ledger; that is what earns the absolute replay claim.
  4. Prove once. In the client: challenge the circuit, respond, assemble the envelope with the published binding fields, and POST. You should see a 2xx and observe the side effect exactly once.
  5. Replay once. Send the exact same envelope bytes again. Gate should reject at the nonce stage with a named error. That is your baseline evidence that request authority is one-shot.
Binding reminder
sha256(method || endpoint_id || request_body_hash
     || policy_hash || tau || nonce_uuid)

What failure looks like

If the allow path returns a 4xx, the client is almost always hashing bytes that Gate does not recompute the same way (canonicalization drift). If the replay attempt returns 2xx, Gate is pointed at a non-durable ledger, or the middleware is running out of order and missing the burn step. The Conformance suite exercises both of these explicitly.

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

Migration guide

Big-bang credential cutovers fail because high-risk routes and low-risk routes are not the same blast radius. Replace ambient credentials one endpoint at a time: inventory, shadow mode, then proof-required. You keep your PKI, mTLS, and identity provider; what changes is the authority object your service accepts on the routes that hurt when they are abused.

Migration is deliberately per-route, not per-service, because that is the smallest unit at which the mechanism creates value and the smallest unit at which you can safely learn.

  1. 1. Inventory

    List every API, agent, and MCP tool that holds long-lived secrets. Rank each by blast radius if the credential is stolen: payments, admin, data export, and side-effecting agent tools go to the top. This ranked list drives the rest of the migration; do not skip it.

  2. 2. Shadow mode

    Deploy Gate in observe-only mode. It watches envelope assembly and coverage while still accepting existing tokens. This is how you find clients that have not been updated, before flipping any route to fail-closed.

    Migration can run Gate in shadow mode (envelopes observed, tokens still accepted) before proof-required cutover.Design targetFour-stage path: inventory → shadow → proof-required on high-risk → retire tokens per endpoint.

  3. 3. Proof-required on high-risk routes

    Flip fail-closed on the top blast-radius routes first. Confirm allow path and replay-reject with the Conformance suite before expanding the set. If Conformance fails on a route, do not proceed; the whole point of doing this per-endpoint is to catch integration errors while they are cheap.

  4. 4. Retire tokens per endpoint

    Remove the ambient credential for routes that are proof-required and stable. Leave coexistence on paths that are not yet migrated (see Security → Coexistence). At no point should you attempt to remove a credential from a route that has not first spent time in shadow mode and then in proof-required.

How to verify

A migrated endpoint is one whose Conformance suite is green in CI and whose old credential no longer works. Anything short of both is coexistence, not migration.