Stripe and Tempo shipped the Machine Payments Protocol on March 18. Within 24 hours, 100+ services were compatible. Visa extended it to credit and debit cards. Lightspark added Bitcoin Lightning. Agents can now request a resource, receive an HTTP 402 with payment details, authorize spending, and stream micropayments — all without a human touching a checkout page.
The payment rails problem is solved. The authorization proof problem hasn't been touched.
What MPP Actually Does
MPP introduces a sessions primitive: an agent authorizes a spending limit upfront, then streams payments continuously under that cap. The flow is clean — agent requests resource, service responds with 402, agent pays, resource delivered. For Stripe users, payments appear in standard dashboards with fraud protection, tax calculation, and accounting integrations built in.
This is a genuine breakthrough. Before MPP, agents had to navigate account creation forms, pricing pages, and manual payment entry — interfaces designed for humans. Now payment is a protocol-level operation: machine-to-machine, no UI required.
Browserbase charges agents per headless browser session. PostalForm lets agents pay to print and mail physical letters. Prospect Butcher Co. (yes, really) lets agents order sandwiches for human pickup in New York. The use cases are already concrete.
The Invisible Problem
MPP handles payment execution. It tells you that a payment happened, how much was charged, and which service received it. Stripe's infrastructure tracks the financial flow with the same reliability it provides to millions of merchants.
What it doesn't capture:
- Which agent version initiated the payment
- What prompt or instruction was active when the spending decision was made
- Who authorized the agent to spend on this category of service
- What decision chain led to the payment (did the agent evaluate alternatives? was it a first attempt or a retry after failure?)
- Whether the spending limit was set by a human with appropriate authority, or inherited from a default configuration nobody reviewed
These aren't edge cases. They're the first questions an auditor asks.
When a human employee expenses a $200 dinner, the company doesn't just verify the credit card worked. They verify who approved the expense category, whether the amount was within policy, and whether the employee had authority to spend on that vendor. The payment rail (Visa, Mastercard) is the least interesting part.
What Regulators Will Ask
Three regulatory frameworks intersect with autonomous agent payments, and none of them care about payment rails:
PSD2 (Payment Services Directive 2): Strong Customer Authentication requires that payment initiation be traceable to an authenticated actor. When an agent initiates payment on behalf of a company, PSD2's chain of authentication doesn't terminate at "the agent had API keys." It asks: who delegated payment authority to this agent? Can you prove it? The answer can't be "check the system prompt."
AML/KYC (Anti-Money Laundering): Transaction monitoring rules require understanding the intent behind payments, not just the amounts. An agent streaming micropayments to 50 services per hour looks indistinguishable from structuring unless you can prove the business logic behind each payment decision. "The agent was configured to optimize cost" is not a compliance answer.
EU AI Act (effective August 2026): Article 14 mandates human oversight proportional to risk. Article 9 requires risk management including continuous monitoring. An agent autonomously spending company money is a high-risk decision. The Act doesn't ask "did the payment clear?" It asks: "what human oversight mechanism was in place when the agent decided to spend?"
The common thread: regulators don't audit payment rails. They audit authorization chains.
"The agent did it" is not a compliance answer for any of these frameworks.
The Missing Layer
The gap between "agent can pay" and "agent payment is compliant" is an authorization proof layer — a mechanism that captures the decision context before the payment executes, not after.
What this looks like concretely:
{
"action": "mpp_payment",
"agent_id": "support-agent-v2.3.1",
"agent_hash": "sha256:9f86d081884c...",
"prompt_hash": "sha256:a3c2f8e71b...",
"decision_context": {
"trigger": "customer_request_browser_session",
"alternatives_evaluated": 2,
"selected_service": "browserbase",
"amount_usd": 0.12,
"spending_budget_remaining": 48.88
},
"authorization_chain": {
"delegated_by": "ops-team@company.com",
"policy_id": "agent-spend-policy-v3",
"max_per_transaction": 50.00,
"category_authorized": ["developer_tools", "compute"]
},
"timestamp": "2026-03-19T14:23:01Z",
"certification_hash": "sha256:7c3b2a..."
}
This record is created before the payment hits Stripe. It's cryptographically signed. It captures the full decision chain: who delegated authority, what policy governed the decision, which agent version ran, what prompt was active, and what alternatives were considered.
The payment itself is just the last step in an authorization chain that starts with a human policy decision. MPP handles the last step. The rest needs its own protocol.
Why Payment Rails Don't Solve This
Stripe's infrastructure already provides fraud detection, dispute handling, and transaction logging. These are critical, but they operate at the wrong layer.
Fraud detection asks: "Is this transaction pattern suspicious?" Authorization proof asks: "Was this transaction properly authorized before it happened?"
Transaction logs tell you: "Agent X paid $0.12 to Browserbase at 14:23 UTC." Authorization proof tells you: "Agent X version 2.3.1, running prompt hash a3c2f8e, was authorized by ops-team under policy v3 to spend up to $50 on developer tools, evaluated 2 alternatives, and selected Browserbase at $0.12."
The first is a receipt. The second is an audit trail. Regulators want both.
The Scaling Problem
One agent making one payment is manageable. The compliance question gets hard at scale.
MPP is designed for high-frequency micropayments — agents streaming continuous payments to multiple services. At 100 agents making 50 payments per hour, you have 5,000 payment decisions per hour that each need:
- Proof of authorization delegation
- Proof of policy compliance
- Proof of agent identity (version, configuration)
- Proof of decision rationale
Without a structured authorization layer, you're left retroactively reconstructing decision chains from logs scattered across multiple systems. That's forensics, not compliance. Compliance requires the proof to exist before the action, not assembled after an incident.
What Comes Next
MPP is the right foundation. Agents needed a payment protocol, and now they have one. The next layer — authorization proof — is what makes agent payments enterprise-ready and regulator-ready.
The pattern is familiar from other infrastructure transitions. HTTPS solved transport encryption; it didn't solve identity (that took certificate authorities). OAuth solved delegated access; it didn't solve consent tracking (that took additional compliance layers). MPP solves payment execution; authorization proof solves payment governance.
Every agent that spends money will eventually need to answer: who authorized this, under what policy, with what constraints? The earlier that proof is built into the payment flow, the less painful the compliance retrofit will be when regulators inevitably ask.
ArkForge builds cryptographic authorization proof for AI agent actions — including payments. Every decision is certified before execution, creating tamper-evident audit trails that satisfy PSD2, AML, and EU AI Act requirements. arkforge.tech
Top comments (0)