Browser data
The site stores the selected light or dark theme in browser local storage. The site code does not include advertising, analytics trackers, or third-party auto-loaded fonts, scripts, or images. Links to external sites load only when you follow them.
Scans and audits
Free demo scans and paid payload scans transmit the payload and optional context to the API for analysis. The application does not write those scan requests to an application data store. Do not submit private keys, seed phrases, API credentials, personal data, or other material you are not authorized to process.
Endpoint audits process the target URL and any custom prompts supplied by the caller. When an audit completes, Warden persists a public badge record containing the target host, grade, score, blocked and total counts, issue date, audit ID, and integrity signature. The detailed audit response is returned to the caller; the badge record is available through the public badge APIs.
Opt-in feedback and retention
A scan never creates a feedback record by itself. The separate
POST /api/feedback route accepts only a structured
outcome, observed verdict, implemented threat class, and a
reproducer that you have already redacted. Submission requires
literal true confirmations that Warden may retain the
record and that the reproducer is redacted. The route has no field
for the original scan payload, an endpoint, wallet, submitter
details, or arbitrary metadata. Warden cannot establish that your
redaction removed every sensitive value.
A pending record contains the redacted reproducer, its structured labels, submission and expiry times, scanner version, corpus fingerprint, and internal duplicate and content digests. It is assigned a 90-day expiry. Expired records are excluded and the queue file is compacted on its next read or write. A record may be removed sooner when the private queue reaches its 5,000-record cap. Scanner-equivalent Unicode and whitespace-normalized duplicate submissions reference one retained record. Stored identifiers and content digests are rechecked before review or aggregation. HTTP infrastructure may still process the operational metadata described below.
The public /api/threat-intel/v1/summary route exposes
aggregate counts only for outcome and threat-class groups with at
least five accepted records. Smaller groups are absent from the
cells, published total, and observation-window start, so the route
does not expose their exact size or timing. Submitted text, record
identifiers, digests, endpoints, wallets, and submitter details
are not published by that separately rate-limited route. These
self-reported counts do not measure threat prevalence.
Feedback does not update a detector automatically. An operator may promote a consented redacted reproducer only after human review, and only into one training or held-out dataset after scanner-equivalent duplicate and cross-dataset checks under the same promotion lock used by Gauntlet review. A promoted reproducer may be published as part of that dataset and may remain there beyond the pending queue's 90-day period.
Gauntlet retention
Every Gauntlet attempt creates an append-only record with hashes of the payload and declared intent, timestamp, verdict, risk level, threat classes, and claim status. A pending Gauntlet claim produced by an ALLOW verdict also retains the raw payload, declared intent, context, and optional finder name so a human can review whether it is a genuine bypass.
BLOCK and SANITIZE attempts do not retain the raw payload or intent in the Gauntlet store. Duplicate pending claims retain a reference to the existing claim rather than a second raw submission. No automatic deletion period is currently implemented for these records, so submit only material you are comfortable retaining for security review.
For a human-confirmed bypass, the raw submitted payload is not published. A reviewer prepares and rescans a publishable redacted reproducer; that first confirmed reproducer enters only the held-out benchmark. A separate redacted training reproducer may enter the training corpus only when the submission includes explicit training-use consent and rights confirmation and an operator completes a distinct second review. The training row records certificate-bound first-party provenance and a consent digest.
The public WARDEN BREAKER certificate contains the held-out reproducer's payload digest, assigned threat class, confirmation time, log position, and either a consented finder handle or an anonymous credit. It does not contain the private claim, raw submission, declared intent, or private review context. Warden does not authenticate account ownership. Finder handles are self-asserted.
Public records and payment rails
Issued badge records are public through
/api/badges and /badge/{audit_id}. The
marketplace security index is built from public OKX.AI listing
data, not visitor data.
Confirmed WARDEN BREAKER certificates are public through
/api/demo/gauntlet/breakers,
/api/demo/gauntlet/breakers/{certificate_id}, the
shared transparency log, and their /verify?breaker=
permalinks. Pending and rejected claims are not listed.
Paid calls use x402 settlement on X Layer. Blockchain addresses and transactions are public by design, and the payment facilitator processes the signed payment payload. Warden's browser pages do not request or store a wallet private key.
Operational metadata
The application is served behind HTTP infrastructure that may process request metadata such as IP address, timestamp, route, user agent, and response status under operator policy. This repository does not publish a retention period for infrastructure logs and does not provide an authenticated account or self-service deletion endpoint.
Independent service
Warden is an independent service listed on OKX.AI. It does not claim endorsement by OKX or OKLink. Their services and privacy practices are governed by their own terms.
Read the service terms summary for authorization, payment, and disclaimer boundaries.