{"slug": "agentic-payments-move-spending-authority-into-the-runtime-focused-labs", "title": "Agentic Payments Move Spending Authority Into the Runtime | Focused Labs", "summary": "Focused Labs has identified that agentic payments require a new architectural pattern where spending authority is delegated to the runtime rather than the AI agent itself. The company argues that agents should create \"payment intents\" containing actor, task, merchant, amount, and purpose, while a runtime policy engine determines approval, rejection, or escalation to human oversight. This approach addresses the core challenge of AI agents needing to spend money autonomously while maintaining audit trails, budget controls, and liability protection that static allowlists or direct wallet access cannot provide.", "body_md": "Agentic payments are arriving before payment authority has an owner.\n\nAt LangChain Interrupt there was a constant return to a payment question for agentic AI: what to do with AI agents that need to spend money. [Privy said the payment question kept coming up](https://x.com/privy_io/status/2057490730558587366). Harrison Chase [pointed at centralized least privilege, audit trails, and dynamic policies](https://x.com/hwchase17/status/2057524656631083124) as the path that probably beats static allowlists.\n\nThe wallet signs. The runtime decides.\n\nSo let me just repeat that. The payment question that’s come up for agentic commerce, AI agents making payments, is delegated spend. And spending money, even as a new tool call, is not simply another tool call. It creates liabilities, dispute paths, budget pressure, user trust issues, procurement weirdness, and an audit trail the business needs to defend after the fact.\n\nIn this integrated form, agents can research suppliers, compare offers, reserve resources, pay for APIs or other digital goods and services, issue refunds to customers, or book travel inside systems where humans already work. Thus, as previously noted, [the integrated agent](https://focused.io/lab/2026-year-of-the-integrated-agent) is far more powerful than AI-powered chat.\n\nMoney exposes the part of the architecture that hand-wavy autonomy hides.\n\nNote that as soon as the agent stops being able to execute commands in the integrated workflow and instead fills out a human controlled checkout page (e.g. for purchases), then the workflow stops being integrated and turns into purely manual work. And as for spending money on behalf of a user with direct wallet access granted to the agent, the worst part is that the UI will make it look like the money was intentionally spent by the user (with a cool progress bar, for example), until it is revealed weeks later by the finance department that a prompt was entered incorrectly and money was spent by the AI agent.\n\nProtocols are moving quickly. x402 [frames itself as an open payment standard for internet-native payments](https://www.x402.org/). Coinbase describes x402 as [direct programmatic payments over HTTP](https://docs.cdp.coinbase.com/x402/welcome) for human developers and AI agents, with no account setup and no manual payment flow. Cloudflare’s Agents documentation shows the machine-to-machine flow: [client requests a paid resource, receives a 402 Payment Required response, retries with a signed payment payload, and gets settlement confirmation](https://developers.cloudflare.com/agents/agentic-payments/x402/).\n\nGood. Interfaces for agents need to be [agent-operable interfaces](https://focused.io/lab/mcp-is-packaging-agent-operable-interfaces-are-the-product), including payment interfaces. That’s why human checkout pages are so bad for autonomous work.\n\nIn sum, the hard work in enabling a resource to be paid for over the internet is left to the runtime (i.e. spending policy): what agent requested this spend, what was the purpose of the agent, what is the relevant budget, what merchants/services are in scope, who can retract a delegation of spend, who is the human to approve a spend, where will the settlement receipt of the spend of money be written.\n\nThe core object is payment intent.\n\nAn agent shouldn’t be passing around payment authority, the agent should create a payment intent. The intent would include actor, task, merchant/service, amount, currency, purpose, budget, requested payment method, evidence gathered, and fallbacks for when the main method of payment fails. The runtime policy engine then determines the next steps for the payment intent based on its rules (approve the payment of metered API calls automatically, pay customer refunds to support leads, require approval from procurement for new vendors, reject transactions that were not for the intended task, etc). Those next steps could be yes, no, ask for human approval, or open a ticket.\n\nWallet should be behind the runtime policy not inside the agent loop.\n\nThis sounds boring because money likes boring.\n\nThe runtime spending policy needs a few plain fields:\n\nThis can be contrasted with the runtime spending policy that is required to be defined by the agent in Privy's x402 writeup here [Privy's x402 writeup gets close to this shape](https://privy.dev/blog/building-agentic-and-programmatic-payments-with-x402-and-privy) for per-domain spend limits, agent-specific permissions, workflow-level approvals, and even for session signers for offline user workflows.\n\nWallet architecture still matters. It just answers a much narrower question.\n\n[Privy's agentic wallet docs describe two control models](https://docs.privy.io/recipes/agent-integrations/agentic-wallets): developer-owned wallets controlled by backend authorization keys, and user-owned wallets that grant an agent signer scoped policies while the user keeps ultimate control and revocation.\n\nA developer-owned wallet for a backend agent paying for infrastructure, such as data enrichment, paid APIs, crawl credits, model calls, or transaction fees. The company owns the budget, the runtime owns the policy, and operational control of the revocation is sufficient (i.e. someone on the team can log into the management interface and cancel an agent).\n\nUser-owned wallets with agent signers also fit into the delegated action model. In these cases, users are delegating others to perform action(s) on their behalf. In these cases, users fund their own workflows, and the agent or signer is granted bounded authority to complete tasks on their behalf. (In these cases, the user should always have the ability to revoke the agent or signer).\n\nThe control model decides who owns funds, who can revoke access, and where policy gets enforced.\n\nBoth models need runtime policy. A developer-owned wallet with no spend controls turns into a company credit card taped to an agent’s back. A user-owned wallet with no scoped delegation turns into a consent problem just waiting to turn into a customer dispute.\n\nApproval is a runtime state transition. The modal is just where a human sees it.\n\nThat is why [agent UI belongs in runtime infrastructure](https://focused.io/lab/agent-ui-is-runtime-infrastructure). So when a user approves a spending action, they are approving a proposed transaction with a matched policy. The evidence the agent used, the budget impact, and the scope of authority being granted should all be visible to the user approving the spending. The user should be approving a bounded payment intent, not a vague agent plan.\n\nThat is the part that everyone tries to treat like an SDK integration and therefore payments “work”.\n\nA payment-capable agent needs a way to have those payments recorded as receipts as first-class data within the agent’s runtime.\n\nWhen making payments, the payment response should be written back as evidence to the same stream as the rest of the work done by the agent. Cloudflare’s x402 flow ends with [a PAYMENT-RESPONSE header that contains settlement confirmation](https://developers.cloudflare.com/agents/agentic-payments/x402/).\n\nThat was also true for tool calls: [agent traces need to cross the boundary](https://focused.io/lab/agent-traces-need-to-cross-the-mcp-boundary) of work, the side effect of which is that the trace becomes much more valuable. In the case of payments, the side effect is value transfer (i.e. money moving out of or into an account). Therefore, for all but the cheapest of actions, traces of agent work must include payment receipts.\n\nThe ledger doesn’t have to be pretty or shiny. It has to answer the boring set of questions of work done quickly.\n\nWe should pay attention to how existing payment networks already frame the problem. For example, while [Visa Intelligent Commerce](https://corporate.visa.com/en/products/intelligent-commerce.html), enabled by crypto, frames agentic checkout around approved AI “agents” for consumers to manage their card(s) online, for merchants, it frames around similar but additional factors such as fraud/dispute protections, merchant acceptance, and especially “trust in transaction” for each payment context (visa online, in app, etc.), all already handled for them by existing payments networks. PayPal also recently announced integration of Mastercard’s Agent Pay into PayPal wallets [Mastercard Agent Pay will integrate with PayPal's wallet](https://newsroom.paypal-corp.com/2025-10-27-Mastercard-and-PayPal-Join-Forces-To-Accelerate-Secure-Global-Agentic-Commerce) to enable merchants to accept payments from AI agents acting on behalf of users that have added their payment methods to the wallet.\n\nThe runtime layer has to own the authority model before this becomes the normal pattern.\n\nDefine the payment intent schema. Include purpose, merchant scope, amount, budget, evidence required, approval required, signer scope and receipt destination. Treat as an object from day one. Use for backend logic as well as for generating form fields for human fill-in-the-blanks approval actions.\n\nA path for runtime control of payments above and beyond enterprise wallet offerings is to first implement a policy engine, write policies as simple rules which Finance and Security can understand, and test against various scenarios. Service allowlists are only a first input, but purpose, budget window, task owner, customer account, and approval state all impact payments.\n\nMake approval a runtime event: The approval should pause the payment intent, show the policy match, capture a bounded decision, and then resume or reject the workflow. In other words, do not make “approve agent action” a button.\n\nTest out denial paths. If all a payment system can test for is successful settlement, the team is asking for a weird Friday afternoon. Denied payment, expired approval, revoked signer, duplicate retry, failed settlement, disputed transaction, and exhausted budget all need first-class paths.\n\nAgentic payments are going to make agents feel useful since they are able to buy data, pay for API calls, issue credits, book services… for companies within specified policy. That is real work.\n\nThe agent runtime becomes a spending control plane.\n\nCompanies will get agentic payments right by starting from a different vantage point than existing payment ‘solutions’ and beginning with a plain set of questions for every transaction: who is delegating the spend; what policy will be enforced on that spend; where is the approval for the spend delegated; and what receipt will prove that the transaction was for the business.\n\nThen the wallet can sign.", "url": "https://wpnews.pro/news/agentic-payments-move-spending-authority-into-the-runtime-focused-labs", "canonical_source": "https://dev.to/focused_dot_io/agentic-payments-move-spending-authority-into-the-runtime-focused-labs-41i8", "published_at": "2026-05-28 04:06:26+00:00", "updated_at": "2026-05-28 04:24:01.513033+00:00", "lang": "en", "topics": ["ai-agents", "ai-products", "ai-tools", "ai-startups", "ai-infrastructure"], "entities": ["LangChain", "Privy", "Harrison Chase", "Focused Labs"], "alternates": {"html": "https://wpnews.pro/news/agentic-payments-move-spending-authority-into-the-runtime-focused-labs", "markdown": "https://wpnews.pro/news/agentic-payments-move-spending-authority-into-the-runtime-focused-labs.md", "text": "https://wpnews.pro/news/agentic-payments-move-spending-authority-into-the-runtime-focused-labs.txt", "jsonld": "https://wpnews.pro/news/agentic-payments-move-spending-authority-into-the-runtime-focused-labs.jsonld"}}