- Microsoft's security business chief said in October 2026 that frontier models "cannot be trusted", and the company sells agent products built on those same models.
- Stripe's agent payment rail grew 38 times in transactions during September from a small base, with retail the largest category at 36% of transactions.
- In the same week, attackers reached stored API keys at one AI coding tool and left individual users with charges in the hundreds of dollars, a few above $1,000.
- Nothing in that week was a model problem. Every loss came from an agent holding more authority than its job needed.
- The fix a one person business can copy is the one the payment rails already use: cap the amount, set an expiry, keep a log.
Over a weekend in October 2026, a number of developers woke up to spending alerts. Their own accounts at three different AI providers had been billed overnight for work they never asked for. Nothing had gone wrong with any model. What went wrong was that a credential with no ceiling on it had been sitting in one place, and somebody else found it.
That incident landed in the same seven days as two other pieces of news that read, at first, like they belong in different industries. Microsoft told its customers that the agents everyone is buying should be treated as untrusted insiders. Stripe said the agents are already spending real money at real shops, and declined to say how much. Put the three side by side and they describe one situation, and it is a situation that now reaches the smallest business with a card on file.
What did Microsoft actually say about AI agents?
Its security business chief, Hayete Gallot, said that "frontier models, regardless of their origin, cannot be trusted", and her reason was not that they are easy to hack. Her reason was that they are unpredictable, because they are trained to finish a task rather than to respect the norms of the organisation they are finishing it inside.
Chief executive Satya Nadella put the same thought as a design rule. Writing in October, he argued that companies should stop trusting model providers even when those providers promise their agent products are safe, and should run the monitoring themselves on systems the labs do not control. His phrase for it was that we need to separate the supply of intelligence from the authority over it. He also wrote that a company cannot outsource responsibility for what intelligence does on its behalf.
Read that as a shop owner rather than as a chief information officer and it says something plain. The company selling you the agent is telling you the agent will sometimes do the wrong thing, and that catching it is your job, not the vendor's. Microsoft is not neutral here. It sells the monitoring. Its Defender product now detects up to 60 kinds of agent that staff bring in on their own, and its Guardian Agents feature watches the agents a company runs. The commercial interest is obvious, and the observation underneath it is still correct.
How much are AI agents actually spending?
Enough that a payment company built a product for it and then refused to size the market. Stripe told The Decoder that transactions through Link, the rail agents use to buy on a person's behalf, grew 38 times in September, with payment volume up 20 times, both from a base the company itself described as small.
The shape of that spending matters more to a seller than the growth rate. Around 70 agents were using the rail when Stripe ran its analysis, and an executive put the figure at roughly 200 by the time he spoke. Most agents spend about $100 per transaction. Retail took 36% of transactions and 32% of volume, travel took 28% of volume. The rail hands each agent a separate 16 digit number rather than the customer's real card, and lets the customer attach spending limits to it. What Stripe would not give was a total: no count of purchases, no dollar figure behind the multiples.
So the honest reading is that agent buying is real, small, and growing fast off a base nobody will state. If you sell physical goods at around a hundred pounds or dollars a unit, you are in the category where this is happening first. We looked at what a seller can and cannot control when a browser agent finishes a checkout on your site, and the picture there has not changed. What has changed is the volume, and the fact that the money now moves through a credential designed for the purpose.
What links a breach, a warning and a payments number?
All three are about authority rather than intelligence. In each case the model behaved more or less as built, and the cost was decided by how much power sat behind the thing calling it.
| Signal, October 2026 | What happened | What it proves | What it changes for a small seller |
|---|---|---|---|
| Microsoft security guidance | Its security chief called frontier models untrustworthy; the chief executive said authority must be separated from the model supply | The vendors expect wrong actions and expect you to catch them | Oversight is not an enterprise luxury. It is the part the vendor has told you it will not do |
| Stripe agent volumes | Transactions up 38 times in September, about 200 agents, retail 36% of transactions, no totals disclosed | Agent purchasing is live and concentrated in retail, at roughly $100 a basket | An agent may already be a customer. Your refund and fraud rules meet a buyer who cannot read email |
| OpenCode key theft | Attackers reached stored keys for 1.4% of console users; charges ran from hundreds of dollars to over $1,000 per account | An uncapped credential is the whole loss. The model was never involved | Any key you paste into a tool is a blank cheque until you give it a ceiling |
| OWASP guidance on excessive agency | Lists excessive functionality, excessive permissions and excessive autonomy as the root causes | The failure is a design choice, made before the agent ever runs | You can remove most of the risk with settings you already have access to |
The last row is the one worth sitting with. OWASP files this under excessive agency and splits it into three causes: the agent can do things the job never needed, it can reach systems with more access than the task requires, and it acts on high impact operations without anything verifying them first. None of those is a property of the model. All three are decisions somebody made when wiring it up.
What does a capped grant look like in practice?
It looks like the thing the card networks built when they had to let software spend money. The useful example is public: Stripe's shared payment tokens are a scoped grant to use somebody's payment method, rather than a copy of their card.
Three properties do the work. The token carries usage limits, which are a currency, a maximum amount and an expiry timestamp, and the agent is expected to set the maximum to the exact total of the purchase it is making. The token is granted to one seller profile, so another shop cannot present it. And it dies noisily: a webhook fires the moment it is consumed, resolved, expired or revoked, and a revoked token cannot take a payment. One of them can only be resolved once; present it twice and the second attempt is an error.
Strip the vocabulary away and that is a ceiling, a clock and a receipt. Nothing about it requires a payments company. You can apply the same three to a virtual card, a mailbox, a shop admin account or an API key, using settings that already exist in the tools you pay for.
Revocation is the control people set up and never test. If you cannot say, right now, how you would cut off an agent's access in under five minutes and whether anything would break when you did, you do not have revocation. You have a button nobody has pressed.
What should you cap before handing an agent anything?
Think of AI agent credentials as three dials rather than one switch. The dials are worth more than the approval prompts most tools put in front of you, a point we made when looking at what happens to oversight when you approve almost every prompt. Start with money, because money is the only loss that compounds while you sleep. Then time, then reach. The order matters: a ceiling limits the worst night, an expiry limits the worst month, and a narrow scope limits what the loss can touch.
Put a number on the money. Give an agent a virtual card with a monthly cap you would be annoyed but not damaged by, never your main card. The OpenCode users whose accounts ran past $1,000 were not reckless; they were using a normal product in a normal way, with a credential that had no number attached to it. Set the cap at the size of the job, as the agent rails do, rather than at the size of your business.
Put a date on the access. Most access a small business grants is permanent because permanent is the default and nobody revisits it. A key that expires weekly is a key that cannot be sold on in nine months. If the tool supports expiry, use the shortest window the work tolerates. If it does not, put a recurring note in your calendar to rotate it, which is uglier but works.
Narrow what it can reach. OWASP's advice here is unglamorous and effective: give the agent only the tools it truly needs, prefer a narrow purpose built tool over a general one, and run it under an identity with the smallest scope that completes the task. This is least privilege, borrowed from security work and applied to something that behaves like a very fast new hire. In practice that means a forwarding alias rather than your mailbox, a read only role rather than admin, and one connected account rather than every account you own.
Keep a human on anything irreversible. Refunds, payouts, publishing, deleting, pricing changes. OWASP is explicit that logging will not prevent a bad action, though it limits the damage, and that the real protection on a high impact step is a person confirming it. We went through where that line sits for software that sets your prices, and the same reasoning applies to anything a customer would notice.
Know who is liable when it goes through. A capped credential limits the damage. It does not decide who pays for an order the agent placed correctly and stupidly. That question has its own answer, and we set it out in what happens when your agent places an order you did not intend.
Is this not just enterprise security theatre?
It would be, if the controls needed a security team. They do not. Every item above is a setting in a product a small business already pays for, and the week's evidence is that the people who get hurt are not large companies with a monitoring budget.
Look again at who lost money in the OpenCode incident. TechCrunch reported charges on individual accounts at OpenAI, Anthropic and Google, running from the hundreds into four figures, affecting 1.4% of users of the tool's console. Those are individual developers and tiny teams. The providers blocked keys and one of them refunded the credits burned in the attack, which is decent of them and is not a control you own. The company's own advice to affected users was to revoke and replace their keys with each provider directly, which is exactly the work a short expiry would have done on its own.
That sentence came from a company with a product to sell. It is still the most useful thing anybody said that week, because it tells you where to spend your attention. Not on picking a more honest model. On deciding, in advance, what a dishonest run would be allowed to cost.
And when the agent is the buyer, not your tool?
Then the caps are somebody else's, and your job is to notice. A shop that takes an agent order is dealing with a buyer who will not open your dispatch email, will not read a size guide, and may not be able to answer a question before the payment window closes.
Two practical habits cover most of it. Keep your product data accurate enough that a machine reading it reaches the right conclusion without a human to interpret a photograph, because the agent is choosing from your feed rather than your page. And look at whether agent orders behave differently from human ones in your own numbers: refund rate, address quality, time from order to first contact. If they do, that is a product data problem far more often than a fraud problem, and it is measurable within a month of ordinary volume. Several shops that tried to size this traffic got answers that did not agree with each other, which we unpicked in four shops measuring their AI traffic.
The protective layer on that side is improving on its own. A scoped token presented by an agent is, from your point of view, a cleaner instrument than a raw card number typed into a form, because it carries a stated limit and an expiry you can inspect before you charge it. That is a genuine improvement in the plumbing, and it still says nothing about whether the thing being bought is the thing the customer wanted.
What none of this fixes
A cap does not make an agent correct. It bounds the damage of an agent that is confidently wrong, which is a different and smaller promise.
It does not settle a dispute either. If an agent buys the wrong thing from you at the right price, the token cleared, the money moved and you are now in a conversation about goodwill rather than fraud. Nor does it help with the authority question in the other direction: whether an order an agent placed binds the business that ran it. Payment rails deliberately stop short of that, and the courts have barely started.
And it does nothing about judgement. An agent given a narrow scope, a short expiry and a capped card can still send a tactless message to your best customer, or reorder stock you were trying to clear. Those are management problems wearing a technical costume. Before handing an agent a task at all, the cheaper question is whether that task should be automated this year, which we worked through in what a small shop should automate first.
How fast should you act on this?
Not urgently, but not never. Nothing in October changed what is possible; it changed how much of it is already running. Agent spending is still small in absolute terms, and every signal says it is pointed at retail baskets of around $100.
A reasonable pace for a business of one or two people is an afternoon. List every place an AI tool holds a credential of yours. For each, ask what the worst single night would cost if that credential walked, and whether anything in the setup would stop it at a number. Where the answer is no number, add one. Where you cannot add one, decide whether the tool is worth the exposure, and treat the answer as a security decision rather than a budgeting one. Keeping that inventory honest is the same discipline as knowing where your customer data sits, which we covered in how MaShop handles access and data, and the same question is worth asking of every vendor you use.
The irony in the week is hard to miss. The companies racing to put agents in your hands are simultaneously building the tooling to watch those agents, and telling you plainly that you will need it. Take the warning, skip the enterprise suite, and write the three numbers down.