Enforcement plane
ENI6MA Gate
BetaGate runs a fixed eight-stage check order on every untrusted request before application logic executes. Stage 5 burns the nonce in Control’s ledger before cryptographic validation (burn-before-validate), so a captured envelope cannot authorize a second call even if validation later rejects. Callers must present a fresh, request-bound envelope for each protected endpoint, or the request never reaches the upstream. Form factors - reverse proxy and SDK middleware (Beta), MCP wrapper (Demo), sidecar (roadmap) - sit between callers and the route while authentication (OIDC, SAML, mTLS) still terminates upstream.
- Proxy
- SDK
- MCP
- Sidecar
What Gate is and why this page exists
For a security architect placing Gate on an existing diagram - coexistence first, then what changes.
Gate is a small enforcement process between callers and a protected route (a single API path or agent tool behind Gate; the commercial unit of value). It coexists with authentication and sits behind an existing reverse proxy, API gateway, service mesh, or WAF. What it replaces is the authorization layer that today is usually a Bearer token, an API key, or a long-lived JWT. On each request Gate consults Control (registry of active identities plus the durable nonce ledger) to reserve a nonce, runs the eight-stage gate order, and forwards only what survives. Absolute guarantees assume the reference architecture: durable ledger, freshness window, and fail-closed default. Gate is the enforcement plane of Cloud and Agent stacks; Foundry and Control supply minting and lifecycle around it.
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 - under the stated model and claim registry.
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.
Per-route policy binds endpoint_id, policy_hash, allowed methods, TTL, and freshness. Fail-closed means an unreachable Control yields reject, not silent pass-through. Audit mode is configurable: hash-only for compact evidence, or full capture when a regulated route needs the transcript. Claim strength for replay and authority expiry is gated by the registry (for example authority-expires-per-request, replay-impossible) and the reference architecture - not by unqualified marketing absolutes.
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: terminate proof in front of the upstream, forward only survivors. SDK middleware is for teams that own the code and want policy next to business logic (Node/Express is the Beta reference). The MCP wrapper sits in front of AI agent tools that can mutate systems of record - MCP selects the tool; Gate/policy authorizes whether that call may change the world once. The sidecar covers workloads where a shared proxy is awkward and ships later; until then, proxy or SDK cover the same envelope contract.
Terminate proof in front of an existing service. No application change: eight-stage order including burn-before-validate; only survivors reach upstream.
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. That is why replay does not survive the boundary under the reference architecture.
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
Stages cover envelope presence, binding to method/endpoint/body/policy/time, ledger reservation and burn, cryptographic validation, and policy match. Reject reasons are keyed to the stage that fired so on-call can triage without guessing. The same order runs in proxy, SDK, MCP, and (when shipped) sidecar form factors - the form factor changes placement, not the contract.
Deployment shape, failure mode, observability
What a sysadmin actually operates when Gate is in the path.
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. Migrate one endpoint at a time; leave the rest of the estate on existing credentials until you move them.
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 (durable append-only log of single-use request tokens and spend times) is the durable piece. A cache-only ledger is not the shipping shape for absolute claims.
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. Pair with Verify to see reject stages fire before production.
What developers change in their code
Callers stop attaching a static Authorization header. Machines run a compiled twin (per-identity binary from Foundry) that produces a request-bound proof per call - tied to HTTP method, endpoint, body hash, policy, and timestamp. Humans use Pass+ to produce the same shape of proof interactively without leaving a reusable secret as a lasting authorization factor. Server code declares an endpoint_id, a policy_hash, an allowed method list, and a freshness window; Gate runs the eight-stage order and consults Control. Application handlers only see traffic that cleared the boundary.
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.