---
title: "x402 security and testing for agentic payments | Settlens"
description: "x402 security and testing for agentic payments: Settlens checks paid APIs and facilitators, gates CI, monitors drift, signs evidence and vets 402s via MCP."
url: https://settlens.com/
last_updated: 2026-10-13
---

# Make x402 payments safe to automate.

> **In short:** Settlens is a security and conformance tool for x402 agentic payments. It scans paid APIs and facilitators, gates CI, monitors drift, signs evidence and gives AI agents a pay, review or do_not_pay preflight over MCP, without ever paying, settling or holding funds.

Settlens brings x402 security to agentic payments by checking all three sides. API sellers show that their paid endpoints advertise the right recipient, price and resource and refuse invalid signatures. Facilitators show that /verify rejects them. AI agents check each HTTP 402 against a spending policy before they pay.

[Request a pilot](https://settlens.com/contact) [Check a 402 in your browser](https://settlens.com/tools/x402-checker)

Passive by default. No wallet, no payment keys, no custody.

evaluate\_payment\_requirements 12 of 13 checks pass

Agent requested `GET 127.0.0.1:4402/premium` received `402 PAYMENT-REQUIRED`

- **scheme:** `exact` — Pass `policy.scheme`
- **network:** `eip155:84532` — Pass `policy.network`
- **amount:** `10000` — Pass `policy.maximum_amount`
- **asset:** `0x036C…CF7e` — Pass `policy.asset`
- **payTo:** `0x2096…287C` — Pass `policy.recipient`
- **resource.url:** `127.0.0.1:4402/secure` — Fail `binding.resource_url`

decision do_not_pay

resource.url does not match the URL being assessed.

_Scenario: an agent asks for /premium and receives the demo /secure payment request. The checks and the verdict are real output of the [Settlens MCP server](https://settlens.com/mcp), computed under a complete spending policy when this page was built._

## In agentic payments, the costly failures are silent

With x402, a paid API answers HTTP 402 with machine-readable terms and an agent can pay without a human in the loop. When those terms, or their enforcement, are wrong, nothing crashes. The agent pays, or the content is served, and every log line looks normal.

- **A mis-advertised recipient**

  The `payTo` address changes through a configuration error or a compromised server, and agents keep paying someone else. Caught by `policy.recipient` against your allowlist, and by `stability.payment_requirements` when it changes between requests.

- **A drifting price**

  The amount differs between identical requests or rises above what was approved. Caught by `stability.payment_requirements` and, against your ceiling, by `policy.maximum_amount`.

- **A resource that unlocks on an invalid signature**

  The server checks that a `PAYMENT-SIGNATURE` is present, not that it is valid, so anyone gets the content for free. Caught by `security.invalid_signature_fail_closed`.

- **A facilitator that verifies garbage**

  The facilitator's `/verify` answers `isValid: true` for an all-zero signature. Caught by `security.facilitator_rejects_invalid_signature`.

## One set of checks, from first scan to signed evidence

Every stage reuses the same check catalog, so a finding means the same thing in a pilot report, in CI and in production monitoring. Agents run the offline checks from the same catalog as a preflight.

_Diagram: The Settlens assurance loop: Assess, CI gate, Monitor and Evidence in sequence, with the fix for a regression found by Monitor going back through the CI gate. Below, AI agents call the MCP preflight on every HTTP 402 and receive pay, review or do_not_pay._

_Four stages for the teams that run x402 endpoints, one preflight for the agents that pay them._

- **[Assess](https://settlens.com/product/assess)**

  Scan the 402 handshake, PAYMENT-REQUIRED and every advertised requirement, plus the facilitator's GET /supported. The fail-closed probe runs only with explicit authorization.

  Passive by default

- **[CI gate](https://settlens.com/product/ci)**

  Run your target configuration in pull request workflows, fail the job at your fail-on severity and write SARIF for code scanning.

  GitHub Action

- **[Monitor](https://settlens.com/product/monitor)**

  Compare each passive scan with a stored baseline, flag regressions, POST an optional webhook alert and exit non-zero at your threshold.

  Scheduled

- **[Evidence](https://settlens.com/product/evidence)**

  Sign a report's SHA-256 digest and a timestamp with your own ed25519 key, so a partner or auditor can verify it offline.

  ed25519

- **[Verify](https://settlens.com/product/verify)**

  Recover the signer of a captured EIP-3009 authorization and check recipient, amount, asset and validity window. Solana transaction signers too.

  Offline, no RPC

- **[MCP preflight](https://settlens.com/mcp)**

  Agents call evaluate_payment_requirements on every HTTP 402 and get pay, review or do_not_pay, with the reasons.

  For AI agents

[All product capabilities](https://settlens.com/product)

## A recorded run: the bypass a passive scan cannot see

The demo server that ships with Settlens includes /bypass, an endpoint that advertises valid x402 V2 terms but serves its content for any PAYMENT-SIGNATURE. The first transcript shows steps 1 and 2; the second picks up from the report.

**Recorded demo run (excerpt): /bypass accepts invalid signatures by design**

```text
$ settlens scan http://127.0.0.1:4402/bypass
Settlens x402 assessment ac276b3e
Targets 1 · Active 0 · Settlement calls 0
13 pass · 0 fail · 0 warn · 0 skip
 
$ settlens scan http://127.0.0.1:4402/bypass \
    --facilitator http://127.0.0.1:4402/facilitator \
    --active --authorized --authorization-ref DEMO-APPROVAL-002
Settlens x402 assessment 19fc4364
Targets 1 · Active 1 · Settlement calls 0
25 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.
```

1. **Passive scan: everything looks right**

   13 checks pass. The 402 status, the PAYMENT-REQUIRED header, the official SDK schema, the resource binding and the stability of the terms are all correct.

2. **Authorized probe: the bypass appears**

   With the owner's authorization and a reference, Settlens sends one intentionally invalid `PAYMENT-SIGNATURE`. The facilitator's `/verify` rejects it, yet the resource answers HTTP 200, so `security.invalid_signature_fail_closed` fails at critical severity.

3. **The report names every check**

   The JSON report lists each result by check id, records `settlementCalls: 0` and `privateKeysUsed: 0`, and `verify-report` recomputes its SHA-256 digest.

4. **Evidence anyone can verify offline**

   `evidence attest` binds the report digest to your ed25519 key and a timestamp. `evidence verify` checks the signature and that the report is the one attested.

> **Recorded example**
>
> Captured on October 13, 2026 with Settlens 0.5.0 and `npm run demo:server` on 127.0.0.1. `settlens` is the CLI's command name; in a checkout you can run `node src/cli.js`. Report ids, digests and keys change on every run. Try it yourself with the [quickstart](https://settlens.com/docs/quickstart).

**Recorded example: report, integrity and evidence**

```text
$ jq -r '.targets[0].checks[] | select(.status != "pass")
    | "\(.status) \(.severity) \(.id)"' reports/settlens-19fc4364.json
fail critical security.invalid_signature_fail_closed
warn medium transport.invalid_payment_status
$ jq -c .scope reports/settlens-19fc4364.json
{"targetCount":1,"activeTargetCount":1,"settlementCalls":0,"privateKeysUsed":0}
$ settlens verify-report reports/settlens-19fc4364.json
VALID Report content matches its SHA-256 evidence digest.
Expected: d5c00c1f2ae0431340a566fb6b6cd6c90645db872f483c0c5efbbb698fdae09d
Actual:   d5c00c1f2ae0431340a566fb6b6cd6c90645db872f483c0c5efbbb698fdae09d
$ settlens evidence keygen --out evidence.key
Private key written to evidence.key (keep it secret).
Public key: 0x3ec0418921368b1b88e90b132699167c594d2e7d36bb6bc0c7a087b21fa708f7
$ settlens evidence attest reports/settlens-19fc4364.json \
    --key evidence.key --out attestation.json
Attestation written to attestation.json
$ settlens evidence verify attestation.json \
    --report reports/settlens-19fc4364.json
VALID evidence attestation
Signature valid: true
Report matches:  true
Public key:      0x3ec0418921368b1b88e90b132699167c594d2e7d36bb6bc0c7a087b21fa708f7
```

## What Settlens checks

36 checks in four modes. Each has a stable id, a default severity, an explanation of why it matters and a documented fix, linked to the x402 V2 specification where one applies.

- **Offline**

  Evaluated from the PAYMENT-REQUIRED content alone. Runs in passive scans and in the MCP preflight.

  13 checks

- **Passive**

  Needs a live, unauthenticated request to the paid resource. Never sends a payment.

  7 checks

- **Facilitator**

  Reads the facilitator's GET /supported capabilities: schema, V2 support, signers and coverage of the advertised requirements.

  10 checks

- **Active, authorized**

  Runs only with explicit authorization and sends one invalid PAYMENT-SIGNATURE. /settle is never called.

  6 checks

_A selection of checks from the catalog_

| Check id | What it verifies | Mode | Default severity |
| --- | --- | --- | --- |
| `transport.status_402` | Unauthenticated request requires payment | passive | high |
| `schema.official_x402_sdk` | Official x402 SDK accepts PaymentRequired | offline | high |
| `binding.resource_url` | Payment requirement is bound to the requested resource | offline | high |
| `schema.payment_requirements` | Accepted payment requirements are well formed | offline | high |
| `policy.recipient` | Recipients match the local policy | offline | high |
| `policy.asset` | Assets match the local policy | offline | high |
| `policy.maximum_amount` | Amounts stay within the approved ceiling | offline | high |
| `stability.payment_requirements` | Payment requirements remain stable | passive | medium |
| `transport.redirect` | Payment endpoint does not redirect unexpectedly | passive | medium |
| `facilitator.requirement_coverage` | Facilitator covers advertised payment requirements | facilitator | high |
| `security.invalid_signature_fail_closed` | Invalid payment authorization is denied | active | critical |
| `security.facilitator_rejects_invalid_signature` | Facilitator /verify rejects an invalid signature | active | critical |

[Browse every check](https://settlens.com/docs/checks) [Read the methodology](https://settlens.com/docs/methodology)

## Security principles built into the tool

Settlens is designed so that running it cannot move money, leak your secrets or overstate what it observed.

- **Settlement calls:** 0 — Each report records settlementCalls
- **Private keys used by a scan:** 0 — Each report records privateKeysUsed
- **Invalid signature per active probe:** 1 — Only with explicit authorization
- **Report formats:** 3 — JSON, HTML and SARIF

- **Passive by default**

  A scan sends ordinary requests with no payment, two by default, follows no redirect and reads at most 1 MiB of each response.

- **Never pays**

  Settlens never calls /settle and never sends a real payment. A PAYMENT-SIGNATURE you supply is rejected outright; the active probe only ever sends an invalid one.

- **No custody**

  No wallet, no payment key, no funds: the only key is the ed25519 key that signs your evidence. Settlens is not a blockchain and has no token.

- **Authorized probing only**

  The active probe needs `--active`, `--authorized` and an `--authorization-ref`, and that reference is written into the report.

- **Secrets stay out of evidence**

  Reports keep request header names but not their values, store a digest instead of the response body and redact credentials and secret query parameters in URLs. Custom headers only go to hosts you allowlist.

- **Signed, verifiable evidence**

  Every JSON report carries a deterministic SHA-256 digest. An ed25519 attestation binds it to a signing identity and a time, verifiable offline.

[Security model](https://settlens.com/docs/security) [How we handle security](https://settlens.com/security)

## A preflight check for AI agents

The Settlens MCP server lets Claude and any other MCP client check an x402 payment request before paying. It never signs, never pays and never needs a key.

On every HTTP 402, the agent passes the `PAYMENT-REQUIRED` header, the URL it requested and its spending policy to `evaluate_payment_requirements`. Settlens validates the request offline with the official `@x402/core` schema, checks that it is bound to that URL, validates every payment option and applies the policy.

- **do_not_pay**: a high or critical check failed. The agent must not pay.
- **review**: something needs a human, including a policy that does not bound the recipient, the asset, the network and the amount.
- **pay**: every protocol check passed and an advertised option fits the policy. The agent pays only with an entry listed in `acceptable`.

The remote endpoint at `https://settlens.com/mcp` serves the offline tools publicly. The passive network tools, `scan_endpoint` and `scan_facilitator`, need a bearer token there and are always available in the local stdio server.

No agent yet? Paste a `PAYMENT-REQUIRED` header in the [free x402 checker](https://settlens.com/tools/x402-checker) to run the same evaluation from your browser.

Read the [MCP reference](https://settlens.com/docs/mcp) for every tool's inputs and outputs, [how to write an agent spending policy](https://settlens.com/learn/agent-spending-policy), or [why agents should verify before paying](https://settlens.com/blog/mcp-verify-before-paying).

**Add Settlens to Claude Code**

```shell
# Remote endpoint: the offline tools, no install
claude mcp add --transport http settlens https://settlens.com/mcp

# Local stdio server from your pilot checkout: every tool
claude mcp add settlens -- node /absolute/path/to/settlens/src/cli.js mcp
```

**Result (excerpt): the demo /secure request, evaluated for /premium**

```json
{
  "decision": "do_not_pay",
  "summary": "Do not pay: 1 blocking problem(s) found.",
  "reasons": [
    "binding.resource_url: resource.url does not match the URL being assessed."
  ],
  "acceptable": []
}
```

[Set up the MCP server](https://settlens.com/mcp) [Try the free x402 checker](https://settlens.com/tools/x402-checker)

## Who Settlens is for

Four kinds of teams work with x402 payments. Each needs a different answer from the same checks.

- **[API sellers](https://settlens.com/use-cases/api-sellers)**

  Prove your paid endpoints advertise the right terms and fail closed before agents rely on them.

- **[Facilitators](https://settlens.com/use-cases/facilitators)**

  Show that /supported is conformant and /verify rejects invalid signatures, with evidence partners can check.

- **[Agent builders](https://settlens.com/use-cases/agent-builders)**

  Give agents a policy-bound preflight on every 402, so a mis-advertised request is stopped or sent to a human before payment.

- **[Security teams](https://settlens.com/use-cases/security-teams)**

  Run authorized, reproducible x402 assessments and hand over signed, offline-verifiable reports.

[All use cases](https://settlens.com/use-cases)

## Questions, answered plainly

**Does Settlens move funds or need a wallet?**

No. Settlens never calls /settle, never sends a valid payment and needs no wallet or payment key. The only payment data it ever sends is one intentionally invalid signature, and only during an authorized active probe. Every report records zero settlement calls and zero private keys used.

**Is it safe to run against a production endpoint?**

Passive mode sends ordinary requests with no payment, two by default, follows no redirect and reads a bounded response. The active probe runs only with `--active`, `--authorized` and an authorization reference from the endpoint owner. Only test endpoints you own or are allowed to assess.

**How do AI agents use Settlens?**

Through the MCP server. On every HTTP 402 the agent calls `evaluate_payment_requirements` with the header, the requested URL and its spending policy, and receives `pay`, `review` or `do_not_pay` with the reasons. See [the MCP server](https://settlens.com/mcp), or try the same check without an agent in the [free x402 checker](https://settlens.com/tools/x402-checker).

**What does a passing report prove?**

That the sampled endpoint behaved as the checks require during the recorded run. It does not prove the absence of other vulnerabilities, and Settlens does not check on-chain balances, nonce use or settlement. A report is evidence of observed behavior, not a certification or legal advice. [Read the methodology](https://settlens.com/docs/methodology).

**How do I get Settlens?**

Settlens lives in a private repository. Pilot participants get the CLI (Node.js 20.19 or newer), the GitHub Action and the Dockerfile. It is not distributed on npm. Request a pilot to get access.

**Is there a Settlens token?**

No. Settlens is not a blockchain, has no token and never takes custody of funds.

[All questions](https://settlens.com/faq)

## Learn x402 security

How x402 payments work, what to check before agents pay and the failure modes we test for, in guides and articles.

1. Jul 31, 2026 9 min read

   **[Agentic payments are moving real money. Here's what breaks.](https://settlens.com/blog/agentic-payments-what-breaks)**

   When AI agents pay APIs over x402, no human checks the price, recipient or chain. Where agentic payments break, and what agents and sellers should verify.

   Agentic payments AI agents x402 MCP

2. Jul 31, 2026 11 min read

   **[How to test an x402 payment endpoint: a practical checklist](https://settlens.com/blog/how-to-test-x402-endpoint)**

   A step-by-step guide to testing an x402 V2 endpoint: passive scan, policy, facilitator checks, the authorized fail-closed probe, offline verification and CI.

   x402 Testing Guide CI

3. Jul 31, 2026 10 min read

   **[x402 security: the payment failure modes every implementation should test](https://settlens.com/blog/x402-security-failure-modes)**

   Eight ways x402 payment endpoints fail quietly, from fail-open resources and forged signatures at /verify to drift and weak binding, and how to test each one.

   x402 Security Testing

- **[x402 security checklist](https://settlens.com/learn/x402-security-checklist)**

  A printable x402 security checklist for resource servers, facilitators and AI agent clients, with the Settlens check that tests each control where one exists.

- **[EIP-3009 and EIP-712 in x402 payments](https://settlens.com/learn/eip-3009)**

  How EIP-3009 transferWithAuthorization and the EIP-712 domain power x402 exact EVM payments, field by field, and what can be verified offline versus on chain.

- **[What is x402?](https://settlens.com/learn/what-is-x402)**

  x402 turns HTTP 402 into a machine-readable payment handshake. Learn the roles, the V2 flow step by step, schemes, CAIP-2 networks and common failure modes.

[All x402 security guides](https://settlens.com/learn) [All x402 security articles](https://settlens.com/blog)

## Start with one endpoint, facilitator or agent flow

A scoped pilot on one endpoint, facilitator or agent flow, with a report your engineers and partners can verify.

[Request a pilot](https://settlens.com/contact) [See pricing](https://settlens.com/pricing)

## Sources

1. [x402 protocol specification, version 2](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md) — x402 Foundation
2. [x402 V2 HTTP transport](https://github.com/x402-foundation/x402/blob/main/specs/transports-v2/http.md) — x402 Foundation
3. [Model Context Protocol specification (2025-06-18)](https://modelcontextprotocol.io/specification/2025-06-18) — Model Context Protocol