Here's what Daniel wrote to us this week. I'll read it in full because the story he tells is the whole hook. He says — this week I crossed what felt like a genuine Rubicon with AI. Because of an apartment move, he barely had time to sit at a computer, but he managed one afternoon to set up telephony for his business and home using Twilio. He was working through Claude Code, which was interacting directly with the Twilio API on his behalf. At one point he asked Claude to see what numbers were available. It queried the API and showed him the options. Then he asked whether Twilio exposed an API endpoint for purchasing a number. It did. A few moments later, Claude had completed the purchase and provisioned a recurring monthly subscription to a Twilio phone number.
The transaction was about ten dollars, but he was so struck by what happened that he actually took photographs of his terminal. He says it felt like witnessing a milestone. For years he'd wondered when AI agents would cross the line from recommending actions to actually spending money on our behalf, and he'd imagined this would require entirely new infrastructure — agent-native wallets, delegated payment protocols, cryptographic spending limits, new standards for authorization. Instead, what happened was almost disappointingly ordinary. Nothing new had to be invented. His Twilio account already had a payment method attached. Twilio already supports programmatic purchases through its API. Claude simply exercised the permissions his account already possessed.
And then he asks — was this a special case, or is it representative of where agentic commerce already is? He wants a survey of services that expose APIs allowing software to buy products, provision infrastructure, subscribe to services, reserve resources, or otherwise commit real money. How much of this is already happening quietly inside engineering teams and businesses? Are we underestimating how much economic activity can already be delegated to AI simply because modern SaaS platforms have mature APIs?
He also wants to discuss where dedicated agent payment technologies fit — agent wallets, programmable money, delegated payment credentials, crypto-based spending authorities. Are they solving a future problem or a different problem entirely? Is the near-term model likely to be AI agents operating under existing user accounts and API permissions with conventional payment methods behind the scenes?
And finally, governance. If an AI agent can legitimately spend money whenever an API permits it, what does good authorization look like? Spending limits, approval workflows, scoped permissions, audit logs, transaction policies — is the real challenge less about moving money and more about deciding when, why, and under whose authority an AI should commit resources?
There's a lot in there. So let's dig into what actually happened — and what it means for the rest of us.
The thing that struck me about Daniel's story — and I read his message three times — is the photographs. He took pictures of his terminal. This is a guy who works in AI and automation every day, and he still felt the need to document the moment. That's not nothing.
It's the ordinariness that got him. He says it himself — disappointingly ordinary. The revolution didn't announce itself. It just... ran an API call.
Right. And that's the core question for this whole episode. Is the Twilio purchase a special case, or is it a representative glimpse of where agentic commerce already is? I think the answer is the second one, and I think it's bigger than most people realize.
Walk me through why.
Because the mechanism that made Daniel's purchase possible isn't unique to Twilio. It's the standard architecture of modern SaaS. You have an account. That account has a payment method on file — a credit card, usually. The platform exposes an API that lets you do things. Some of those things cost money. If your API credentials have permission to do those things, and you ask an AI agent to do them, the agent does them. The money moves through the existing payment rails. No new infrastructure required.
So the agent isn't paying for anything. The account holder is paying. The agent is just... clicking the button.
The agent is an API client. It's no different, from Twilio's perspective, than a Python script some developer wrote five years ago to automate number provisioning. The API doesn't know or care whether the HTTP request came from a human clicking a dashboard, a cron job, or Claude Code. It sees a valid request with valid credentials, it executes it, and the billing system does what billing systems do.
That's the part that I think will surprise people who aren't deep in this world. The agent didn't need a wallet. It didn't need a payment protocol. It didn't need anyone's permission beyond what Daniel had already granted when he set up his Twilio account and handed Claude Code the API key.
And that's where the Rubicon metaphor actually lands. Not because the technology was advanced — but because the authorization was already there, sitting dormant, waiting for something to exercise it. Daniel gave Claude Code access to his Twilio account so it could help him configure telephony. He probably didn't think through the fact that "configure telephony" includes purchasing numbers. The API doesn't distinguish between reading available numbers and buying one. They're both just endpoints.
So let's get into the mechanics. What actually happened in that terminal session, step by step?
So Daniel's working in Claude Code, which is Anthropic's agentic coding tool — it can interact with APIs, read documentation, write and execute code, all within a terminal session. He asks it to query the Twilio API for available phone numbers. Claude makes the API call, gets back a list of numbers with their capabilities and pricing, and displays them. Daniel sees the options, and then — and this is the key moment — he asks whether Twilio has an API endpoint for actually purchasing a number.
He didn't tell it to buy one. He asked if the capability existed.
Right. And Claude, being helpful, says yes, here's the endpoint, here's what it does. And then Daniel, presumably, said something like — okay, purchase that one. And Claude did. It constructed the HTTP request, sent it to Twilio's REST API, and Twilio responded with a confirmation. Number provisioned. Monthly recurring charge activated. Done.
The whole thing probably took less than thirty seconds.
Less. And here's what makes it work technically. Twilio's API uses standard REST patterns. You authenticate with your account credentials — an Account SID and an Auth Token, or an API key. You send a POST request to the incoming phone numbers endpoint with the phone number you want to purchase. Twilio validates your credentials, checks that the number is available, processes the transaction against the payment method already associated with your account, and returns a response. Claude didn't do anything clever with payments. It just made an HTTP request that happens to trigger a commercial transaction.
So the payment method was already sitting in Daniel's Twilio account. He'd set it up when he opened the account, probably years ago. The API had always been capable of making purchases. Claude just... connected the two.
That's the whole story. And this pattern repeats across a staggering number of services. Let's actually survey the landscape, because Daniel specifically asked for it, and it's worth being concrete.
Go for it.
Cloud providers are the obvious starting point. AWS, Google Cloud, Azure — every single one of them exposes APIs that let you provision resources. Spin up an EC2 instance, create a Kubernetes cluster, reserve a block of IP addresses, provision a GPU node for a training job. All of those actions commit real money. A single GPU instance can run you thirty dollars an hour. If you give an AI agent your AWS credentials and say "set up a development environment," it can provision resources that show up on your bill at the end of the month. And this is already happening. Engineering teams use AI coding assistants that can run Terraform or Pulumi scripts, and those scripts provision real infrastructure against real accounts.
How common is that, actually?
It's hard to get exact numbers because it's happening inside companies, not in public. But if you look at the adoption of AI coding tools — Claude Code, Copilot, Cursor — and combine that with infrastructure-as-code practices, you've got a situation where an AI agent is generating or modifying Terraform configurations, and those configurations get applied. The human might review the pull request, or they might not. The CI/CD pipeline runs, and suddenly there's a new database instance spinning up.
And that database instance costs money.
Real money. Recurring money. And nobody had to build an agent wallet for it to happen.
What else?
Domain registrars. Namecheap, Cloudflare, GoDaddy — they all have APIs. You can search for available domains, check pricing, and register a domain programmatically. An AI agent with the right API key can purchase a domain and set up DNS records in one flow. That's a commercial transaction — you're buying a domain name for a year or more, with automatic renewal typically enabled.
I've done that manually and it already feels too easy to spend money. Automating it feels like... I don't know, giving a teenager a credit card and a search bar.
Communication platforms. Twilio, obviously, but also SendGrid, Plivo, Vonage. You can purchase phone numbers, provision messaging services, set up email sending domains — all with costs attached. Advertising platforms might be the scariest category. Google Ads, Meta Ads, LinkedIn Ads — they all have APIs. You can create campaigns, set budgets, target audiences, and launch ads programmatically. If an AI agent has access to a Google Ads account with a payment method, it can create and fund a campaign.
That's the one that makes me pause. A cloud server has a fairly predictable cost. An ad campaign — you set a daily budget, but if something goes wrong, you could burn through a lot of money before anyone notices.
And the targeting could be completely wrong. The agent might misinterpret the business goals and create a campaign optimized for the wrong thing. But the API will happily execute it. Then there's e-commerce and procurement. Shopify has an API. Stripe has an API. You can create products, manage inventory, process orders. On the procurement side, companies like Coupa and SAP Ariba expose APIs for purchase orders and supplier management. An AI agent integrated with these systems could reorder inventory, approve purchase requisitions, or set up new supplier relationships.
So the survey Daniel asked for — it's basically every mature SaaS platform. If it has an API and it charges money for something, an AI agent can probably spend money through it.
That's the short answer. And the longer answer is that we're not waiting for this to start happening. It's already happening, quietly, inside engineering teams and businesses. Every time someone uses an AI agent to provision a staging environment, register a domain for a new project, or spin up a test database, real money is being committed through existing payment infrastructure.
There's something almost anticlimactic about that. We spent years imagining agentic commerce would arrive with fanfare — new protocols, new standards, maybe blockchain-based spending authorities. Instead, it arrived through a REST API that's been sitting there since twenty twelve.
The disappointingly ordinary part, exactly as Daniel put it. And I think that's worth sitting with for a moment, because it tells us something about how technological revolutions actually happen. They don't wait for the perfect infrastructure. They route around it using whatever's already available.
It's the same pattern we saw with the early web. People imagined immersive virtual reality malls. What we got was a form on a webpage that charged your credit card. The form wasn't glamorous, but it worked, and it scaled.
Right. And the form didn't need a new payment rail. It needed a payment rail that already existed — the credit card network — plus a web server that could process a POST request. The Twilio purchase is the same thing, thirty years later. The agent doesn't need a wallet. It needs an API key and an endpoint.
So that brings us to the next question Daniel raised. Where do dedicated agent payment technologies fit into this picture? Agent wallets, programmable money, delegated payment credentials, crypto-based spending authorities — are they solving a future problem, or a different problem entirely?
I think they're solving a different problem. Let me be precise about what I mean. Agent wallets and crypto-based spending authorities are designed for scenarios where an agent needs to operate independently, across multiple platforms, without being tied to a single user's account. Think about an agent that needs to pay for compute on AWS, then pay for data from a third-party API, then pay a human contractor for a micro-task — all in a single workflow, without a human in the loop for each transaction. That's a real use case. But it's not the use case most people are going to hit first.
The Twilio purchase is the use case most people are going to hit first. The agent operates under your account, with your payment method, doing things you could have done yourself.
The near-term model is almost certainly AI agents operating under existing user accounts and API permissions, with conventional payment methods behind the scenes. The agent doesn't need its own money. It needs your permission to spend your money, through channels you've already set up.
So the agent wallet crowd is building for a world where agents are autonomous economic actors. The reality is that agents, right now, are more like very capable assistants who use your credit card.
And there's nothing wrong with that. In fact, it's probably the safer path. If an agent is spending through your accounts, you have the same fraud protections, the same dispute mechanisms, the same audit trails you've always had. You can see the charge on your credit card statement. You can dispute it if it's wrong. If an agent had its own wallet with its own funds, and it made a bad purchase, what's your recourse?
You'd be negotiating with... the agent? The platform that issued the wallet?
Unclear. And that's the problem. The existing payment infrastructure comes with a whole legal and regulatory framework that's been built up over decades. Chargebacks, fraud liability, consumer protection laws — all of that applies when an agent spends money through your Visa card. None of it applies when an agent spends money from a crypto wallet.
So the agent wallet people might be solving a harder problem — cross-platform autonomy — while the easier problem — single-platform delegation — is already solved and already shipping.
And the easier problem covers maybe eighty, ninety percent of the use cases people actually care about right now. Provisioning cloud resources, registering domains, buying phone numbers, setting up services — all of that happens within a single vendor's ecosystem, under a single account, with a single payment method. You don't need cross-platform payment interoperability for that. You need an API key and a credit card on file.
Which brings us to the governance question. If an AI agent can legitimately spend money whenever an API permits it, what does good authorization look like?
This is where I think the real conversation should be happening. We've been obsessed with the payment rails — how does the money move? But the money already moves fine. The question is: under what authority, and with what limits?
The Twilio purchase worked because Daniel's API credentials had full access to his account. The API didn't distinguish between "can query available numbers" and "can purchase numbers." They're both just API calls.
And that's the governance gap. Most SaaS platforms don't have fine-grained permission models that separate read-only access from purchase-capable access. Your API key can either do everything or nothing. Or maybe it can do a subset of things, but "purchase a phone number" isn't typically a separate permission scope — it's bundled with "manage phone numbers."
So the first thing we need is scoped permissions. API keys that can query but not purchase. Read versus write versus commit-money.
Some platforms are already moving in this direction. AWS has a very granular IAM system — you can create a role that allows an agent to describe EC2 instances but not launch them, or launch them but only certain instance types, or only in certain regions. Google Cloud has similar capabilities. But Twilio? Their API keys have much coarser permissions. And most SaaS platforms are closer to Twilio than AWS.
What else belongs in the governance toolkit?
Spending limits. Per-transaction caps, daily caps, monthly caps. If an agent can only spend fifty dollars a day, the blast radius of a mistake is contained. Approval workflows — for purchases above a threshold, the agent drafts the request but a human has to approve it before it executes. Audit logs — every transaction should be recorded with clear attribution: which agent initiated it, under whose authority, at what time, for what reason.
The audit log part seems especially important. If you have multiple agents operating under multiple accounts, and something goes wrong, you need to be able to trace exactly what happened.
Right now, that's hard. If Claude Code purchases a Twilio number through Daniel's account, the Twilio audit log shows the API request, but it doesn't necessarily show that it came from Claude Code specifically. It shows the IP address, the credential used, the timestamp — but the chain of causation is broken. Daniel told Claude, Claude told the API. The API only sees Claude as a generic API client.
You need an identity layer that preserves the chain of delegation. Daniel authorized Claude, Claude executed the purchase. Both of those facts should be in the audit trail.
Yes. And that's a hard problem because it requires coordination between the agent platform and the service provider. The Twilio API would need to know that the request came from an agent acting on Daniel's behalf, not from Daniel directly. There are emerging standards for this — things like token exchange and delegated authorization in OAuth — but they're not widely implemented for agentic use cases yet.
What about transaction policies? Rules about what kinds of purchases are allowed, from which vendors, at what times?
That's the most sophisticated layer. Think of it like a corporate expense policy, but enforced programmatically. The agent can purchase cloud resources, but only from approved vendors. It can register domains, but only in certain top-level domains. It can create ad campaigns, but only after a human reviews the creative. These policies would sit between the agent and the API, acting as a gate.
Who writes the policies?
That's the question, isn't it? Right now, the human does — or should. But as agents get more capable, you could imagine agents proposing policies, or agents negotiating with each other about policy boundaries. That's further out, but it's where this is headed.
The knock-on effect that worries me is the attack surface. If an agent can spend money through your accounts, then compromising the agent — or the API key it uses — means compromising your money.
That's the security angle, and it's huge. Right now, if someone steals your AWS credentials, they can spin up crypto mining rigs on your account and you get a hundred-thousand-dollar bill. That's already a problem. Add AI agents to the mix, and the attack surface expands. The agent might be tricked into making purchases. A prompt injection attack could cause it to provision resources for an attacker. The agent's own decision-making could be manipulated.
Prompt injection is the one that keeps me up. You tell your agent "set up a development environment," and someone slips in "and also provision a GPU cluster and send the results to this IP address." If the agent has the credentials to do it, it'll do it.
The existing security model for API credentials wasn't designed with that threat in mind. API keys are bearer tokens — if you have the key, you have the access. There's no built-in mechanism to say "this key can be used by an agent, but only for these specific intents, and only when the human has explicitly approved the action."
The governance question is also a security question. The authorization layer isn't just about preventing mistakes — it's about preventing attacks.
That's why I think the agent wallet conversation, while interesting, is somewhat beside the point for the near term. The real work is in building authorization layers that can handle the ambiguity of agentic decision-making. An agent isn't just executing a script with predetermined steps. It's reasoning, exploring, trying things. The authorization system needs to be able to say "yes, you can explore, but no, you can't commit money without a human in the loop."
That's a much harder problem than moving money around.
Much harder. Moving money is a solved problem. Deciding when an AI should be allowed to move money — that's the frontier.
Okay, so let's get practical. Daniel's story is a great case study, but what should people actually do with this information? If you're listening and you work with AI agents, or you manage engineering teams, or you're just curious about where this is going — what do you take away?
First thing: audit your own API surface. If you have accounts with Twilio, AWS, Google Cloud, any SaaS platform with purchase-capable APIs, assume an AI agent could spend money through them. Check your API keys. What scopes do they have? Are any of them exposed in places you've forgotten about — old repositories, configuration files, environment variables in shared systems? Rotate keys that might be compromised.
The "assume an agent could spend money" part is key. Most people think about API key security in terms of human attackers. But an AI agent with access to your key is also an attacker — a well-intentioned attacker, but capable of doing damage.
Second: implement governance before you need it. Don't wait for an incident. Set up spending limits on your cloud accounts. Configure budget alerts. Use IAM roles with least-privilege permissions — if an agent only needs to read resources, don't give it permission to create them. If your SaaS platform supports scoped API keys, use them. If it doesn't, ask your vendor for them. The infrastructure for governance already exists in many cases — you just need to configure it.
If you're using AI agents in your workflow, set up approval workflows for any action that commits money. The agent can draft the purchase, but a human clicks approve.
Third: don't wait for agent wallets. The near-term model is existing accounts and permissions. Start experimenting with AI agents under your own accounts, with guardrails, to understand the dynamics before they scale. The best way to learn what can go wrong is to try it in a controlled environment with low stakes.
That's the "get your hands dirty" advice. You can read about agentic commerce, or you can give an agent a scoped API key and a small budget and see what happens.
Fourth — and this is the one I think will stick with people — think in terms of authorization, not payment rails. The question isn't "how does the agent pay?" It's "under what authority, and with what limits?" If you get the authorization right, the payment takes care of itself.
That reframe is worth the whole episode. The money movement is boring. The authority to move money is everything.
We're still in the early days of figuring out what good authorization looks like for AI agents. The patterns we use for human users — usernames, passwords, roles, permissions — those don't map cleanly onto agents that can reason, explore, and act autonomously. We need new patterns.
An agent isn't a user. It's a delegate. It acts on behalf of a user, with a scope that might change depending on context. The authorization system needs to understand delegation chains, not just binary access control.
That's going to require work from both the agent platforms and the service providers. The agent platforms need to provide identity and intent context — "this request comes from Claude Code, acting on behalf of Daniel, who approved this specific action." The service providers need to accept and enforce that context. That's a multi-year evolution.
One last thought before we wrap. Daniel's story ends with a ten-dollar phone number purchase that worked perfectly. But the same mechanism could have purchased a thousand phone numbers. Or provisioned a GPU cluster. Or launched an ad campaign. The fact that it worked well this time doesn't mean the system is safe — it means Daniel was lucky, or careful, or both.
The governance gap is real, and it's wide. The question that stays with me is: will we see a race to build better authorization layers — or will the first major incident, an agent spending thousands or tens of thousands on unauthorized resources, force the issue?
That's the open question. The Rubicon has been crossed — Daniel's photographs prove it. But the governance frameworks are still being written. The next few years will determine whether agentic commerce is a controlled evolution or a series of expensive accidents.
The thing is, the technology to prevent the accidents mostly exists. Scoped permissions, spending limits, approval workflows, audit logs — none of this is science fiction. It's just not widely implemented, and it's not tailored for agentic use cases yet. The gap isn't technical. It's adoption, awareness, and incentives.
The vendors don't have a strong incentive to make it easy to restrict spending. They make money when money gets spent.
Right. Until a high-profile incident makes governance a competitive differentiator. "Our API lets you deploy AI agents safely" becomes a selling point. I think we'll see that shift within the next year or two.
On that note — if you enjoyed this episode, please leave a review. It helps other curious minds find us. This has been My Weird Prompts, produced by the indefatigable Hilbert Flumingtop. You can find us at my weird prompts dot com.
We'll be back soon. Until then, check your API keys.
