Before Your Agent Pays, Someone Needs to Re-Verify the Seller

The approval your agent gave an MCP endpoint last month covers that endpoint as it was, not as it is today. Zenity raised $125 million in a Series C round in August. AIR came out of stealth in September with $50 million across two seed rounds led by Sequoia and Greenoaks. Both companies pitch the same core idea: vetting the tools agents use is not a one-time scan. It is a continuous re-verification problem.

AIR's CEO Yair Saban puts it in terms of driver signing. Before code signing became mandatory, loading an unsigned driver was routine. Unsigned drivers are now unthinkable because the signature is a kernel-level trust decision made with evidence rather than without it. Agents loading MCP servers face the same structure, with one critical difference: agents are not just users making trust decisions. They are buyers making payments. The blast radius of a compromised endpoint scales with how much the agent delegates to it.

AIR found that 27% of add-ons and skills it reviews online fail its vetting criteria. That figure covers skills at the moment of first review. It says nothing about what happens when a previously approved add-on's package is updated, or when its developer's account is compromised after you added it to your agent's toolset. Sequoia partner Bogomil Balkansky described the scope: "Inspecting every skill, plugin, MCP server and sub-agent an enterprise's agents touch, re-inspecting each one every time it changes, in real time and across an entire company's agent fleet, is an infrastructure problem long before it is a security problem."

For a paying agent, that infrastructure problem is also a financial control problem. Discovery tells you what is connected. Re-verification tells you whether what is connected is still what you approved. A call that costs pennies under the approved endpoint can behave differently under a modified one while billing the same amount.