--- title: "Independent evidence for x402 payment audits | Settlens" description: "Evidence for auditors, AppSec and risk teams: reproducible x402 checks, SARIF findings, SHA-256 report digests and ed25519 attestations you verify offline." url: https://settlens.com/use-cases/security-teams last_updated: 2026-10-13 --- # Independent, verifiable evidence for x402 payment reviews > **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. 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](https://settlens.com/contact) [See the evidence chain](https://settlens.com/use-cases/security-teams#evidence-chain) Real output from the bundled demo target, an endpoint deliberately built to unlock with an invalid signature. **Authorized fail-closed probe** ```text $ 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 ``` ## 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](https://settlens.com/learn/x402-security-checklist); our article on the [eight x402 failure modes](https://settlens.com/blog/x402-security-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. _Diagram: Evidence chain in four steps: a passive or authorized active scan produces a JSON report with a SHA-256 digest; an ed25519 attestation signs the digest with a key and a timestamp; a verifier checks it offline with evidence verify. Changing one value in the report makes verify-report and evidence verify answer INVALID._ _The JSON report is canonicalized with settlens-stable-json-v2 before hashing, so the digest is deterministic._ **Sign and verify a report** ```text $ 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** ```text $ 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](https://settlens.com/blog/signed-evidence-for-payment-assessments) walks through the forgeries each layer catches, including a report re-signed with another key. ## How an assessment runs 1. **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. 2. **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. 3. **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](https://settlens.com/product/evidence). 4. **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](https://settlens.com/docs/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](https://settlens.com/docs/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](https://settlens.com/docs/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](https://settlens.com/docs/security) 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. ## 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](https://settlens.com/contact) [Read the methodology](https://settlens.com/docs/methodology) ## Sources 1. [x402 protocol specification, version 2 (§7 facilitator interface, §10 security considerations)](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md) — x402 Foundation 2. [RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA)](https://www.rfc-editor.org/rfc/rfc8032) — IRTF 3. [FIPS 180-4: Secure Hash Standard (SHS)](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) — NIST 4. [Static Analysis Results Interchange Format (SARIF) Version 2.1.0](https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html) — OASIS 5. [SARIF support for code scanning (security-severity scores)](https://docs.github.com/en/code-security/reference/code-scanning/sarif-files/sarif-support) — GitHub Docs