Make x402 payments safe to automate.

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 Check a 402 in your browser

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

evaluate_payment_requirements12 of 13 checks pass

Agent requestedGET 127.0.0.1:4402/premiumreceived402 PAYMENT-REQUIRED

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

decisiondo_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, computed under a complete spending policy when this page was built.

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.

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.

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

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

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

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

Scheduled
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

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

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

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

$ 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.

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.
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.
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.
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.

Recorded example: report, integrity and evidence

$ 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 Read the 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 How we handle 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.

ShellAdd Settlens to Claude Code

# 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

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

{
  "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 Try the free 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

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

Show that /supported is conformant and /verify rejects invalid signatures, with evidence partners can check.
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

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

All 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, or try the same check without an agent in the free 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.

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

Learn x402 security

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

Jul 31, 20269 min read

Agentic payments are moving real money. Here's 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 paymentsAI agentsx402MCP
Jul 31, 202611 min read

How to test an x402 payment endpoint: a practical checklist

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.

x402TestingGuideCI
Jul 31, 202610 min read

x402 security: the payment failure modes every implementation should test

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.

x402SecurityTesting

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

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?

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 All x402 security articles

Sources

x402 protocol specification, version 2x402 Foundation · github.com
x402 V2 HTTP transportx402 Foundation · github.com
Model Context Protocol specification (2025-06-18)Model Context Protocol · modelcontextprotocol.io

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 See pricing

Make x402 payments safe to automate.

A mis-advertised recipient

A drifting price

A resource that unlocks on an invalid signature

A facilitator that verifies garbage

Passive scan: everything looks right

Authorized probe: the bypass appears

The report names every check

Evidence anyone can verify offline

Offline

Passive

Facilitator

Active, authorized

Passive by default

Never pays

No custody

Authorized probing only

Secrets stay out of evidence

Signed, verifiable evidence

Sources

Start with one endpoint, facilitator or agent flow