Developer surface
ENI6MA Verify
DemoVerify (a customer-runnable attack suite that exercises a Gate deployment with adversarial traffic before real users do) is how a buyer sees the mechanism refuse to be replayed. It is a Demo-status developer surface, not a purchase SKU, and its whole job is to be pointed at your Gate so you can watch which reject stages fire against which attacks before you commit an estate.
Verify attack suite
Adversarial checklist icons against a live Gate
Verify / falsify
Falsifiable attack checklist icons for Verify demos
What Verify is
ENI6MA Verify is a customer-runnable attack suite against a Gate deployment.ValidatedDEMO-HACK adversary on :8092 and E6-A2A 21-attack suite.
- A DEMO-HACK adversary process that runs on port 8092 and exercises a live Gate deployment with hostile traffic.
- The E6-A2A 21-attack suite against Gate deployments, so a buyer can see the mechanism reject a full attack tree, not a curated single example.
- Demo status: it is a runnable demonstration artifact for evaluation, not a supported purchase SKU with a price.
- Pairs with the Ceremony demo and with the MCP and reverse-proxy Gate form factors, so the same suite covers the surfaces a buyer is most likely to deploy first.
How to use it
For a security engineer who wants to see this thing bite before trusting it in production.
- Stand up a Gate (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) in reverse-proxy or SDK form against a Control instance.
- Point Verify at the protected endpoint (a single API route or agent tool placed behind Gate; the unit of value on every commercial page) and let it run the attack suite.
- Inspect the reject stages and the burn evidence for each attack, so you can see the specific stage that stopped a replay, a forged envelope, or a stale nonce.
- Escalate to the gated Deployment Security Package under NDA when you need the full threat model and the mapping from every attack to the stage that rejects it.
Public pages stay mechanism-first on purpose. The detailed attack-to-reject mapping lives in the Deployment Security Package request, not on this page.
What a buyer walks away with
- Direct evidence that a captured envelope (a one-time cryptographic authorization for a single request, replacing the reusable bearer token or API key) does not authorize a second request against the same route.
- Direct evidence that the 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) property holds when a proof is malformed as well as when it is stolen.
- A mapping from Gate reject reasons to attack classes, which is what security engineering wants to see before signing.
- A repeatable script you can hand to your red team, so verification is not a one-time vendor demo.
See it run against your Gate
Verify is Demo status, so the path forward is a guided walkthrough or a self-run against a demo Gate. There is no purchase button on this page by design.