DEV Community

Rumblingb
Rumblingb

Posted on

Your AI Agent Can't Pay For Anything — Here's the Missing Layer

#agentpay #aiagents #payments #buildinpublic

Every AI agent today can browse, code, and email. None of them can actually pay for anything without a human co-signing.

Here's the exact gap:

Agent → Stripe API → Which agent? Which task? Which budget?
Enter fullscreen mode Exit fullscreen mode

The payment rails see an API key. They don't see agent identity. So you can't enforce per-agent budgets, audit spend, or revoke a rogue agent without revoking the human's credentials too.

This is being solved right now:

  • Kontext CLI: credential broker for coding agents (70 HN points)
  • Pomerium: zero-trust gateway extended for agents
  • AgentMail (YC S25): email addresses as agent identity primitives
  • Grantex: IETF draft for agent authorization without human consent flows

But the product layer is missing. AgentPay is building the payment control plane — MCP + Stripe + per-agent budgets + audit trails.

61 MCP servers. 61 npm packages. The tools are free. The middleware is where the value lives.

Try it: agentpay.so

AgentPay #AIAgents #Payments #BuildInPublic #MCP

Top comments (1)

Collapse
 
johnfrandsen profile image
John Frandsen •

The core insight here — that payment rails see an API key, not an agent identity — is spot on. But there's an existing regulatory framework that partially solves the "who authorized this payment?" problem, at least in Europe: PSD2 Payment Initiation Services (PIS).

Under PIS, a payment is initiated via an open banking API call to the user's bank, and the bank enforces Strong Customer Authentication (SCA) as part of the flow. The authentication is tied to the payment itself (amount, recipient, timestamp), not to a stored credential. So in theory:

  • The agent initiates the payment intent via a PIS API.
  • The bank sends an SCA challenge (biometric, OTP) to the human account holder.
  • The human approves the specific amount and payee.
  • The payment settles directly from the bank account, no card network involved.

The agent never holds a reusable credential. The authorization is per-transaction and cryptographically bound to the payment details. That's the "per-agent budget + audit trail" problem solved at the protocol level — the bank record IS the audit trail.

The catch: this is EU/UK only, it requires merchant-side PIS acceptance (still niche outside specific verticals like invoicing and e-commerce checkout), and SCA adds latency that doesn't fit high-frequency micro-transactions. The IETF draft and MCP-based approaches you mention are better fits for the "agent swarms making 1000 API calls" use case. But for higher-value, lower-frequency agent-initiated payments where human-in-the-loop authorization is actually desirable, PIS is worth knowing about as an existing rail rather than building from scratch.

Interesting overlap between the agent-identity work (Grantex, AgentMail) and the open banking PIS model — both are trying to separate "who is this entity" from "can they spend money."