The signed record of Watch and Defend.

A statement your accounts' own key signs, that anyone can check without Warden.

Check a signed record. The file is a wd.proof/1 statement in strict JSON, every field in its allowed form.Nothing in it is an account id or something one can be read from.The accounts' key the statement names signed it, and nothing changed after signing.Its scope, result and cycle counts add up, and a partial scope says so.Every opening it carries matches the statement, and none reaches past its audience.It was current at the moment this page judged it.
The open verifier runs in your browser; warden proof verify runs it offline.

What exists, in early access.

  • The standard, v1
  • The signed statement
  • The browser verifier
  • The offline check
Each one, and where to see it
  • The standard, v1. Nine rules a test run must meet before its statement counts as a signed record. Read the standard.
  • The signed statement. One wd.proof/1 file, signed with your accounts' own key, that attests one run in one scope on stated dates. What it must carry.
  • The browser verifier. Checks a statement in the reader's own browser with the open verifier. Nothing is uploaded. Verify a statement.
  • The offline check. warden proof verify runs the same checks on the same file, with no network. The checks it runs.

Each is marked early access. The test run that produces a record is not in a release, so there is no signed record to show yet; it is listed under planned after the first release.

The record of Watch and Defend.

The signed record has no plan of its own: Watch and Defend produce it, in early access.

  • Watch: harden and catch.

    What to fix first. Who got in.

    The demo's Findings page, worst first. Critical, 5, and 4 more in a case above: a publicly accessible database open to the internet on its port, on analytics-pg-test, ops-metrics-db and orders-replica-2; a new access key on ci-deploy-bot, whose existing key is aged; and a bucket readable by anyone, customer-uploads-staging. Then High, 34, starting with an EKS node launch template that launches nodes with a metadata hop limit above 1, on eks-ng-prod-eu-spot, eks-ng-platform and eks-ng-payments-batch. See what Watch finds
  • Defend: lock the attacker out.

    Plan ready. One signature locks them out.

    The top of the demo's signing page, Sign the response. You are signing as alice@example.com: read this, and if it is what you mean, sign with your passkey. One signature covers the whole plan: signing runs all 8 steps now, each one undoable.

    Every step is undoable. Defend's role cannot terminate machines, delete data or create identities.

    See how one signature works

The signed record Early access Watch and Defend's record, signed with your own account's key; anyone can check it in a browser. Public verifier

Screens from the live demo, on recorded data.
What each one does
  1. Watch: harden and catch. Reads your AWS accounts and Kubernetes clusters, read-only, ranks what to fix first by what an attacker could reach, and turns a break-in into one case.
  2. Defend: lock the attacker out. Drafts the plan for each case, every step undoable; one passkey signature runs it and keeps containing what the attacker creates next.
  3. The signed record Early access Watch and Defend's record, signed with your own account's key; anyone can check it in a browser.

What a statement attests.

One run, in one scope, on stated dates, signed with your accounts' own key.

Who sees what

A statement opens three ways, and a file never opens more than its audience allows.

  1. Public. Anyone with the file or its link. The result, the scope and the dates. Never an account id, a resource name or a person.
  2. Shared. Your customers' procurement, your board, your investors. Adds the attack chains.
  3. Sealed evidence. An auditor. Adds where the run started and its subject, opened from your own bucket, never through Warden.

The outcome word reads plain "Held" only when no tested goal was reached and analysis found no path to a real data store. Otherwise it says how many paths analysis found, at every level, public included.

Every human-latency figure is printed with "approvers knew a run was on".

Check it yourself.

The open verifier runs in your browser, or offline with warden proof verify.

What it checks
  • The file is a wd.proof/1 statement in strict JSON, every field in its allowed form.
  • Nothing in it is an account id or something one can be read from.
  • The accounts' key the statement names signed it, and nothing changed after signing.
  • Its scope, result and cycle counts add up, and a partial scope says so.
  • Every opening it carries matches the statement, and none reaches past its audience.
  • It was current at the moment this page judged it.

A file alone cannot show:

  • that the accounts' key belongs to the domain named (the domain's own DNS record);
  • that Warden's public log of signed records recorded it on its date, under a signed tree head;
  • that a genuine Warden release produced it;
  • that an approver approved its publication;
  • that it meets the published standard, v1.

The rules a run must meet are public: the standard, v1.

Be among the first.

We use your email only for this request.

What we keep
Add your company and number of AWS accounts Optional

A request joins the Warden early access list; Plans shows what each licence carries.

Engineering evidence

How Warden tests its own build

Before every release, Warden's build replays its own attack and benign corpus through the detection pipeline; every number on that page is read from the files the build writes: how each release is tested. It is the vendor's record of its own build, not a signed record of your accounts. The rules a signed record meets: the standard, v1.