MCP needs a standard payment layer — x402 onboarding friction is losing users to MPP/Tempo #2436

This is exactly the kind of feedback that makes the harness better. The 5/20 result is a targeting issue, not a security issue, and the fact that the 5 that passed are the ones that actually matter (no data leaks, no session hijacking, rate limiting) is a clean result.

On the endpoint targeting: you're right, the harness assumes root URL returns 402, which is the simplest x402 flow but not how production implementations work. Adding --paid-path support is the right fix. I'll open an issue for this — the pattern should be:

agent-security test x402 --url https://apibase.com --paid-path /api/v1/tools/weather.current/call

The harness would hit --url for baseline probing (your homepage tests) and --paid-path for the 402 payment flow tests. That way both the general security properties (X4-007/010/011/017/018) and the payment-specific properties (facilitator validation, recipient manipulation, escrow behavior) get tested against the right endpoints.

On the escrow timing: the hard 10s timeout with AbortSignal + atomic PG transaction (REFUNDED or rollback) is clean. The partial-body-at-timeout-boundary case is worth testing explicitly — it's the kind of edge case where implementations silently diverge from the spec.

On the delegation token pattern: agreed that a scoped permission token (A signs for B, B presents alongside its own key) is the right direction for multi-hop workflows. That's also testable — our identity harness (18 tests) could validate that delegation tokens are properly scoped and can't be replayed or escalated.

Opening the --paid-path issue now. On the joint MCP payment spec contribution — let's do it. Your production escrow data + our adversarial test results is a stronger proposal than either alone. Happy to draft the test methodology section if you draft the escrow implementation section.

Quick update @whiteknightonhorse — shipped the --paid-path flag based on your feedback: PR #54

agent-security test x402 --url https://apibase.com --paid-path /api/v1/tools/weather.current/call

When set, payment-specific tests (challenge validation, facilitator trust, recipient manipulation) hit the paid path. General security tests still probe the base URL. Backward compatible — omitting the flag gives the same behavior as before.

Once merged, would appreciate a re-run against your production endpoint. The 5 tests that already passed (stateless sessions, no data leaks, rate limiting, clean error messages) should still pass, and the payment flow tests should now get proper 402 responses to validate against.

PR #54 is merged but the PyPI release is behind (3.2.0 on PyPI vs v3.6.0 on git). That is why the --paid-path flag is missing from the installed version. Cutting a PyPI release today to close that gap.

In the meantime, installing from git main should work:

pip install git+https://github.com/msaleme/red-team-blue-team-agent-fabric.git@main

If that still shows the error, the issue is the CLI entrypoint not picking up the new argparse flag from the merged code. I will verify and tag you when the release is live.

On the joint spec contribution: your four-point structure (escrow flow, cache-hit billing, idempotency, reconciliation) paired with our test methodology section is the right framing. Agree that targeting it as an MCP spec extension rather than standalone gives it more traction. Happy to co-author the test methodology section once you have the escrow draft started.

Update: v3.6.0 is now live on PyPI with the --paid-path flag. @whiteknightonhorse you should be able to install cleanly now:

pip install agent-security-harness==3.6.0
agent-security test x402 --url https://apibase.pro --paid-path /api/v1/tools/geo.geocode/call

Also expanded the x402 harness from 20 to 43 tests in this release, adding 18 health check validations (payment challenge completeness, currency validation, recipient verification, address format checks) and the identity verification tests that @FransDevelopment is contributing fixtures for.

Looking forward to your re-run results against the APIbase endpoints.

Lightning-first architectures like this are exactly why I pushed for the x402 harness to focus on semantics rather than a specific rail. If the platform enforces "agent calls tool → gets invoice → pays atomically" and the controls live in code, the payment surface area shrinks dramatically.

The two attack classes we keep seeing (regardless of whether it’s Lightning, x402, or L402) are: (1) spend bypasses — agents replaying or underpaying challenges, and (2) facilitator trust — someone swapping out the payee or session context mid-flight. That’s why I added the --paid-path flag + 18 health checks in v3.6.0. If the endpoint changes depending on which tool is being called, the harness needs to hit the real economic path.

Curious if you’ve found any gaps Lightning doesn’t solve, especially around facilitator trust or replay. Happy to compare notes if you’re willing to share details (even privately).

@giskard09 — perfect. This is exactly the kind of architectural data we need to make the L402 harness useful beyond the macaroon-native pattern.

Your BOLT11 + custom verification flow is actually a cleaner test target for the payment-layer tests than traditional L402. Here is what will be meaningful vs. noise:

Tests that should work as-is (7 of 14):

• L4-001/002: Payment challenge validation — your 402 response with BOLT11 invoice is functionally equivalent
• L4-005/006: Replay attacks — your markUsed() anti-replay is exactly what these test. If preimage-seen-twice returns 402, these should pass.
• L4-009: Session binding — your session_id bound to invoice memo maps directly
• L4-012: Budget exhaustion — burst payment requests
• L4-014: Timing attacks — measures whether payment verification leaks info through response timing

Tests that will fail by design (7 of 14):

• L4-003/004: Macaroon caveat manipulation — not applicable
• L4-007/008: Caveat chain escalation — not applicable
• L4-010/011: Third-party caveat delegation — not applicable (no facilitator in path)
• L4-013: Macaroon binding verification — not applicable

We do not have a --no-macaroon flag yet but this is a good reason to build one. For now, run as-is and we will use the results to design a --rail bolt11 mode that skips the macaroon-specific tests and focuses on the payment verification, replay protection, and session binding tests.

What the harness needs: Just a URL. Format:

pip install agent-security-harness==3.7.0
agent-security test l402 --url https://your-endpoint.com/paid-path

If your paid path requires POST + JSON body (like whiteknightonhorse's endpoint), add that context and we will include it in the --method flag shipping in v3.8.0 (#58).

The 1,700+ calls with zero orphaned payments is a strong operational claim. If the harness confirms the anti-replay and session binding hold under adversarial conditions, that is publishable validation data.

@msaleme @giskard09 — Frans from OATR here. Seeing OATR identity verification included in the security harness (X4-021/022/023) is exactly the right call for this use case. Before an MCP server processes an x402 payment, it should know which agent runtime is on the other side.

The core specs are ratified and the SDK is live. Here's everything you need to flip those 3 tests to native passing:

Install:

npm install @open-agent-trust/registry

Verify an agent attestation before processing payment:

import { OpenAgentTrustRegistry } from '@open-agent-trust/registry';

const registry = await OpenAgentTrustRegistry.load('https://registry.openagenttrust.com');
const agentJwt = request.headers['x-agent-attestation']; 

const result = await registry.verifyToken(agentJwt, 'https://your-api.com');

if (result.isValid) {
  // Identity verified — proceed to x402 payment flow
  console.log(`Verified agent from issuer: ${result.issuerId}`);
} else {
  return res.status(401).json({ error: 'Untrusted agent identity' });
}

CLI for manual testing:

npx @open-agent-trust/cli verify <JWT_STRING> --audience https://your-api.com

This slots in before the payment layer in the same defense-in-depth pattern @msaleme identified — AUTH before PAYMENT. The registry lookup confirms the agent's runtime is a trusted issuer, then x402 handles the economics.

Back to @whiteknightonhorse's original point — MCP needs a standard payment layer, agreed. But a payment spec without an identity layer means any anonymous caller can trigger payment flows. OATR solves the identity half: the MCP server knows who is paying before it decides whether to accept payment. If a payment transport spec lands in MCP, identity verification should be a recommended prerequisite, not an afterthought.

Happy to help with integration or provide test fixtures for the harness.

@FransDevelopment — alignment confirmed. The minute we added OATR verification tests (X4-021 through X4-027) the false positives vanished: we can now distinguish between endpoints that simply require auth (X4-013 returning 401 before payment) and endpoints that truly have missing attestation coverage.

Appreciate you building the a2a-oatr-reference server — that gives us the exact live target we needed to validate A2A-001/A2A-004 in a reproducible way. Will report back with any findings once the harness run is complete.

@giskard09 The Haiku agent case study is a perfect test for the payment layer. Once we wrap the --method/--body flag and the --rail bolt11 mode, I’ll run the x402 and L402 suites against that deployment. The facilitator trust and session binding tests will be the most interesting given phoenixd + markUsed().

Frans — thank you for the OATR fixtures and the reference server drop. I have X4-021/022/023 queued to run against it as soon as v3.8.0 lands with the new --method/--body flags, and I will file whatever issues shake out in that pass.

@whiteknightonhorse the dual-rail launch is exactly the data point we needed. I am carving out a dedicated Tempo/Stripe profile for the harness next:

• --rail tempo to exercise the WWW-Authenticate: Payment header + tempo invoice payload alongside the x402 body
• replay + amount-mismatch tests that hit both rails to make sure the proxy refuses half-signed responses
• mixed-wallet scenario coverage (Tempo wallet should never be offered x402-only invoices, Base wallet should never be offered MPP-only invoices)

Goal: first nightly with MPP coverage the week of March 31 right after the 3.8.0 release drops. I will ping this thread with a build link so APIbase can be the first external validation run.

Appreciate both of you pushing the ecosystem forward.

added similar request at the newly launched a2a protocol: a2aproject/A2A#1815 , which @msaleme already commented on

Real bug from running an x402 server in production, relevant to the spend-bypass and facilitator-trust points raised above.

Our server logged the settle result from the facilitator but never actually checked it before serving the paid data. Both the primary facilitator call and the on-chain fallback could fail and the server would still return 200 with the real data, because success or failure of settlement was never gated on. Separately, two of our endpoints treated any header that was not a recognizable payment format as though payment had succeeded, so a garbage string in the payment header was enough to get free access.

Neither of these was caught by us. A reader asked a technical question in a blog comment about whether verification was bound to the wallet or only the amount, and that question is what led to actually re-reading the code and finding both gaps. Fixed now: data is only built after a confirmed settle, and an unrecognized payment format returns an explicit 400 or 402 instead of falling through.

The reason I am bringing this up here is that both bugs are the kind a spec would catch by construction. Right now every implementer has to remember on their own that settle failure means reject, and that an invalid payment proof is not the same as no proof and both must be rejected. If a payment transport spec defines these as mandatory rejection states rather than something each server author has to think of independently, this exact class of bug stops being possible to ship by accident.

“x402 authenticates the wallet, not the intent” is the core issue. CAPI2 checks authority, policy, delivery and settlement as one portable receipt. Would a free endpoint preview help test that model? https://capi2-claim-verify.onrender.com/buy

Adding a merchant/operator note on the onboarding friction vs. “payment rail works” split.

We’ve seen the same pattern from the seller side of x402: the protocol settles fine once a payload is facilitator-clean, but cold agents (and cold human operators wiring agents) bounce on opaque failure modes that look like wallet/funding problems:

1. Silent validation as 402 — facilitator /verify rejects on field-length / metadata (e.g. resource.description Unicode code-point cliffs around a conservative ≤500 budget) and returns a bare or misleading 402. Sellers A/B description length and suddenly “demand appears.” Spec does not advertise this as a length rule; operators discover it in production (see Bazaar: a resource can be silently unpayable because its description is too long — document the limit and give it a distinct error x402-foundation/x402#2993 and adjacent Test issue to see if MCP docs server tools are usable by Copilot agent #2284 schema-union noise).
2. Empty-body / opaque 402 — unpaid probe returns 402 with no usable PAYMENT-REQUIRED body, so staging-vs-prod copy diffs look like payer setup bugs.
3. Settle-gated serve — @holistis’s Aug note is the complementary bug: logging facilitator settle without gating the paid response. Onboarding friction and spend-bypass are different classes; both kill trust.

For an MCP payment transport _meta / error -32042 shape, the highest-leverage additions for agent onboarding (regardless of rail: x402 vs MPP/Tempo) would be:

• A machine-readable reject class on non-paying probes (field_length | schema | auth_before_pay | insufficient_funds | facilitator_unreachable) so agents don’t burn wallet setup time on validation cliffs.
• A documented unpaid preflight (challenge shape + field budgets) that hosted wallets can run before asking the user to fund.
• Explicit settle-before-serve as a SHOULD for monetized tools, with a conformance vector.

Happy to compare failure-shape matrices with folks running dual-rail sellers; the agent-side “hours of docs vs 2 minutes hosted wallet” complaint is real, and a lot of that hour is illegible 402s rather than USDC mechanics.

@holistis thanks — that matches what we were pointing at, and the fix shape (gate on confirmed settle + explicit 400/402 for unparseable headers) is the right conformance bar.

Yes, please share the exact vectors if you can paste them here: junk-header → expected status, and structurally valid but crypto-fake-signed → expected status (and which settle field failed). Happy to treat those as settle-before-serve conformance cases.

One adjacent seller-side cell from our side, same class: facilitator eventually returns settle.success=true, but the merchant builds/serves the paid response before settle returns (race on the await). Log line looks healthy; spend-bypass still happens. Gating on the returned settle object — not on “we called settle” — catches that too.

Still comparing failure-shape matrices across sellers if useful; no other ask.

For an MCP payment layer, a useful split is create versus approve.

send21 prepares payment drafts and pay links. Agents create drafts with scoped keys that cannot spend. Humans sign in their own wallet. send21 never holds keys, never signs, never broadcasts.

That keeps fiscal safety on the human (or buyer control plane) while the agent still gets payment capability.

Supported: BTC, USDC, USDT, EURC on Bitcoin, Solana, Ethereum, Base. (Never USDT or BTC on Base.)

Testnet demo: https://send21.io/demo
MCP: https://send21.io/mcp
One-paste notes: https://send21.io/mcp
info@send21.io