Independent, verifiable evidence for x402 payment reviews

For auditors, AppSec and risk teams who must decide whether an x402 payment surface behaves as claimed. Settlens runs reproducible checks from outside, records what it observed and how, and lets anyone verify the report and its signature offline.

Request a pilot See the evidence chain

Real output from the bundled demo target, an endpoint deliberately built to unlock with an invalid signature.

Authorized fail-closed probe

$ settlens scan http://127.0.0.1:4402/bypass \
    --active --authorized --authorization-ref AUDIT-2026-014 --no-write
Settlens x402 assessment 8701a0bc
Targets 1 · Active 1 · Settlement calls 0
 
127.0.0.1  GET http://127.0.0.1:4402/bypass
13 pass · 1 fail · 1 warn · 0 skip
  FAIL critical Invalid payment authorization is denied
       The endpoint returned HTTP 200 after an invalid payment authorization.
  WARN medium   Invalid payment uses a standard failure status
       Expected HTTP 400 or 402 for invalid payment, received HTTP 200.
 
Total: 13 pass · 1 fail · 1 warn · 0 skip

In short

Settlens gives auditors, AppSec and risk teams reproducible x402 checks run from outside the payment, findings in JSON, HTML and SARIF, and an evidence chain they verify offline: a SHA-256 report digest plus an ed25519 attestation from a signing key they pin. Reports describe observed behavior, not a certification.

Who this is for

You are asked to approve a product that takes payments from AI agents, to assess a vendor or facilitator that does, or to keep a payment surface under continuous review. Vendor claims and screenshots are hard to check. You need findings tied to an exact target, tool version, configuration and authorization record, and a way to confirm that nobody edited them afterward.

Settlens is independent tooling: it observes x402 behavior from the outside, the way a paying client would, and never takes part in the payment. To scope a review, start from the x402 security checklist; our article on the eight x402 failure modes shows what each finding looks like on the wire.

What you can assess

Each finding maps to a documented check or command. Tags show the check id you will see in JSON, HTML and SARIF reports.

Payment bypass at the resource

With the owner's authorization, one invalid PAYMENT-SIGNATURE is sent. Any 2xx answer is a critical finding: the content is available without paying.

security.invalid_signature_fail_closed
Verification bypass at the facilitator

The same invalid payload is posted to the facilitator's /verify. isValid=true for an all-zero signature is critical.

security.facilitator_rejects_invalid_signature
Payments bound to the wrong resource

resource.url must equal the URL that was requested, path and query included.

binding.resource_url
Terms outside the approved policy

Recipients, assets, networks, schemes and the amount ceiling are compared with a reviewed configuration. In a scan, every advertised option must comply.

policy.recipient
Unstable terms

Identical unauthenticated requests should return identical terms. Drift can reveal recipient rotation, unintended dynamic pricing or tampering.

stability.payment_requirements
Captured payment authorizations

verify-payment recovers the EIP-3009 / EIP-712 signer offline and checks recipient, amount and validity window; every signature slot of a Solana transaction is checked too.

The evidence chain

Three links, each checked offline: the SHA-256 digest shows the report is unchanged since it was hashed, the ed25519 signature ties that digest to a key, and the public key, obtained through a channel you trust, ties the key to a signer. The digest alone is not a seal: whoever edits a report can recompute it.

The JSON report is canonicalized with settlens-stable-json-v2 before hashing, so the digest is deterministic.

Sign and verify a report

$ settlens evidence keygen --out settlens-evidence.key
Private key written to settlens-evidence.key (keep it secret).
Public key: 0x8d8c0d80a48b600dadf417ad9be2c1b1e5b9f5ad2947823282b35ef918be87ff
$ settlens evidence attest reports/settlens-b000e04e.json \
    --key settlens-evidence.key --out attestation.json
Attestation written to attestation.json
$ settlens evidence verify attestation.json \
    --report reports/settlens-b000e04e.json
VALID evidence attestation
Signature valid: true
Report matches:  true
Public key:      0x8d8c0d80a48b600dadf417ad9be2c1b1e5b9f5ad2947823282b35ef918be87ff

The same checks on an edited report

$ settlens verify-report tampered.json
INVALID Report content was modified after the evidence digest was created.
Expected: c10d1efc4e5597749014a47d6dc4ffb10e2abb850fa5fd86c99831059ec9f5fc
Actual:   4996c0769db96ac3bcfa39269b95ea83aeaa8cfb881e3af7a2e3b50c9eeb89c0
$ settlens evidence verify attestation.json --report tampered.json
INVALID evidence attestation
Signature valid: true
Report matches:  false
Public key:      0x8d8c0d80a48b600dadf417ad9be2c1b1e5b9f5ad2947823282b35ef918be87ff
Reasons:
  - The provided report failed its own integrity check.

Real output. The report comes from settlens check against the bundled demo target; tampered.json is a copy with one check message changed. The signature still verifies, but the report no longer matches its digest, so the attestation is rejected. Our article on signed evidence for payment assessments walks through the forgeries each layer catches, including a report re-signed with another key.

How an assessment runs

Scope it and record the approval

Passive scans need no special access. The active probe refuses to run without --active, --authorized and a non-empty --authorization-ref; the reference is stored in the report next to the target.
Run the checks

The report records the mode (passive, active-authorized, or passive-facilitator for a /supported scan), the tool version, the pinned @x402/core version and scope counters for settlement calls and private keys used, both zero by design.
Verify, sign and share

settlens verify-report recomputes the SHA-256 digest. settlens evidence attest signs it with an ed25519 key, and settlens evidence verify checks the signature and that the report is the one attested. See Evidence.
Track findings and regressions

Run settlens check on every change: it fails while a finding persists. Run settlens monitor on a schedule: it compares each passive scan with the previous run and exits non-zero on a regression at your threshold, once per change. See Monitor.

In SARIF, failing and warning checks become results. Failures at high or critical severity are errors and the rest warnings, each rule carries a security-severity (9.5 critical, 8.0 high, 5.0 medium, 2.0 low), and the run's invocation properties keep the report digest so a finding can be traced back to the signed report. See reports.

What a report contains, and what it leaves out

Recorded

Target URL, with credentials stripped and secret query values redacted
HTTP method and request header names
Response status, duration, size, SHA-256 of the body and header names
Every check with status, severity, message and evidence
Tool and official SDK versions, and the authorization reference for active runs

Left out

Request header values: custom headers are listed by name only
Paid resource response bodies: only their size and SHA-256 are kept (a facilitator scan keeps the validated /supported response)
Wallets and payment keys: scans never use them

Attestation fields
Field	Meaning
`kind`	Always settlens-evidence-attestation.
`version`	Attestation format version.
`canonicalization`	Canonical JSON form that was signed (settlens-stable-json-v2; older attestations without this field used v1).
`reportId`	Id of the attested report.
`productVersion`	Settlens version that produced the report.
`protocolVersion`	x402 protocol version assessed.
`subjects`	URLs of the assessed targets.
`summary`	Pass, fail, warn and skip counts.
`reportDigest`	SHA-256 integrity digest of the report.
`attestedAt`	Timestamp written by the signer's clock.
`publicKey`	ed25519 public key of the signer, hex encoded.
`signature`	ed25519 signature over all the fields above, in canonical JSON.

Result semantics follow the methodology: pass means the observed evidence satisfied the check, fail that it violated a required property, warn that risk or instability was observed, and skip that prerequisite evidence was missing. Severity expresses expected impact, from critical (payment protection can be bypassed) to info.

Limits to keep in mind

Evidence of observed behavior, not a certification

A passing report means the sampled endpoint behaved consistently with the tested properties during the recorded window. It does not establish the absence of vulnerabilities in untested code, on-chain settlement, uptime, economic safety, or legal or regulatory compliance.

An attestation proves which key signed which digest. It does not prove who holds the key: obtain the signer's public key through a channel you trust.
attestedAt comes from the signer's clock. It is not a trusted timestamp.
Check subjects and the target URLs: a valid attestation can cover a different endpoint from the one you care about.
The active probe tests one invalid payload class. Settlens does not check balances, on-chain nonce use or replay, or settlement, and never calls /settle.

Read the security model for the trust boundaries and residual risks of the tool itself.

Questions from security teams

Is a Settlens report a certification?

No. It is evidence of observed protocol behavior during the recorded window, tied to a tool version, a configuration and, for active runs, an authorization reference. It is not a certification or legal advice.

Can a vendor hand us a doctored report?

The digest alone does not stop it: anyone who edits a report can recompute its digest. The attestation does: an edited report no longer matches a digest signed by a key you trust. A vendor that runs the scan can still sign an edited report, or one about another endpoint, with its own key, so check the subjects and the public key, or run the scan yourself.

Do verification steps need network access?

No. verify-report, evidence verify and verify-payment run offline. Only scans contact the target.

Does Settlens test smart contracts or settlement?

No. It assesses the x402 HTTP handshake, the facilitator's /supported and /verify behavior and payment authorizations offline. It never calls /settle and never moves funds.

Can we run it inside our own CI or network?

Yes. Pilot participants receive the CLI (Node.js 20.19 or newer), the GitHub composite Action and a pinned non-root container image.

Sources

x402 protocol specification, version 2 (§7 facilitator interface, §10 security considerations)x402 Foundation · github.com
RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA)IRTF · rfc-editor.org
FIPS 180-4: Secure Hash Standard (SHS)NIST · csrc.nist.gov
Static Analysis Results Interchange Format (SARIF) Version 2.1.0OASIS · docs.oasis-open.org
SARIF support for code scanning (security-severity scores)GitHub Docs · docs.github.com

Get evidence you can check yourself

Tell us the endpoint, facilitator or agent flow in scope. The pilot ends with a report, its digest and a signed attestation you verify offline.

Request a pilot Read the methodology

Independent, verifiable evidence for x402 payment reviews

Payment bypass at the resource

Verification bypass at the facilitator

Payments bound to the wrong resource

Terms outside the approved policy

Unstable terms

Captured payment authorizations

Scope it and record the approval

Run the checks

Verify, sign and share

Track findings and regressions

Recorded

Left out

Sources

Get evidence you can check yourself