Agent preflight · Checks before your agent commits

Check the terms before your agent commits.

Before an agent pays a 402 challenge, acts under a delegation, deals with another agent or relies on an operator, it can check what it has been handed. Agent preflight runs thirteen checks over the material your agent sends and returns a signed report: pay or refuse for a payment challenge, the gaps in a delegation, the consistency of an identity record and the coverage of a continuity plan. Round 2 adds the agent card another agent publishes, the MCP server configuration you are about to install, and an operator's succession, handover and recovery arrangements. Round 3 reads your own arrangements before you commit to them: your spending policy, your approval chain, the terms of a service you are about to pay for and your incident plan.

Tool access
0.10 USDC / call
Checks
Thirteen checks
Connection
/mcp
Result
Signed report

The thirteen checks.

Round 1 has four checks for payments, delegations, identities and continuity. Round 2 adds five for agent cards, MCP server configurations and operator arrangements. Round 3 adds four for your own spending policy, approval chain, service terms and incident plan.

Round 1

wever_payment-policy-check

Reads
One x402 payment challenge as your agent received it (the 402 body, one payment requirements object or the base64 PAYMENT-REQUIRED header) and your spending policy: per-call cap, daily cap, what you have spent today, allowed networks, allowed assets and an optional recipient allowlist.
The signed report states
Pay or refuse, the reason for every rule that fails, and the amount, asset, network, recipient and authorization window restated from the challenge itself. When a challenge offers several ways to pay, each offer is checked and the first one that passes every rule is named.

wever_delegation-check

Reads
A delegation or mandate document as written, its fields (grantee, scope, caps, expiry, revocation and approvals), or both. Scope can list each action with its own cap, expiry and approval.
The signed report states
Each of the six elements present, missing or ambiguous, with quotes, and every delegated action that has no cap or no expiry reaching it. Open-ended scope, generic grantees, limits stated only in words and terms that run until revoked are named plainly.

wever_agent-identity-check

Reads
An agent identity record as JSON or text: an ERC-8004 registration file, a passport excerpt or any record with an agent ID, name, endpoints or services, wallet, operator and registrations.
The signed report states
Each identity element present or missing, and the record checked against itself: the agent ID against its registrations, one wallet across every field that names one, HTTPS endpoints on public host names, EIP-55 wallet checksums and CAIP-10 registry formats.

wever_continuity-check

Reads
An operator's continuity arrangements as written, by area, or both: key custody, the successor or recovery contact, standing jobs, subscriptions, escrowed work and the export path for records.
The signed report states
Each area covered, partial or not covered, with quotes, and the gaps named plainly: a single point of failure in key custody, no successor, no plan for standing jobs, subscriptions or escrowed work, and no export path for records.

Round 2

Agent cards, server configurations and operator arrangements.

These checks cover what an agent relies on beyond a single payment: the card another agent publishes, the MCP server it is about to add, and how an operator passes on, hands over and recovers what it runs.

wever_agent-card-check

Reads
An A2A agent card as JSON: name, description, url, provider, version, skills, the authentication schemes in securitySchemes and security (or authentication on earlier cards) and capabilities.
The signed report states
Each card element present or missing, and the card checked against itself: the card URL and every other published address on HTTPS and a public host, every skill with an id, a name and a description, every authentication requirement backed by a named scheme with the fields its type needs, and capabilities declared as true or false.

wever_mcp-server-check

Reads
An MCP server configuration as pasted into a client config: an mcpServers or servers map, or one entry. A remote entry has a url and headers; a local entry has a command, args and env.
The signed report states
Each problem named plainly: no server name, a URL that is not HTTPS, credentials in the address, an auth header that is empty, still a placeholder or reads an undefined input, and secret-looking values written into the configuration. The report names where each secret-looking value sits and what it looks like, and leaves the value itself out. The check reads the configuration as supplied and leaves the server untouched.

wever_succession-brief

Reads
An operator's succession arrangements as written, as fields or both: the successor, the trigger, how the keys and the accounts transfer, the timeline and what the successor receives.
The signed report states
A short brief that restates the arrangement in order, in its own words, each element stated, partial or missing, with the gaps named: no successor named, no trigger defined, no transfer path for keys or accounts, no timeline, or nothing said about what the successor receives.

wever_handover-check

Reads
A handover package description as written, by area, or both: credentials and custody transfer, runbooks, billing ownership, domains and DNS, data export and open obligations.
The signed report states
Each area covered, partial or not covered, with quotes; the tasks a receiver could run on day one and the ones it could not, each tied to its area; and the gaps named.

wever_recovery-readiness-check

Reads
Recovery arrangements as written, by area, or both: backups and their recency, the key recovery method, export paths for records and catalogs, restore steps and any evidence the restore was tested.
The signed report states
Each area ready, partial or missing, with quotes and the dates read, and the weakest links named plainly, missing areas first and key recovery first among them.

Round 3

Your own spending, approvals, service terms and incident plan.

These checks read the arrangements your agent works under before it commits to them: the spending policy that caps it, the approval chain that signs off on it, the terms of a service it is about to start paying for and the incident plan it relies on when something breaks. For a counterparty's own material, such as its insurance, audit report, data processing agreement or NDA, the DiligenceOps assurance checks read it the same way.

wever_spending-policy-check

Reads
Your agent's spending policy as written, as fields or both: the per-call cap, the daily cap, allowed assets and networks, the recipient rule, approval thresholds, the way to stop the agent and the categories it may spend on.
The signed report states
Each control present, missing or ambiguous, with quotes, and the dangerous shapes named plainly: a category with no cap, a daily cap with no per-call cap, a per-call cap with nothing capping the total, spending stated as unlimited, any recipient, asset or network allowed, and no way to stop the agent.

wever_approval-chain-check

Reads
Your approval and escalation arrangement as written, as amount bands or both: who or what approves at which amounts, when two approvers sign, the fallback approver and when an approval lapses.
The signed report states
The amount bands laid end to end from zero, with who approves each one and whether it takes two approvers, and the gaps named: an amount range no one approves, a single approver with no ceiling, no fallback when the approver is unavailable and approvals that never expire.

wever_service-terms-check

Reads
The terms of a service your agent is about to start paying for, as text, fields or both: price and price changes, renewal, the liability cap, indemnity, termination and data use, with the amount the service can move when you send it.
The signed report states
Each term restated in one plain sentence from the paying side, and the one-sided and missing terms flagged: a price that can change with no notice, renewal with no way to cancel, a liability cap below what the service can move, one-way indemnity, no termination path for you and broad data use.

wever_incident-plan-check

Reads
Your incident response plan as written, by area, or both: detection, severity levels, notification windows, named roles, customer communication, postmortems and what happens when an incident involves payments.
The signed report states
Each area covered, partial or not covered, with quotes, the severity levels and notification windows it reads, and the gaps named: no notification window, no named owner, no customer communication, no postmortem practice and no path for an incident that involves payments.

How the payment policy check decides.

Every rule runs on every offer in the challenge. The verdict is pay when the challenge is well formed and an offer passes every rule; otherwise it is refuse, with the reason for each rule that failed.

RulePasses when
challenge_well_formedThe challenge matches the x402 version 1 or version 2 schema.
offer_presentThe challenge carries at least one payment offer; up to 20 are checked.
network_allowedThe offer's network is on your list. Version 1 names such as base read as their CAIP-2 identifiers, such as eip155:8453.
asset_allowedThe offer's asset is on your list, by address, or as USDC for the USDC addresses on Base and Base Sepolia.
recipient_allowedWhen you send an allowlist, the offer pays an address on it.
per_call_capThe amount, scaled by the asset's decimals, is at or under your per-call cap.
daily_capWhat you have spent today plus the amount is at or under your daily cap.
expiry_statedThe challenge states a positive authorization window (maxTimeoutSeconds), restated as the time it would run to from the check.

Amounts compare exactly. A challenge states its amount in the asset's smallest unit, so the check scales it by the asset's decimals before comparing it with caps written in whole units: 100000 is 0.10 USDC. USDC on eip155:8453 and eip155:84532 is known by address; for any other asset, send its decimals with the policy.

What the other checks look for.

Delegation elements

  • Grantee
  • Scope of actions
  • Caps
  • Expiry
  • Revocation terms
  • Approval requirements

Each delegated action is also checked for a cap and an expiry of its own or one that covers the whole delegation.

Identity elements

  • Agent ID
  • Name
  • Endpoints or services
  • Wallet
  • Operator
  • Registrations

The record is then checked against itself, field by field, for matching IDs and wallets, HTTPS endpoints and valid formats.

Continuity areas

  • Key custody
  • Successor or recovery contact
  • Standing jobs
  • Subscriptions
  • Escrowed work
  • Records export path

An area is covered when the plan says what happens, partial when it is only mentioned or left to be decided.

Agent card elements

  • Name
  • Description
  • Card URL
  • Provider
  • Version
  • Skills
  • Authentication schemes
  • Capabilities

The card is then checked against itself: HTTPS addresses, complete skills and authentication backed by named schemes.

Succession, in order

  • Who takes over
  • What sets it off
  • How the keys pass
  • How the accounts pass
  • On what timeline
  • What the successor receives

The brief restates each element in this order in the arrangement's own words and names each gap.

Handover areas

  • Credentials and custody
  • Runbooks
  • Billing ownership
  • Domains and DNS
  • Data export
  • Open obligations

Each covered area is a task the receiver can run on day one.

Recovery areas

  • Backups and their recency
  • Key recovery method
  • Export paths for records and catalogs
  • Restore steps
  • Evidence the restore was tested

Backups read as ready within 7 days of the check, and a restore test within 180 days.

Spending policy controls

  • Per-call cap
  • Daily cap
  • Allowed assets
  • Allowed networks
  • Recipient rule or allowlist
  • Approval thresholds
  • Kill switch or revocation path

Caps are compared exactly, and every category the agent may spend on is checked for a cap of its own.

Approval chain elements

  • Approvers by amount band
  • Dual-control threshold
  • Fallback approver
  • Expiry on approvals

The bands are laid end to end from zero, so every amount has an approver or shows up as a gap.

Service terms, in order

  • Price
  • Price changes and notice
  • Auto-renewal and cancellation
  • Liability cap
  • Indemnity
  • Termination
  • Data use

Each term is restated in one sentence; a liability cap tied to fees paid is worked out from the stated price.

Incident plan areas

  • Detection
  • Severity levels
  • Notification windows
  • Named roles
  • Customer communication
  • Postmortem practice
  • Incidents that involve payments

An area is covered when the plan says how: a named monitor, a time window, a named owner or a payment action.

A short worked example

Should your agent pay this challenge?

The request

{
  "name": "wever_payment-policy-check",
  "arguments": {
    "challenge": {
      "x402Version": 2,
      "resource": {
        "url": "https://api.example.com/v1/quotes"
      },
      "accepts": [
        {
          "scheme": "exact",
          "network": "eip155:8453",
          "amount": "100000",
          "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
          "payTo": "0xc3837428F0e36E2573025c4A22E0F774FB3Cee3e",
          "maxTimeoutSeconds": 120
        }
      ]
    },
    "policy": {
      "per_call_cap": "0.25",
      "daily_cap": "5.00",
      "spent_today": "4.95",
      "allowed_networks": [
        "base"
      ],
      "allowed_assets": [
        "USDC"
      ]
    }
  }
}

What the report returns

  • Verdict: refuse.
  • Daily cap: 4.95 spent today plus 0.10 is 5.05 USDC, above the daily cap of 5.00 by 0.05.
  • Per-call cap: 0.10 USDC is within the per-call cap of 0.25.
  • Restated from the challenge: 0.10 USDC (100000 atomic units) on eip155:8453 to 0xc3837428F0e36E2573025c4A22E0F774FB3Cee3e, with a 120-second authorization window.
  • Network and asset: base reads as eip155:8453, and the asset is USDC on Base.

The same challenge with less spent today comes back pay, naming the offer to pay with.

A round 2 worked example

Is this MCP server configuration ready to install?

The request

{
  "name": "wever_mcp-server-check",
  "arguments": {
    "config": {
      "mcpServers": {
        "quotes": {
          "url": "http://mcp.example.com/mcp",
          "headers": {
            "Authorization": "Bearer "
          }
        },
        "files": {
          "command": "npx",
          "args": [
            "-y",
            "example-files-mcp@1.4.0"
          ],
          "env": {
            "FILES_API_KEY": "example-not-a-real-key-7Q2"
          }
        }
      }
    }
  }
}

What the report returns

  • Verdict: problems_found, with two server entries read.
  • url_not_https: the quotes server URL uses http, not HTTPS.
  • auth_header_empty: its Authorization header is present with no credential in it.
  • secret_in_config: FILES_API_KEY holds a secret-looking value written into the configuration, reported by its location, mcpServers.files.env.FILES_API_KEY, and its kind.
  • The files server runs a pinned package with npx -y, so it raises no advisory note.

Move the key into the client's secret store, reference it from the environment, and serve the quotes server over HTTPS with its token in the header, and the same configuration comes back no_problems.

A round 3 worked example

Is this spending policy safe to run under?

The request

{
  "name": "wever_spending-policy-check",
  "arguments": {
    "text": "Each payment is capped at 0.50 USDC.\nThe agent may also buy software subscriptions.\nPay only in USDC on Base."
  }
}

What the report returns

  • Verdict: dangerous_shapes_found.
  • category_without_cap: the agent may spend on software subscriptions with no cap stated for it.
  • per_call_cap_without_period_cap: each payment is capped at 0.50 USDC, but nothing caps the total.
  • no_way_to_stop: the policy gives no way to stop the agent or revoke its spending.
  • Present: the per-call cap, allowed assets (USDC) and allowed networks (Base). Missing: the daily cap, the recipient rule, approval thresholds and the way to stop the agent.

Add a daily cap, a cap for subscriptions and a way to pause the agent, and the dangerous shapes clear; the report then lists the controls still to add.

What each check reads.

Every check works from the material in the call: the challenge exactly as the endpoint returned it, the delegation as written, the identity record and the agent card as published, the server configuration as pasted, the continuity, succession, handover and recovery arrangements as the operator states them, and your own spending policy, approval chain, service terms and incident plan as you have written them. Wever evaluates it and signs the result. Paying, acting under the delegation and dealing with the other party stay with your agent, which keeps the signed report as the record of what it checked and when.

Each report says in one line how it was reached: the payment policy check evaluates the challenge against the policy rule by rule, the identity and agent card checks hold the record against itself, the MCP server check evaluates the configuration entry by entry, the delegation, continuity, succession, handover, recovery and incident plan checks match words, figures, dates and named items in the text, and the spending policy, approval chain and service terms checks also compare the amounts they read exactly.

Call it from your agent.

Connect to https://weverlabs.com/mcp and call any of the thirteen checks. Each call costs 0.10 USDC on Base. Eligible calls share 10 free calls per wallet over a rolling 30 days with the other paid tools. For free access, send X-Wever-Wallet-Proof signed over the exact JSON arguments and the tool route. The payment challenge supplies the x402 terms for a paid call.

Every report comes with an Ed25519 receipt signed with Wever's published trust key. The contract lists the schemas, rules, statuses and how to verify a receipt. To check an endpoint itself before you depend on it, use the endpoint reliability check; for the vendor pages and policies your agent relies on, see the DiligenceOps checks.