When Your Agent Pays Another Agent, Who Checks the Seller?
AIR raised $50M to vet the skills and MCP servers agents use. Our index shows 15.8% of paid endpoints have more than one buyer. The commerce layer exists; the vetting layer does not.
· 558 words
Agents are spending real money on third-party services. Of 27,858 listed paid endpoints in our index (measured from Coinbase transaction telemetry we ingest, not our own probe), 4,405 have more than one distinct paying buyer in the last 30 days. That is 15.8%. The rest have one payer or none, and in most cases that single payer is the endpoint's own operator. The median call costs $0.01. At that price, skipping the question of who vetted the supplier feels cheap. It is the mistake that the next major agent security breach will have started from.
AIR, an AI security startup founded by Israeli military intelligence veterans, came out of stealth Tuesday with $50 million raised across two rounds led by Sequoia and Greenoaks. Its core product is a continuous vetting layer for the skills, plug-ins, and MCP servers that agents use when they reach across the internet. The company catalogs add-ons available on the open web and filters out 27% of them as malicious or risky. It re-checks them continuously, because a skill that passed last week may fail today if the developer's account was compromised or an underlying package changed.
The founding analogy is worth holding. Two decades ago, any code could load into an OS kernel as a driver without a signature. Today every driver is signed; unsigned ones are blocked. Agent tools, including the paid endpoints that now form a real commercial market, are at the unsigned-driver stage. Nothing checks that the endpoint your agent is about to call is the same one it called yesterday, or that what it returns has not been altered.
The attack surface is specific to commerce. A paid endpoint call reaches further than a data request. The response it receives can load behavior into the calling agent. Prompt injection through an API response is well documented. Sequoia partner Bogomil Balkansky described AIR's problem as "an infrastructure problem long before it is a security problem," and that framing holds. The verification gap closes after a breach, not before.
Three things builders with money-authorized agents should do now, before this becomes a post-incident checklist.
Keep a whitelist of which agents can call which endpoints. If an agent can authorize payments, restrict it to endpoints a human explicitly approved. The pattern AIR sees most often is an agent granted broad API access because scoping it felt like a second sprint, then forgotten while its reach expands into systems nobody intended.
Track external endpoints like software dependencies. Log what each one returns on every call. Behavior can change without a version bump and without any notification from the endpoint's operator. That log is how you detect the change before it becomes an incident.
Use corroboration as a proxy while better signals take shape. A service listed in two or more independent registries is categorically more likely to be a real, stable operator than one appearing only once with no description. Staying reachable matters too. A service that does not answer a live handshake is invisible to automated routing regardless of how well it is listed.
The 4,405 endpoints with genuine multi-buyer activity are a real market. The commerce layer exists. The vetting layer is what has not been built at scale yet, and AIR's $50 million is the first large bet that enterprises will pay to fix that before they are forced to.
Sources
[object Object]