background gif
eni6ma

Demos · Verify

Demo

A green happy path is not proof that replay, retarget, and tamper paths are closed. Verify shows the exact checks a Gate deployment must pass, then the same suite can be pointed at your own deployment before real users arrive.

Verify walkthrough

Verify (a customer-runnable attack suite that exercises a Gate deployment with adversarial traffic before real users do) is meant to be pointed at your own deployment. It proves in one run that a well-formed request is allowed and that captured, retargeted, or tampered requests are rejected at the correct stage. The site deliberately does not publish a residual-risk table for someone else's deployment; the number that matters is the one Verify produces against yours.

For an integrator, Verify slots into a CI/CD pipeline the same way a smoke-test suite would: it takes a base URL, exercises the protected endpoint (a single API route or agent tool placed behind Gate; the unit of value on every commercial page), and returns a pass or a fail per check with the stage of the emitted reject captured for the log.

Replay is impossible by design.ShippingThe nonce is burned before validation in a durable ledger; it is spent even when validation later fails.Holds under the reference architecture

The falsifiable checklist

Each row is written so that you can look at a real run and decide, without interpretation, whether it passed or failed. If a check does not have an observable pass criterion, it does not belong in this list.

Verify / falsify

Falsifiable attack checklist icons for Verify demos

Verify attack suite

Adversarial checklist icons against a live Gate

  • Health

    What passing looks like: Every process in the deployment (client, server, registry, and the adversary if it is running) returns HTTP 200 on /api/health, so a red result on any later check is a real signal rather than a startup race.

  • Allow path

    What passing looks like: A first poll with a fresh envelope (a one-time cryptographic authorization for a single request, replacing the reusable bearer token or API key) returns headlines, and the transcript records the expected sequence: envelope received, nonce burned, twin proof validated, resource served.

  • Replay reject

    What passing looks like: Re-submitting the exact same envelope a second time fails at stage=nonce, and there is no successful fetch attributable to that nonce in the server log. This is the concrete evidence that 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) is doing what it says.

  • Binding rejects

    What passing looks like: Three tampered variants all fail before the protected endpoint runs: a body-tampered envelope fails at the request-hash stage, an envelope retargeted to a different route fails at the endpoint stage, and an envelope submitted with a loosened policy fails at the policy-hash stage.

  • Model B (optional, registry-backed validation)

    What passing looks like: With 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) reachable, a fresh poll still allows and the server log records that validation ran through the registry rather than locally.

What a replay reject looks like on the wire4 events
  • canon

    Canonicalized request body

    identical bytes to prior envelope

    0.00s
  • envelope

    Envelope received

    same nonce_uuid as previous ALLOW

    0.01s
  • burn

    Nonce already consumed

    stage=nonce · replay detected

    0.02s
  • verdict

    REJECT: envelope already spent

    A captured envelope is not authority to spend the request a second time.

    0.02s
Screenshot pending: the Verify dashboard after a full run, with pass markers on each check.

Smoke commands you can run today

The first tab is the health probe that has to succeed before any adversarial check will produce meaningful output. The second describes the replay experiment the suite runs against a live deployment; the shape is deliberately simple so you can reproduce it by hand against a Gate you already have.

curl -sf http://localhost:8091/api/health
curl -sf http://localhost:8090/api/health
curl -sf http://localhost:8093/api/health
ENI6MA VerifySecurity architectureRequest Deployment Security Package