Stripe Sessions is a great event. The density of people genuinely thinking about agent-to-API payments is unmatched. Practitioners, builders, infrastructure folks, and payments leaders are all in the room together, and the on-stage discourse has moved a long way in twelve months. The room has clearly internalized that agents are economic actors, not just clients of an API.
So this isn’t a critique. It’s a set of notes from sitting in those conversations and asking what the agenda looks like a year from now. Five themes stood out as undercovered today and likely to dominate next time. They’re the gaps OnDB is built around, so I’m biased. But they’re also the gaps a security and data person walks in and sees immediately.
1. The supply-side of the agentic economy
Most of the agentic-commerce conversation treats the agent as a buyer: checkout flows, BNPL for agents, agent-to-agent purchases, fraud on the buy side. That’s the natural starting point because it’s a clean analog of human e-commerce.
The harder half is the supply-side. Who provides the data and tools the agent calls, how do they get paid for it, and on what basis does the agent trust them? Agents in production today are pulling code, context, and tool responses from wherever they can reach, with no coherent answer to who they trust or who gets paid for what they consume. That feeds straight into the over-permissioning problem in section 4: the more chaotic the supply, the more the consuming agent compensates by trusting indiscriminately and being granted broader access than it should have.
This is the single biggest hole in the conversation right now. The rails for the supply-side already exist. x402 and Stripe’s Machine Payments Protocol are both shipping. The businesses that should sit on top of them aren’t being talked about as a category yet, but they will be soon.
2. Pay-per-call as a first-class data business model
The thesis is in the air everywhere. Models are commoditizing, proprietary data is the moat. But it rarely gets put on a slide next to Stripe owns the rail. Connecting those two is what turns pay-per-call data businesses from a thesis into a category.
The reason it matters is that pay-per-call is a different unit of sale than the SaaS world is built around. SaaS sells seats and tiers. Marketplaces sell subscriptions. Pay-per-call is per-query, denominated in fractions of a cent, settled in milliseconds, with no user to log in. That’s not a pricing tweak. It’s a different shape of business, and the tooling to support it is what we’re building.
If you’re a data provider thinking about how to expose your dataset to agents without giving the whole thing away, the existing playbooks aren’t going to help you. New ones are being written this year.
3. Multi-party settlement for composite calls
Stripe Connect is excellent at marketplaces with one buyer, one seller, and a platform taking a cut. The agentic-data shape is different. One query fans out to three or four providers and all of them need to be paid in the same transaction, with rev-split happening server-side without manual reconciliation.
This is what we mean by cross-provider joins with revenue splitting. It’s a real settlement primitive, not a billing afterthought. The pattern doesn’t show up in volume yet, which is why it isn’t a major topic. But we’re seeing it in our early traffic, and the moment one composite query touches a dozen sources, manual rev-share spreadsheets stop scaling.
4. Threats to agents, not threats from fraud
This is the gap I find most undercovered, and I’ll be upfront about the bias. I’ve spent most of my career in cybersecurity and investigating incidents. So when I look at the way risk and fraud get discussed, I see an industry that handles human-buyer adversaries beautifully. Card-testing, chargebacks, AML, and dispute management are all well covered. What’s barely being engaged with is the attack surface created by handing agents credentials, capabilities, and budgets.
The most acute problem is also the most basic: agents today routinely run with far more permission than they need. A single agent token typically grants access to everything the user can see, with no segmentation between tasks, no scoping by data sensitivity, and no separation between read and write. We knew how to do better than this for human IAM fifteen years ago.
Rethinking permissions for agents is going to be necessary. The agentic stack, as currently deployed, is a security regression, and the longer the industry waits to address it, the more painful that retrofit will be.
There are early signals of this thinking starting to land at the payment layer. Stripe’s Issuing for Agents gives cards as a budget, clock, and scope primitive, and the expanded Radar surfaces (free-trial abuse, multi-account abuse, pay-as-you-go abuse) push fraud detection toward agentic abuse patterns. That’s real progress, but it’s payment progress. The harder problem sits one layer up: scoped credentials and segmented capabilities for the data and tools an agent reaches for, not just for the money it spends.
The attack surface that follows from this:
- Over-permissioned agents. Most agent deployments today violate basic security-by-design principles. Least privilege, segmentation between capabilities, and scoped credentials per task are the baseline once an agent is allowed to spend money or touch sensitive data, not optional patterns. Permissions also need to extend into the economic layer: per-agent spending budgets, time-bounded permissions and budgets that expire on a clock rather than waiting for revocation, and explicit scoping on the actions an agent can take rather than blanket access to a capability surface.
- Trusted data for context enrichment. Retrieval and tool calls are not convenience features. They shape what the agent decides. If the data flowing into context can’t be trusted to be authentic, fresh, and unmanipulated, the entire downstream decision chain inherits that doubt. Provenance and integrity at the source are the product, not a feature, and they are why high-quality data access matters more than raw availability.
- Agent abuse and quota exhaustion. A misbehaving agent doesn’t look like a botnet. It looks like a paying customer. Rate-limiting becomes a billing problem before it becomes a security problem.
- Identity and delegation chains. Who is the agent acting on behalf of, with what scope, for how long, and how is that bound to its credentials? Every other gap on this list depends on solving it well.
Risk and fraud, as the industry currently uses those words, is mostly a transactional vocabulary. The agentic stack needs an integrity and access-control vocabulary too: was the data real, was the source authentic, did this agent have the right to fetch it, did the right party get paid. That’s the conversation OnDB is leaning into, and where we expect a lot of our category to be defined.
If you’re building security data products and you’ve watched the threat-intel market chew on subscription-based licensing for a decade, this is where MPP actually changes the unit of sale.
5. The agent perimeter
The perimeter is where bot-vs-agent classification has to happen, and where the cleanest answer to “what do we do about non-human traffic” stops being block it and starts being charge it.
The shift from blocking to monetizing is one of the most interesting downstream consequences of MPP. It changes the economics of operating any public-facing API. Traffic that used to cost you money now generates revenue, but only if you can tell the difference between an agent willing to pay and a scraper that won’t. That’s a perimeter problem, an identity problem, and a payments problem stacked on top of each other. Nobody owns it cleanly today.
You can see the gap in what already exists in its place. A growing category of startups now sells webpage-to-markdown APIs and similar scrape-and-reformat services as “agent data infrastructure.” That’s public data, restructured for context windows. It’s a workaround, and it barely scratches what agents actually need for context enrichment. The reason it exists at all is that the perimeter doesn’t know how to monetize an agent yet, so the supply chain has defaulted to scraping the public internet. Once that changes, providers can serve agents directly, paid per call, with the proprietary data that was never going to show up on the public web in the first place.
I’d expect this to be one of the more contested conversations at next year’s events. This year, it’s open territory.
Where OnDB fits
OnDB is shipping directly into these gaps. Per-query metering on Stripe MPP and x402, multi-provider joins with automatic rev-split, data that never leaves the provider’s infrastructure, and a threat model that takes integrity and provenance as seriously as availability. We come at the problem from a security and data background, not a payments background, which is why these gaps were the first thing we noticed.
OnDB is invite-only. We review applications manually and respond within 48 hours.
Want to talk first? Reach me directly at m@ondb.ai or DM @msuiche / @ondbai.
Matt
