DEV Community: Jiangw2718i

The median MCP server installs 94 packages, and 88% pull an HTTP framework into a stdio process

Jiangw2718i — Fri, 31 Jul 2026 13:19:26 +0000

I built an MCP server this week. Before publishing it I did the thing I would want someone else to do: I looked at what installing it actually puts on your machine.

Installing it pulled down 95 packages. My server is two files and 145 lines. It exposes one read-only tool. It speaks JSON-RPC over its own stdin and stdout, and it never opens a socket.

Inside those 95 packages were express, hono, and @hono/node-server.

That bothered me enough to ask whether it was just me. It was not. I measured every npm-packaged stdio server in the official MCP registry — 6,139 of them, 6,030 resolvable — and the median install is 94 packages. For the 88% built on the v1 SDK the median is 95, which is exactly where mine landed, without trying.

The interesting part turned out not to be the number. It is that almost nobody chose it, and that you cannot see it in anything they wrote down.

What I measured

The official MCP registry held 18,990 servers when I pulled it, 18,788 marked active. Filtering to entries that ship an npm package and declare stdio transport gives 6,139 distinct npm packages. That is the population.

For each one I asked npm what a production install resolves to:

npm install <package>@<version> \
  --omit=dev --package-lock-only --no-audit --ignore-scripts

--package-lock-only resolves the full tree without downloading a single tarball, which is the only reason 6,139 packages is feasible at all.

The scripts and the measured data are in the repo, at research/mcp-dependency-census. This post makes claims about its own instrument, so the instrument ships with it. Running article_numbers.py reprints the population, distribution, framework and SDK figures below, each labelled as it appears here. The figures that need the network — the sampled dependency declarations, the SDK-version table, and the sizes — are not in it.

6,030 resolved. 109 did not, and it is worth saying why: 58 declare a version that is not published on npm, 29 name a package that is not on npm at all, 19 have an identifier npm cannot parse as a spec, and 3 failed otherwise — one refused this platform, one timed out, one exited non-zero. Those 109 are excluded from every number below.

One wording note I will use consistently: each row is an npm package, not a server. 166 packages appear in the registry under two different server names, and I count those once.

Checking the ruler, twice, because the first check was worthless

I got a result that could not be true. A server package occupies one slot plus whatever the SDK brings, so a server depending on the SDK had to be larger than the SDK alone. My data said the median server was smaller.

I had two counting rules and had not noticed. Install locations counts every node_modules/… entry — content-type appears three times in the SDK's tree, at two versions, because of a conflict deeper down. Distinct package names collapses those three into one. My validation measured install locations and agreed with a real npm install. My measurement counted distinct names. I validated one ruler and then measured with a different one.

So I fixed it, re-ran, and validated six packages against real installs. Six out of six agreed, and I nearly shipped that sentence as my proof of rigour.

It was not proof of anything. All six of those packages have zero platform-specific optional dependencies — and that is the one failure mode this instrument has. --package-lock-only writes a lockfile entry for every platform variant of an optionalDependency; a real install unpacks only the ones matching your OS and CPU. For kubernetes-mcp-server@0.0.65 the lockfile lists 7 and a real install creates 2. My validation set could not have detected that if it tried.

Two instruments later — npm install --dry-run --json looked authoritative and then undercounted appium-mcp by 43% against its own real install — I settled on gating optional entries by os/cpu, and validated it the way it should have been validated the first time: real installs on 150 randomly chosen packages from the actual population.

	packages	exact match
no optional entries	128	128 (100%)
has optional entries	21	18 (86%)
all	149	146 (98.0%)

Three overcounts, by 1.5% to 2.0%. Not one undercount. Sample median: 94 measured, 94 real. So the numbers below were exact for 98% of a random sample, never low in it, and at worst 2% high on trees carrying platform-specific binaries. The median is untouched, because the trees sitting at the median contain no optional entries at all.

I am spelling this out because the first version of this post contained a section congratulating itself for checking its instrument, using a check that was structurally incapable of finding the bug it still had.

The distribution

packages installed	packages	share
1	443	7.3%
2–5	118	2.0%
6–20	72	1.2%
21–50	60	1.0%
51–100	3,281	54.4%
101–250	1,846	30.6%
251+	210	3.5%

Median 94. First quartile also 94 — 2,356 packages resolve to exactly 94, and 52.6% of the population sits within five packages of it. The heaviest resolves 2,052.

5,280 of 6,030 — 87.6% — install an HTTP server framework:

framework	packages
`express`	5,276
`hono`	5,203
`@hono/node-server`	5,202
`koa`	22
`fastify`	19
`connect`	7

Every one of these declares stdio transport in the registry.

Where the wall at 94 comes from

87.8% of these packages have @modelcontextprotocol/sdk, the v1 SDK, in their production tree. On its own that package resolves to 93 install locations. express, hono, @hono/node-server, cors, jose, ajv, and express-rate-limit are all in its dependencies — not optional, not peer. They install regardless of which transport you use.

Of the 4,992 packages resolving SDK v1 at its current version, 45.9% land on exactly 94: themselves, plus the SDK's 93, and nothing else that npm has to unpack.

I want to be careful about what that does and does not mean, because in the first draft of this post I got it wrong. It does not mean those authors declared one dependency. I sampled 400 of them and read their published dependencies: 35.8% declared exactly one, most declared two, and some declared four. A server can list zod, cross-spawn and zod-to-json-schema and still land on 94, because all three are already inside the SDK's tree. "Adds nothing" is a fact about deduplication, not about authorship. My first draft quietly promoted one into the other, in the sentence carrying the whole moral argument.

What survives is narrower and still worth saying: of the 5,280 packages carrying an HTTP framework, 99.1% have the v1 SDK. Almost no one typed express.

The number nobody chose

Here is the part I missed entirely on the first pass, and it is the most important thing in this post.

94 is not what any of these authors pinned. It is what today's npm floats their ranges to. In 400 sampled packages, 400 declared a caret range on the SDK. Not one pinned a version. And the SDK's weight has grown a great deal:

SDK version	published	install locations	`express`	`hono`
1.0.0	2024-11-25	14	no	no
1.10.0	2025-04-17	82	yes	no
1.20.0	2025-10-09	88	yes	no
1.25.0	2025-12-15	92	yes	yes
1.30.0	2026-07-27	93	yes	yes

A server published against ^1.0.0 in late 2024 installed about 14 packages the day it shipped. The same unchanged package.json installs 94 today. express arrived in the SDK's dependencies around April 2025 and hono in December 2025 — neither is ancient, and neither required anything of the 5,203 servers that now carry them.

So my first draft's line about "what that one line used to cost" had the arrow backwards. Nothing these authors wrote got heavier. A caret range did what caret ranges do, upstream added an HTTP stack, and 5,295 dependency trees grew without a single commit in any of them. The wall at 94 is a photograph of one afternoon's npm, not a property of anybody's code.

That also means this post has a shelf life, and that re-running it after the next SDK release will not reproduce these numbers. I could not demonstrate drift at the scale of a day — I re-resolved 413 random rows hours later and every one matched — but it follows mechanically from 400 caret ranges out of 400.

What changed three days ago

On 2026-07-27 the TypeScript SDK shipped v2, splitting the monolith: @modelcontextprotocol/server, @modelcontextprotocol/core beneath it, and HTTP framework adapters (/express, /fastify, /hono) as separate packages you install only if you serve HTTP.

I migrated. My server went from 95 packages to 5. npm install frisk-mcp now pulls the package itself plus @modelcontextprotocol/server, @modelcontextprotocol/core, zod, and my own screening library. No web framework. Both numbers count the same way every number above does: the package itself plus everything npm unpacks for it. The code change was two import lines; the rest was fixing what the codemod did to my dependencies — it put the MCP client package into runtime deps, where a server does not need it.

At the time of measurement 27 of 6,030 — 0.4% — had v2 in the tree, three days after release. And that 0.4% is softer than it sounds: 9 of the 27 also still carry v1 and the full express-plus-hono stack, resolving between 101 and 361 packages. A third of the v2 cohort has shed nothing yet.

What I am not claiming

A dependency is not a vulnerability. Ninety-four packages is not ninety-four problems, express is not unsafe, and nothing here says any of these servers is compromised or badly written. I measured package counts, not risk.

On stdio versus HTTP: the registry declares stdio for every entry I counted, and the framework is a hard dependency of the v1 SDK, so it lands in the tree either way. But some of these packages do serve HTTP as well, and rather than say "I did not audit that" — which is what the first draft said, and which was the more flattering choice — I went and counted: 176 of the 6,139 also ship a streamable-http package entry, and 759 active registry entries pair an npm stdio package with a remote HTTP endpoint. For those, the framework is not dead weight. That is under 3% of the population, and it does not rescue the other 97%.

On the comparison group: it is tempting to point at the 717 packages with no MCP SDK in the tree, note their median install is 1, and call that the counterfactual. It is not clean. All 443 single-package rows are in that group — 62% of it — and I say below that I would not vouch for a quarter of those. The median of 1 is produced by exactly the rows I am least willing to defend, so I am not resting the causal claim on it. The claim rests on the SDK's own dependency list and on 45.9% landing on 94 to the package.

On the single-package rows: median unpacked size 38 KB; 33% over 100 KB and plausibly bundling their dependencies at build time; 25% under 10 KB, small enough that I would not assume there is a working server inside.

On versions: I measured the version each registry entry declares. npx -y <package> installs whatever is latest on npm instead, which can resolve to a different tree than the one I counted.

Why I care about this one

I work on payment screening for agents. What I am paid to worry about is what an autonomous agent is about to hand money to. An MCP server sits closer to that decision than almost anything else on the machine: it runs with your agent's privileges, on your credentials, in the same process tree.

Which is why it is worth stating plainly that my own server — the one whose job is to be suspicious of things — was carrying a web framework it has no code path to reach, and that I only know because I looked. And then that my first attempt at looking was wrong twice: once about which ruler I was using, once about what the ruler could not see.

If you maintain an MCP server, the check takes about ten seconds. Do it as a real install in an empty directory, not with --dry-run — that is one of the two instruments I caught being wrong:

mkdir /tmp/dep-check && cd /tmp/dep-check && npm init -y
npm install <your-package> --omit=dev

The last line npm prints is added N packages. If that number surprises you, the migration guide is upgrade-to-v2.md, and there is a codemod. Read what it does to your dependencies block before you commit it.

Frisk is an MIT-licensed screening library for agent payments. The MCP server described here is frisk-mcp.

A changed payTo address is not a honeypot: 272 payTo changes, 13 lookalikes, zero proof

Jiangw2718i — Sun, 26 Jul 2026 05:17:44 +0000

In my last post I listed the ways an x402 payment can go wrong. Vector number one was the dynamic payTo swap: in x402 the destination address can change per request, so a seller can quote you address A and then take payment to address B. I said it was one of the checkable ones.

So I built the check, wired it into Frisk's hosted reputation side, and pointed it at the x402 Bazaar — the public directory of paid endpoints — on a daily crawl. The idea was simple: remember each endpoint's advertised payTo, and if it changes, that is a swap, so flag the counterparty.

Over about a month it recorded 272 payTo changes across 246 endpoints, and promoted them into 57 honeypot:payto_swap reputation labels.

Then I looked at what it had actually flagged. The endpoint with the most flags in the entire dataset was x402.browserbase.com, with 9. Second was x402.tavily.com, with 8. Browserbase and Tavily are real, funded infrastructure companies. My detector had scored them 0 and told callers they were honeypots.

Those flags were wrong. So were the rest. What took longer to admit is that they were wrong in five separate ways, and only one of them was the mistake I thought I was making.

What the label actually said

Before the excuses, the exact damage. A honeypot:payto_swap label drives the trust score to 0 and raises a high severity signal. At the default strictness of 0.3 that returns a review verdict, escalating to block for a strict caller or any payment over 1000. So Frisk did not literally say "do not pay" — it said "stop and look at this one," which is bad enough when the counterparty is a legitimate vendor rotating a key.

Worse is the reason string that came with it, which was hardcoded:

observed in active probing: payto_swap

Nothing had probed them. These labels came from a passive daily crawl of a public directory. The snapshot job was borrowing the active probe's language, so the API was telling callers it had tested something it never touched. That is the part I find hardest to write down.

Two things keep this from being a disaster rather than an embarrassment: the hosted API has three keys issued and one active, so almost nobody could have read those labels — and the local, MIT-licensed screening library that most people actually use never had this bug, because it never sees other people's addresses at all.

What a rotating crawl can actually see

Here is the whole flawed idea in one line: the address changed, therefore something is wrong.

Start with what the crawler can see. It runs once a day and walks a rotating window of 8,000 listings. I had described this as a "daily snapshot," which was wrong twice over. The registry is not a fixed size — my table has accumulated 41,286 endpoint URLs since I started, and never deletes, while the live directory reports a total of about 14,345 today, drifting by a few between pulls. Against a registry that size an endpoint comes back around every three to five days, not daily, and the tail goes longer.

It is worse than that. While writing this I checked the crawl cursor and found it had been stuck since 2026-07-23. The registry shrank below the saved offset, so every run fetched an empty window and returned early without rewinding the cursor. Three days of no data collection, silently, because the resume logic could not handle a registry that gets smaller. That is fixed now — an empty window rewinds to zero — but a detector whose evidence depends on visit cadence had been quietly not visiting.

So when the crawler sees address A on one visit and address B on the next, all it knows is A -> B, somewhere inside a multi-day gap. That fact is identical whether:

an honest operator rotated its receiving wallet on a schedule, or migrated its whole fleet to a new treasury address, or
an attacker quietly swapped in a wallet they control.

Nothing in A -> B, observed days apart, distinguishes those. The address change is not evidence of fraud. It is evidence of an address change.

	count
payTo changes recorded	272
distinct endpoints affected	246
distinct addresses labeled	57
accounted for by a single fleet migration	109 (40%)
matched the address-poisoning lookalike shape	13
that the crawl could prove were an attack	0

The vendors were not rotating nine times. I was sampling nine times.

The first thing that fell apart was my own headline number.

Browserbase's endpoint produced 9 recorded changes, Tavily's 8. But when I lined the rows up, no address ever appeared twice. Browserbase's chain runs through ten distinct addresses across those nine changes; Tavily's through nine. Not one repeat, and not one return to a previous address.

That is not a vendor who rotated nine times. That is a vendor whose address changes at least as often as I look, measured by a crawler that happened to look nine times. My "rotation count" was a fact about my cron schedule. And "the two worst offenders" was wrong in its own right — by raw flag count they rank fifth and sixth, behind hosts that contributed 109, 28, 21 and 15 rows. They only top the list per endpoint: one endpoint each, changing every single visit.

You can watch it happen live. Pulling the public discovery API three times over about three hours while writing this, each vendor advertised a different Base address every time:

x402.tavily.com        0x2a09d4fd…fa09a  ->  0x68459d07…091af  ->  0x043d2e40…29c7
x402.browserbase.com   0x61ce240e…0633e  ->  0x100f307A…13834  ->  0xC09B2303…be12

Two pulls seventy seconds apart returned identical addresses, so this is not per-request minting visible from the directory — but it is comfortably faster than a crawler that comes back every three to five days.

Tavily also publishes something worth reading carefully. Its listing quotes two rails, and the second one is not an address at all:

eip155:8453   0x043d2e40ced48199415f3b2463d0bfab4fc029c7
aws:base      urn:x402:agent-pay:see-quote

A placeholder meaning the address is decided when you ask for a quote. I want to be precise here, because I got this wrong in an earlier draft of this post: Tavily does advertise a concrete Base address on the standard EVM rail, and that address is the one my pipeline reads. The placeholder sits on a separate rail. But it is still the operator saying out loud that the payment address is not a stable identifier.

Fresh-address-per-payment is a deliberate design — whatever the motive, it is the opposite of negligent — and a reputation system built on "the address should stay the same" declares the most carefully built endpoints to be the most dangerous ones. That is the failure mode exactly backwards.

Forty percent of my evidence was one event

Of the 272 changes, 109 came from a single host on a single day, every one of them the same old address moving to the same new address. One operator moved its treasury and my detector recorded it 109 times, then wrote a reputation label as if 109 endpoints had independently gone bad. The next largest cluster is 27, also one host, also one day.

Counting one business decision 109 times is how a scary-looking number gets built. It is also trivially fixable: three or more endpoints under one host making the identical move now collapse into a single observation.

The 13 that looked like an attack

I do not get to claim the whole dataset was innocent, because 13 of the changes were not ordinary rotation. They belonged to one operator — ten endpoints spread across four subdomains of a single gateway — and each moved between two addresses that are identical except for one character:

0xb3c2776ce3f99…942ab6
0xb3c2776ce4f99…942ab6

Forty-two characters counting the 0x; forty hex digits, of which thirty-nine match. Same leading characters, same trailing characters, one digit different in between. That is the copy-paste-poisoning shape — a near-twin address swapped in so a human eyeballing the ends signs off on it — and it is exactly what my lookalike class was built to catch.

It is also, on inspection, impossible to be that.

Address poisoning works by mining a vanity address: you generate keypairs until one lands on an address whose first and last few characters match your target. Matching six characters is cheap. Matching thirty-nine of forty is not — you would be searching on the order of 2^156 keys for the privilege. Nobody mined the second address to look like the first. For the same reason, this cannot be one operator deliberately alternating between two near-twin wallets it controls: nobody can generate that pair on purpose either. Both are plain externally-owned accounts with no contract code, so no CREATE2 salt-grinding produced them either — and that grind costs the same 2^156.

The rows do not describe a swap, either. Ten endpoints moved from …ce3… to …ce4…, and then three moved back. Right now the gateway serves both addresses side by side: on one page of a thousand listings I count 22 pointing at the first and 6 at the second. That is two deployment configurations being rolled in and out, one of which almost certainly contains a mistyped character — one finger landing on the 4 instead of the 3.

On Base, the first address holds 102.19 USDC and the second holds 1.32, and neither has ever originated a transaction. That last part proves less than it sounds: x402's exact scheme settles USDC through EIP-3009 transferWithAuthorization, so a receiving address never needs to send anything, and either balance could be swept by a relayed signature without the nonce ever moving. Whether anyone holds the key to the second address is not something I can see from outside.

So the scariest-looking flag in the batch is not a honeypot, not a poisoning attempt, and probably not adversarial at all. My detector's most alarming class fired hardest on what looks like a config typo — and if I had shipped that label, I would have published an accusation of fraud against an operator whose actual problem is a stuck digit.

And one of the false positives was mine alone

The fourth failure was not in the data. It was in my parser.

An x402 listing quotes the same resource on several chains, and each quote carries its own payTo. On the page I sampled, 443 of 1,000 listings advertise more than one distinct payment address at the same time — the proportion drifts between pulls, and it is closer to a third across the first five pages. Almost always that is an EVM address plus a Solana one; three distinct EVM addresses on one listing showed up twice in a thousand. I was storing a single counterparty per endpoint, taken from accepts[0].

So "the endpoint's payTo" was never a well-defined value, and the one I recorded depended on the order the registry happened to return. A listing that reordered its array — changing nothing about who gets paid — would appear in my database as a payment address swap.

Here I have to correct the correction. My first instinct was to say I could not tell how many of the 272 this produced. I can, roughly, and the answer is almost none: every one of the 272 changes is EVM-to-EVM, and a reordering between the two common rails would show up as an EVM-to-Solana flip, of which there are zero. Only three listings in a thousand carry two distinct EVM addresses. It was a latent landmine, not a contributor — and I only found it by reading the code instead of the counts, which is its own lesson.

The fix is boring: pick deterministically instead of positionally.

// A listing quoted on several chains carries several payTo values. Taking
// accepts[0] makes the address we record depend on the order the registry
// returns, so a reordering upstream reads as a payTo change. Pick the lowest
// payTo instead: any deterministic rule removes the artifact.
const quoted = accepts.filter((accept) => accept.payTo);
if (quoted.length <= 1) {
  return quoted[0] ?? accepts[0];
}
return quoted.reduce((lowest, accept) =>
  (accept.payTo ?? "").toLowerCase() < (lowest.payTo ?? "").toLowerCase()
    ? accept
    : lowest,
);

The signal I confused for a swap — and how it was also broken

There is a real dynamic-payTo attack, and it is genuinely catchable before you pay. I had aimed the label at the wrong observation.

The real attack lives inside a single burst of requests. It is when the endpoint hands different addresses to different callers at the same moment — quote address A to your discovery call, then return address B in the payment requirement a second later. You catch it by probing the same endpoint several times in one burst and checking whether it ever offers two addresses for the same rail.

That last qualifier is doing a lot of work, and until this week my code did not implement it. The active probe unioned every payTo across probes with no notion of which chain each quote was for, and read accepts[0] exactly like the snapshot job did — on the only code path allowed to write a reputation label. So a multi-chain endpoint whose accepts came back in a different order across two probes would have promoted a public honeypot label. The bug I was writing a post about was still live in the more dangerous place.

Worse, the check as written could re-flag the very vendors this post exists to exonerate. If an endpoint mints a fresh address often enough, a "burst" loose enough to straddle one rotation sees two addresses and promotes. So the check now requires both qualifiers — same rail, and inside a window tight enough that ordinary rotation cannot explain it:

// The dynamic-payTo attack is two addresses offered in one breath. Honest
// operators that mint a fresh address per payment also show two addresses if
// you watch them long enough — the busiest listings in the Bazaar advertised a
// different address on every pull hours apart, and never repeated one across a
// month of crawling — so the burst has to be tight enough that ordinary
// rotation cannot explain it.
const BURST_WINDOW_MS = 10_000;

A change between two crawl visits is the opposite kind of observation. It needs context that a multi-day cadence does not have, so it must not promote:

// Longitudinal drift: address differs from the prior snapshot of this endpoint.
// At crawl cadence this looks identical whether it is a scheduled key rotation
// by an honest vendor or a rug, so we record it as an observation and never
// write a reputation label from it.
findings.push({
  behavior: "payto_swap",
  detail: isLookalike(from, to)
    ? `payTo changed to a lookalike of the prior address: ${from} -> ${to}`
    : `payTo changed since prior snapshot: ${from} -> ${to}`,
  promote: false, // recorded, never a reputation label
});

I should be clear about what this remedy has proven: nothing yet. There is no cron for the active probe — it runs by hand — and honeypot_observations contains zero intra-burst findings to date. The signal I am elevating as the real one has never fired in production. It is the right shape, not a track record.

What changed

Five changes, all in the direction of claiming less:

Only intra-burst rotation promotes. Snapshot-to-snapshot drift is recorded with promote: false. It stays in the database so I can study it; it never becomes a public label.
Bulk migrations collapse. Three or more endpoints under one host making the identical move become one observation instead of a pile of 109.
Lookalikes are their own class, and survive the collapse. A move to a near-twin of the previous address is tagged even when it is part of a fleet migration — which is exactly where the naive version would have hidden it.
The recorded payTo is chosen deterministically on both the snapshot path and the probe path, so a reordered listing stops looking like a swap.
The intra-burst check is rail-aware and time-bounded, so multi-chain listings and per-payment rotation stop looking like attacks.

Then I deleted the damage: the 57 reputation rows the old logic had written, including the ones covering Browserbase and Tavily, purged from production.

One honest caveat about the guard I put on this. A data-review check counts reputation rows carrying honeypot:payto_swap and expects zero. It does not assert, and it cannot tell a drift-written label from a genuine probe-written one, because the reputation row keeps no provenance. A real intra-burst catch would trip it too. Today it reads zero, which today means nothing has re-polluted it.

Why I am telling you this

Frisk is meant to be the neutral, auditable place an agent checks before it pays. That only means something if I am willing to audit it out loud — including the times it was wrong. A closed reputation API can quietly score Browserbase at zero and nobody outside ever knows.

So here is the work: a plausible-sounding heuristic fired 272 times, scored two legitimate companies at zero for doing something better than the standard, told callers it had actively probed addresses it had never touched, inflated its own evidence 109-to-1, and produced exactly one cluster that looked like a real attack — which turned out to be a typo. Zero of the 272 supported the claim the label made. And the check I had been holding up as the correct one had the same parser bug, on the only path that can write a label.

The lesson is narrow and I think correct: do not promote an observation to a reputation claim unless the observation, by itself, supports the claim. A payTo change seen once every few days does not — whether it looks innocent or looks like poisoning. An endpoint quoting two addresses for the same rail in the same breath does.

The local, deterministic checks from the first post are untouched by all of this — none of it changes what runs on your machine before a payment. What changed is what I am willing to say about someone else's address, and how much evidence I now require before saying it.

Frisk is MIT-licensed and the screening runs locally with no API key: github.com/Jiangw2718i/frisk. If you find a case where it is still wrong, that is the most useful bug report I can get — this post is what happens when someone does.

Five ways an x402 payment can go wrong — and which ones you can catch before your agent pays

Jiangw2718i — Sun, 21 Jun 2026 07:58:03 +0000

x402 turns an HTTP 402 Payment Required into something an autonomous agent can actually act on: the server quotes a price, your agent pays on-chain (typically USDC on Base), the request goes through. No human in the loop. That is the whole point — and also the whole problem.

The moment a program can move money without you watching, "discovery" and "payment" collapse into a single step. Your agent finds an endpoint and pays it in the same breath. If anything about that endpoint is wrong — the address, the price, the destination — the money is already gone by the time you would have noticed.

There is now a small but real body of work on how this gets exploited. Five Attacks on x402 and A402 (both on arXiv), Halborn's writeup, and AgentLISA's position paper each cover a different slice of the problem; taken together they sketch the surface. I read through them while building Frisk, an open-source pre-transaction screening library, and I want to do something specific in this post: walk the documented attacks, and for each one, be honest about whether you can catch it locally, before the payment, in your own code — or whether it fundamentally requires data you don't have on your machine.

That line — local-and-deterministic vs. needs-reputation-data — turns out to be the most useful way to think about agent payment safety. So let's draw it.

The attack surface

Here is my own taxonomy, assembled from those sources plus the V2 spec. Two of the five — the payTo swap and insecure transport — are extrapolated from what V2 makes possible rather than enumerated as attacks in any of the papers:

Dynamic payTo swap. In x402 V2 the destination address can change per request. A seller (or a man-in-the-middle) quotes you address A, then returns address B in the actual payment requirement. Your agent pays B.
Malicious 402 / overcharging. The endpoint quotes an absurd price, or a price that drifts upward across calls, and a naive agent just pays whatever the 402 says.
Insecure transport. The quote — including the address you're about to pay — arrives over plaintext HTTP, where anyone on the path can rewrite it.
Sybil-induced discovery. An attacker floods a discovery surface with fake, high-usage-looking endpoints to steer your agent toward a wallet they control.
Prompt-injection-to-payment. Content the agent reads convinces it to send funds somewhere it shouldn't.

Here's the part nobody says out loud: some of these are checkable with pure local logic, and some are not. Conflating them is why "agent payment security" sounds harder than it is.

What you can catch locally, before the payment

Vectors 1, 2, and 3 are structural. You don't need a reputation graph or a threat feed to catch them — you need a few deterministic checks run against the request the instant before your agent signs it. No network call, and no runtime dependency on my service.

This is exactly the slice Frisk's lite mode handles. It runs entirely on your machine, ships with zero runtime dependencies, and returns a verdict — allow, review, or block — with reasons. Here's the whole thing in use:

import { Client } from "frisk-screen";

const client = new Client(); // lite mode, no API key

const result = await client.screen("0x9a3f1b2c3d4e5f60718293a4b5c6d7e8f9a0bc12", {
  endpoint: "https://api.seller.x402/quote",
  amount: 2.5,
  asset: "USDC",
  observedPayTo: quote.payTo,        // what the endpoint actually told us to pay
  policy: { maxPerCall: 5.0, allowedAssets: ["USDC"] },
});

if (!result.allowed) {
  console.log(result.verdict, result.reasons);
  // "review", ["payTo differs from the expected counterparty"]
  // (trustScore 40 — lite starts at 70 and takes 30 off for the swap;
  //  `block` needs a score under 20, so lite escalates rather than decides)
}

(There's a Python package with the same checks — pip install frisk-screen — but not the same signature: it is synchronous and snake_cased, client.screen(addr, observed_pay_to=..., policy=Policy(max_per_call=5.0)).)

Now map each check back to an attack:

Dynamic payTo swap → catch it. You know the counterparty you intended to pay. You also have the payTo the endpoint actually returned. If they differ, that's the V2 swap attack, and it's a string comparison. V2 makes a per-request payTo legitimate for marketplaces and multi-tenant APIs, so the useful question is not "is this address dynamic" but "did it move away from the address I pinned" — which only works if you have an intended counterparty of your own:

if (request.observedPayTo &&
    request.observedPayTo.toLowerCase() !== counterparty) {
  // the address moved between quote and payment — don't pay
}

This is the single most valuable local check, because the swap is invisible to a human reviewing code — it only happens at runtime, per request.

Overcharging → catch it with policy. You can't know the "fair" price of an arbitrary endpoint without market data, but you absolutely know your own limits. A per-call ceiling and an asset allowlist are deterministic and offline:

if (policy.maxPerCall !== undefined && amount > policy.maxPerCall) { /* review */ }
if (policy.allowedAssets && !policy.allowedAssets.includes(asset)) { /* review */ }

This won't tell you a $2 call should cost $0.05. It will stop your agent from silently paying $400 because a malicious 402 said so. Most overcharging damage is just the absence of a spending limit.

Insecure transport → catch it. If the quote that carries the payment address came over http://, the address is untrustworthy on arrival. Refuse to act on it:

if (endpoint && !endpoint.toLowerCase().startsWith("https://")) { /* downgrade */ }

Plus the obvious hygiene: is the counterparty even a well-formed address? A malformed counterparty is either a bug or a probe, and either way you shouldn't pay it. (Lite also has a seed-blocklist hook — an offline check against known-bad addresses. The list bundled in the published packages is empty today, so this check currently never fires; the live, continuously updated list is the part that belongs to the hosted service.)

That's a handful of deterministic checks, all running before a single token moves, all in code you can read in one file. No service to trust. This is the floor every x402 agent should have, and it's the part I made free and MIT precisely because it shouldn't be behind anyone's API — including mine.

What you cannot catch locally — and where I'll be honest

Vectors 4 and 5 — Sybil discovery and prompt-injection-to-payment — are different in kind. A locally-running function genuinely cannot know that an address belongs to a Sybil cluster, or that an endpoint with a clean-looking history has been quietly draining wallets for a week. That requires reputation data: a graph of who-paid-whom across many agents, accumulated over time. No amount of clever offline code substitutes for it.

And there's a third category the papers above actually spend most of their pages on, which no screening library — lite or hosted — should claim to fix: the protocol- and settlement-layer attacks. Payment replay; the settlement races where a server delivers before payment finalizes (the "paid-but-denied" and "unpaid-service" outcomes the Five Attacks paper centers on); and facilitator trust. Those live in the x402 spec, the facilitator, and the on-chain settlement path — not in the request your agent is about to sign. Frisk screens the counterparty and the shape of the transaction; it does not, and cannot, repair the protocol underneath it. So this post is deliberately scoped to the vectors a pre-payment check can actually touch — pretending a screening call closes a replay or atomicity hole would be the other half of how agent-payment security gets oversold.

So lite mode is upfront about this: it always reports "low" confidence and it does not claim to detect Sybil attacks. Pretending a local check can catch a reputation problem is how you ship false confidence, which is worse than no check at all.

This is the line between the open-source library and the hosted service — and I'd rather state it plainly than blur it for a pitch. The hosted side of Frisk is where reputation history and threat intelligence would live, and it is early; the part I'm comfortable telling every x402 developer to install today is the deterministic floor above. If you're shipping an agent that pays, start there. The five checks cost you nothing and close the attacks that are actually closeable in your own process.

Takeaways

Agent payment safety isn't one problem. It's three: structural checks you can do before paying, reputation you have to source from data, and protocol/settlement holes that sit below any screening call. Solve them separately — and don't let a tool for one pretend to cover the others.
The deterministic floor — payTo-swap detection, spending policy, transport and address sanity — covers three of the five failure modes in my own list above — none of which are the protocol- and settlement-layer attacks Five Attacks enumerates — with no network call and no runtime dependency on my service. Ship it.
Be skeptical of anything claiming to detect Sybil/reputation attacks with purely local logic. That category needs data, and honesty about the boundary is the whole game.

Frisk is MIT and the lite engine is dependency-free: npm i frisk-screen / pip install frisk-screen. The source and the (short, readable) check logic are on GitHub. If you're building on x402 and you catch a vector I missed, open an issue — that's exactly the kind of thing this should accrete.

The reputation-backed hosted tier is in early access. If that's the part you need, email support@tryfrisk.dev — but the deterministic floor above is free, MIT, and yours to ship today regardless.

Sources referenced: "Five Attacks on x402" and "A402" (arXiv); Halborn's x402 security writeup; AgentLISA x402 security position paper.