Sapiom just raised $15M for a missing part of the agent stack: spending money safely

AI agents can call tools, chain prompts, hit APIs, read docs, schedule jobs, and write code. Then they hit a very ordinary constraint: paying for things.

That’s the gap Sapiom wants to fill. The startup has raised a $15 million seed round led by Accel, with participation from Okta Ventures, Gradient Ventures, Array Ventures, Menlo Ventures, Anthropic, and Coinbase Ventures. Founder Ilan Zerbib previously led payments engineering work at Shopify, which is about the right background for this problem.

Sapiom’s pitch is straightforward: give AI agents a secure way to buy access to APIs, data, software, and compute on behalf of a company, under policy controls, with auditable payment flows.

It sounds narrow. It isn’t, once you look at where agent systems break in production.

Agents can use tools. Procuring them is another matter

Most agent demos quietly skip the hard part. The API key already exists. The billing account is already approved. The cloud credentials are already provisioned. Somebody already signed off on pricing and legal terms.

That’s not how real companies operate.

If an agent decides it needs Twilio to send messages, a paid dataset to enrich leads, a GPU burst on AWS, or a premium API to verify identity, three questions show up immediately:

1. Who is this agent acting for?
2. Is it allowed to buy this thing?
3. How do you pay without handing it a corporate card or a root API key?

Most teams paper over that with bad workarounds: shared secrets, long-lived credentials, human pre-provisioning, budget controls that sit outside the runtime, manual reviews. You can get away with it for one internal workflow. It gets messy fast when agents are more autonomous and there are more of them.

Sapiom is going after that bottleneck. If it works, it becomes a distinct layer in the stack: delegated spend infrastructure for software agents.

That’s a real category. It’s also a nasty one to build.

The problem runs deeper than “payments for bots”

Accel’s line, “every API call is a payment,” is a little glib. Still, it points at the architecture problem.

A lot of modern software usage already behaves like micropayments, whether anyone uses that label or not. You invoke a model endpoint, send an SMS, run a serverless job, fetch a record from a commercial dataset, or execute a premium search request. Each action costs something. Sometimes pennies, sometimes variable, always cumulative.

Humans put up with rough edges in that system. Agents won’t. If the spend path isn’t programmable, low-latency, and revocable, the workflow breaks.

A usable system here needs five pieces working together.

Identity and delegated authority

An agent needs scoped permission to act for a workspace, project, or user. Not broad account ownership. Not raw secrets sitting in environment variables.

That usually means some mix of:

• OAuth2 delegated access
• short-lived JWT bearer tokens
• on-behalf-of flows
• enterprise identity bindings through OIDC or SAML

If Sapiom wants enterprise adoption, it also needs a clean runtime identity story. Which agent instance made the call? Under which policy version? Inside which tenant boundary? That’s where hardware-backed attestations, WebAuthn, or at least strong workload identity start to matter.

Without that, “the agent bought this” turns into a compliance problem very quickly.

Machine-readable pricing and entitlements

Agents can’t buy intelligently if pricing lives in a PDF or an admin dashboard.

A real spend layer needs a service catalog with structured entries: product, SKU, region, price unit, usage limits, maybe contractual terms. Something like “Twilio SMS, US/CA only, $0.0079 per message, 1,000/day cap” is the minimum useful unit.

That has wider consequences. If this category grows up, API providers will need to publish pricing and entitlements in a format software can reason about. Today, most API billing is built for humans reading docs, not agents making choices in real time.

Payment orchestration without wrecking latency

This is where the idea gets interesting, and where a lot of startups would get crushed by basic physics and economics.

Agents often run in tight loops. If every tool call waits on a slow authorization decision or a card-network hop, the workflow becomes unusable. Policy checks and spend approvals need to happen in tens of milliseconds, not seconds.

So Sapiom probably won’t process every API request as a full standalone payment on a traditional rail. More likely, it maintains an internal ledger, pre-authorizes budgets, batches settlement, and exposes per-call accountability at the software layer rather than the card-network layer.

That makes sense. Otherwise the fee structure would kill it.

The likely funding options are the usual ones: virtual cards, ACH, invoice settlement, perhaps credit. Coinbase Ventures’ involvement naturally prompts stablecoin speculation, and that may end up on the roadmap, but there’s no public evidence that crypto rails are central to the product right now. That’s probably for the best. Enterprise buyers don’t need extra novelty here.

Policy control that works at runtime

A serious deployment needs policy-as-code, not just a monthly budget slider in a dashboard.

The useful rules are specific:

• This agent can call twilio.messages.create but only for US numbers
• This project can spend up to $150/day
• Any single session over $50 requires human approval
• PII-related calls must stay in the EU
• Expensive model inference is allowed for production incidents, blocked for routine QA

This is the part developers and platform teams should care about most. Once budgets and vendor restrictions become runtime inputs, cost control moves closer to the planner itself. Your agent loop starts to look more like:

plan -> quote -> authorize -> execute -> reconcile

That’s better discipline. It also adds friction. An agent that feels fast in a demo can feel a lot slower once every expensive action goes through a policy broker.

Reconciliation, where a lot of good ideas fall apart

Approving a spend token is one problem. Making your ledger match what the vendor says happened is another.

Usage-based billing is messy. Retries happen. Partial failures happen. An API times out after processing the request. A cloud job starts but doesn’t finish. Metering units differ across vendors. Refund logic is inconsistent. Chargebacks exist.

If Sapiom can’t reliably reconcile vendor usage with internal records, it becomes another source of finance pain instead of a fix. That back-office piece matters just as much as the shiny “agents can buy tools” pitch.

The security risks are obvious, and real

Giving agents spending power sounds risky because in a lot of deployments, it is.

A runaway agent can burn real money very quickly. Worse, it can send sensitive data to third-party services while doing it. The guardrails aren’t optional. They are the product.

A credible platform needs:

• HSM or MPC-backed custody for payment instruments
• PCI scope isolation if card rails are involved
• strict tenant isolation and RBAC
• rate limits and circuit breakers
• vendor allowlists
• immutable audit logs tied to idempotency_key, agent identity, and vendor response metadata

There’s also a subtler problem: spend approval becomes a high-value attack surface. If an attacker can mint or replay purchase tokens, they don’t need to steal cloud credentials. They can just direct your agents to buy and run things through approved channels.

So token design, revocation, and replay protection matter a lot. So does graceful failure. If the budget service is down, do calls fail closed? Do they degrade to pre-approved limits? Both choices have operational costs.

Why this matters beyond one startup

Sapiom’s pitch looks niche until you see how much of the market it touches.

Procurement starts to look like infrastructure

Enterprise procurement has always been a human workflow wrapped around spreadsheets, approvals, and vendor systems. Agents put pressure on that model because the buying decision moves into the execution path.

If that sticks, procurement stops being purely administrative and starts to look a bit like auth, policy, and CI/CD. Teams won’t just ask whether a vendor is approved. They’ll encode the exact conditions under which software can buy from that vendor.

That’s a bigger shift than the usual “payments for AI” framing suggests.

API providers may need cleaner commercial interfaces

Today’s API ecosystems are good at auth and metering, mediocre at programmable commercial terms. If agent-driven buying becomes normal, providers will need machine-readable catalogs, quota semantics, entitlements, refund behavior, and delegated billing hooks.

That could also create pressure on companies like Rapid, Kong, and Apigee. API gateways handle routing, auth, and analytics well enough. They don’t generally act as spend brokers with real-time budget enforcement.

That gap is real.

Agent frameworks will probably absorb budget semantics

If Anthropic is backing the company, it’s easy to imagine future agent stacks exposing native concepts like budget, quote, purchase_token, and approval_required alongside tools and memory.

That would be healthy. Right now, many agent frameworks treat cost as observability after the fact. For production systems, that’s too late.

What technical teams should take from this now

You don’t need Sapiom specifically to take the lesson.

If you’re building agents that touch paid services, treat spending as a first-class runtime resource. Add pre-execution checks. Use revocable short-lived credentials. Put spend rules in versioned policy. Require idempotency_key on paid operations. Design fallback paths for authorization failures.

And be honest about how much autonomy you actually want.

A lot of teams say they want autonomous agents. What they usually want is faster automation inside narrow, auditable constraints. That’s sensible. It also means the infrastructure that wins here probably won’t feel magical. It’ll be the plumbing that lets agents act with limited authority, under familiar enterprise controls, at production latency.

That’s the lane Sapiom is trying to claim. The idea is sharp. The hard part is building it.