Developer surface
ENI6MA Verify
DemoVerify is a customer-runnable attack suite that points adversarial traffic at your Gate deployment before real users do. Mechanism: DEMO-HACK / E6-A2A suites drive replay, forged envelopes, stale nonces, and related attacks against a live protected endpoint. Observable outcome: reject stages and burn evidence for each attack - including burn-before-validate when a captured envelope is re-submitted. Scope: Demo status only - evaluation artifact, not a purchase SKU. Use it to falsify Gate placement on Cloud or Agent stacks before you commit an estate.
Verify attack suite
Adversarial checklist icons against a live Gate
Verify / falsify
Falsifiable attack checklist icons for Verify demos
- Attack
- Replay
- Conformance
- Live Gate
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: a runnable demonstration artifact for evaluation, not a supported purchase SKU with a price.
- Pairs with the Pass+ ceremony demo and with MCP and reverse-proxy Gate form factors, so the same suite covers the surfaces a buyer is most likely to deploy first.
- Produces stage-keyed reject evidence that Control visibility and on-call can correlate with burn events.
How to use it
For a security engineer who wants observable reject evidence before trusting Gate in production.
- Stand up Gate in reverse-proxy or SDK form (or the MCP wrapper Demo) against a Control instance with a durable ledger.
- Point Verify at the protected endpoint and run the attack suite; do not cache or reuse envelopes across runs - each proof is one-shot by design.
- Inspect reject stages and burn evidence for each attack: which stage stopped a replay, a forged envelope, a policy mismatch, or a stale nonce.
- Confirm burn-before-validate: a captured envelope re-submitted after burn fails even if cryptographic validation would later reject for another reason.
- 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. Absolute guarantees assume the reference architecture.
What a buyer walks away with
- Direct evidence that a captured envelope (one-time cryptographic authorization for a single request) does not authorize a second request against the same route.
- Direct evidence that burn-before-validate holds when a proof is malformed as well as when it is stolen.
- A mapping from Gate reject reasons to attack classes - what security engineering wants before signing.
- A repeatable script you can hand to your red team, so verification is not a one-time vendor demo.
- Confidence that Cloud-stack proxy/SDK placement or Agent-stack MCP placement fails closed under the attacks you care about.
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.