Enforcement plane
ENI6MA Gate
BetaGate (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) is the flagship. Every untrusted call to a protected endpoint (a single API route or agent tool placed behind Gate; the unit of value on every commercial page) has to present a fresh envelope (a one-time cryptographic authorization for a single request, replacing the reusable bearer token or API key), or it does not reach application logic. Reverse proxy and SDK middleware ship today as Beta, the MCP wrapper is a runnable Demo, and the sidecar is on the roadmap.
What Gate is and why this page exists
For a security architect who is trying to place Gate on an existing diagram.
Gate is a small enforcement process that sits between callers and a protected route. It coexists with authentication (OIDC, SAML, mTLS) and sits behind an existing reverse proxy, API gateway, service mesh, or WAF; it replaces the authorization layer, which today is usually a Bearer token, an API key, or a long-lived JWT. Gate consults 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) to reserve a nonce, runs the gate order (the fixed eight-stage sequence of checks Gate runs on every untrusted request before application logic executes), and forwards only what survives.
What Gate enforces
PKI and tokens prove who may speak for a while. Gate envelopes prove that this specific message may change the world once and no more.
Gate at the boundary
Request hits Gate before application logic with allow or reject
ENI6MA Gate is the enforcement plane: it runs the eight-stage check order at the request boundary before application logic executes.Shippinggateway-service challenge/invoke path and DEMO-HACK news-server middleware.
Each protected route carries its own policy: endpoint_id, policy_hash, method allow-list, TTL, and use count.ShippingPer-route Gate configuration surface on proxy and SDK form factors.
Gate routes can run fail-closed (reject when Control is unreachable) or fail-open with an explicit break-glass path.ValidatedRoute-level fail mode and break-glass configuration on the Gate.
Gate audit capture supports hash_only and full-capture modes per route.ValidatedAudit mode configuration on protected endpoints.
The absolute guarantees assume the reference architecture, which pins the ledger, the freshness window, and the fail-closed default.
Form factors and when to pick each
Gate form factors
Four Gate form factors: reverse proxy, SDK, MCP wrapper, sidecar
Gate ships in four shapes so it can fit a real deployment without asking anyone to rebuild their edge. Reverse proxy is the default for services you cannot recompile. SDK middleware is for teams that own the code and want policy next to business logic. The MCP wrapper is for AI agent tools that can mutate systems of record. The sidecar covers workloads where a shared proxy is awkward and will ship later.
Terminate proof in front of an existing service. No application change: the gate runs the check order and forwards only what survives it.
In reverse-proxy form, Gate terminates proof in front of an existing service without requiring application changes.Shippinggateway-service on port 8095 with /gate/challenge and /gate/invoke.
The Gate reverse proxy sits behind your existing edge (nginx, Envoy, HAProxy, Kong, an API gateway, or a service mesh ingress) and in front of the protected upstream. Authentication still terminates upstream of Gate. Gate replaces the authorization layer that today is a Bearer token, an API key, or a long-lived JWT.
How you integrate it
- Place the Gate reverse-proxy process on the network path between your existing edge and the upstream service.
- Register the protected endpoint in Control and issue circuits for the callers that need to reach it.
- Configure each protected route with an endpoint_id, a policy_hash, a method allow-list, a TTL, and a freshness window.
- Point clients at /gate/challenge to negotiate and /gate/invoke to send; confirm Control emits burn events and access logs.
When to choose reverse proxy
- You need to protect a service you cannot recompile easily or do not own the source of.
- The natural enforcement point is at the edge or in the DMZ, and you already terminate TLS and run a WAF there.
- Several backends share one Gate instance with different per-route policy.
- You want the fastest path to a live deployment: reverse proxy is Beta today and does not require touching application code.
The eight-stage gate order
A fixed sequence on every untrusted request. Stage 5 is burn-before-validate (the ledger records the nonce as spent before the cryptographic proof is checked, so a captured request cannot be re-submitted even if validation later rejects it), which is why replay does not survive the boundary.
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.
- Recompute the request hash
- Check endpoint and policy
- Confirm the circuit is active
- Check freshness
- Burn the nonce
- Validate the proof
- Apply application policy
- Serve the request
Deployment shape, failure mode, observability
What a sysadmin actually operates.
Where Gate sits
Behind the edge (nginx, Envoy, Kong, an API gateway, a service mesh, or a WAF), in front of the protected route. Authentication still terminates upstream via OIDC, SAML, or mTLS; Gate handles authorization on each request.
Runtime footprint
A single Gate process per protected surface, plus a network hop to Control for nonce reservation and burn. Control can be managed or self-hosted; the nonce ledger (a durable append-only log that hands out single-use request tokens and records the moment each one is spent) is the durable piece.
Failure mode
Default is fail-closed: if Control is unreachable, Gate rejects. An explicit break-glass path can be configured per route for emergency access, and every use of it is logged. There is no silent fall-through to a static credential.
Observability
Gate emits burn events, reject reasons keyed to the stage that fired, and access logs back to Control visibility. Audit mode is configurable per route: hash-only for compact evidence, or full capture for the complete request transcript when a route needs it.
What developers change in their code
Callers stop attaching a static Authorization header. Machines run a compiled twin (the per-identity binary a workload runs to prove itself, produced by the Foundry minting appliance) that produces a request-bound (cryptographically tied to this exact HTTP method, endpoint, body hash, policy, and timestamp) proof per call. Humans use Pass+ (the human ceremony client that produces a request-bound proof without leaving a reusable secret behind, similar in spirit to how a hardware security key finishes a WebAuthn ceremony) to produce the same shape of proof interactively. Server code declares an endpoint_id, a policy_hash, an allowed method list, and a freshness window; Gate handles the rest.
Configuration surface
What a buyer configures per protected endpoint.
Per-endpoint policy
endpoint_id, policy_hash, method allow-list, TTL, and use count (scoped to the route being protected).
Freshness window
Tune how long an envelope remains valid for each route. Captured envelopes die when the window closes.
Fail-open vs fail-closed
Choose reject-when-Control-is-unreachable, or an explicit break-glass path for emergency access.
Audit mode
hash_only for compact evidence, or full capture when you need the complete request transcript.
Ready to protect an endpoint?
Reverse proxy and SDK middleware are Beta. MCP wrapper is a runnable Demo. Sidecar is on the roadmap and does not have a purchase path yet.