The signed record of Watch and Defend.
A statement your accounts' own key signs, that anyone can check without Warden.
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.
See what Watch finds
-
Defend: lock the attacker out.
Plan ready. One signature locks them out.
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
What each one does
- 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.
- 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.
- 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.
- 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.
- Shared. Your customers' procurement, your board, your investors. Adds the attack chains.
- 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.
Thank you. Your request is in.
We email the address you gave once, to confirm the request. Requests are approved by hand, and an approved one gets an invite link by email. No marketing is sent. To be taken off the list, write to support@wardensec.ai.
A request joins the Warden early access list; Plans shows what each licence carries.
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.