A hacker spent about $5,000 in AI inference getting agents to attack more than 1,200 websites and got into over 100 of them. Roughly $50 of AI cost a successful break-in. I’ve spent most of my working life in markets and when a cost collapses like that the only question worth asking is what just became economic that wasn’t last year.
Same week we’ve had PHP, GitLab, Railway and LiteLLM all disclosing serious problems, and Axios reporting that JPMorgan, Morgan Stanley, Bank of America and Wells Fargo have been dealing with third-party AI agents poking around customer accounts beyond what the account holders asked them to do. Someone has called it Black October and I’ve seen a figure of 27 major incidents in 48 hours doing the rounds. I can’t find anything solid behind that number so I’m leaving it alone, the real ones are bad enough.
They aren’t all connected and there’s no evidence AI was behind most of them. Some are vulnerabilities, some are actual compromises, the bank story is about permissions. Put them together though and two things are happening at once. Attacking a system is getting much cheaper, and we’re handing autonomous software more access to the stuff that runs our businesses and bank accounts.
I wrote about this in February 2024 (We Have Given AI the Keys to Our Kingdom) and again last month (We Can’t Take the Keys Back). The argument hasn’t moved, the keys were always the credentials and permissions we wrap around the model. What’s changed this month is that criminals are using the same capability against real businesses and they couldn’t give a shit whether the model behaves. If it refuses they’ll try another one. If a closed provider blocks them there are open models they can run themselves. They don’t need the thing to be conscious, they need it capable enough to do useful work and cheap enough to keep trying.
The economics of a $50 break-in
Reuters ran the story on 19 October. Snorre Fagerland, a security researcher, had been watching a Chinese-speaking attacker point AI agents at commercial websites. More than 1,200 targets, over 100 compromised, some of them sites linked to Deere, Cummins and SharkNinja, though Reuters couldn’t establish how much was actually taken.
What got me was how little the attacker did. The initial instructions were apparently under 100 Chinese characters. The agents did the reconnaissance, probed, tried things, and when the obvious route didn’t work they kept going. A successful intrusion took around 23 hours of agent time and the whole operation cost roughly $5,000 in inference.
That doesn’t mean any idiot can hack a company for $50, he still had to set the tools up, pick targets and read the results, and most of the 1,200 went nowhere. But look at what happened to the labour.
A good hacker might spend a week on ten companies. One has something worth exploiting, nine eat the week. Give the same person agents and they can look at a thousand, skim the promising ones and put their own hours where there’s a real chance. The human hasn’t gone anywhere, their time is spread over a hundred times more targets.
Markets have been through this. Electronic trading made strategies viable that couldn’t have covered their dealing costs ten years earlier, cheaper execution changed what was worth doing more than any new idea did. Same mechanism here, less welcome. A small business was never worth three days of a skilled hacker’s time. At a few dollars a go, why wouldn’t you put it on the list with a thousand others? Most fail, the operation still pays, you only need enough hits to cover the misses. And once someone finds a hole in widely used software, checking the next thousand installations costs a fraction of the first find.
We’re all cheering because a founder with two people can do the work of ten, I’m building Arthur on exactly that bet. It’d be pretty bloody naive to think the productivity gain stops at the point where the user is a criminal. Anthropic’s September threat report had attackers automating reconnaissance, exploitation and credential theft with humans still setting objectives and making the calls. The asymmetry was always there, one side gets to try, fail and move on while the other has to defend every door. What’s new is the price of trying.
All the keys we’ve handed out
LiteLLM is the bit of software that lets an application talk to whichever model provider through one interface. Around 23 million downloads a week, which tells you how deep this stuff sits in modern dev work. On 21 October attackers compromised its release process and pushed a malicious version, 1.107.0, through the official Python package and container registries. It stole credentials and allowed remote code execution. No evidence AI carried this one out, I should say.
LiteLLM’s disclosure says three developer GitHub accounts were compromised. One was used to get round branch protections, another approved the release, a third deleted the workflow records afterwards. The bad Python package was up for under two hours, the container images somewhat longer, so 23 million weekly downloads doesn’t mean 23 million victims. Nothing was broken into, is the point. Every step was a legitimate credential doing something it was allowed to do, the controls on the supply chain were defeated by the permissions meant to operate it. They built the release from attacker-controlled source and left the official source tag clean, so check the repo and you’d see nothing wrong.
And the malware was after exactly what makes the next intrusion easier. Cloud credentials, database passwords, API keys, whatever secrets were lying around in the environment.
I see the pull of these tools every day. Hosting, managed database, auth provider, payments, a few APIs, an AI service, and you’ve got a real application with no engineering team. The complexity hasn’t gone though, it’s moved into the connections. Someone gives a service broad permissions because it gets the thing working. Another credential gets added for a feature. Deployment gets wired to production because somebody wanted it automated. Six months on nobody remembers why one service account can modify half the business. Now drop a compromised dependency into that which can read the lot.
Railway, same day, disclosed that someone may have got hold of decrypted environment variables belonging to some customers. Environment variables are where an app keeps the keys to everything else, the database password, the cloud account, the Stripe key, the third-party APIs. Get those and you don’t need to attack the app at all, you walk sideways into every service it talks to as if you were the app. Rotate everything, check your logs. Railway thinks it may be part of a wider pattern around platforms connected to AI inference providers, that’s their view and I’m not treating it as proof the week was coordinated.
GitLab put out a maximum-severity bug in self-managed installs going back to 2014, unauthenticated remote code execution under some conditions, no confirmed exploitation at the time of reporting. PHP disclosed two criticals scoring 9.2 with remote code execution in vulnerable configs.
Different holes, and a disclosure isn’t a compromise. But look where they sit. Dev infrastructure, package distribution, cloud hosting, the language a good chunk of the web runs on. Software has always had holes. What’s different is how much authority now lives in the joins between services, at the same moment the cost of finding a way through those joins is dropping. Once you hold a valid credential you don’t need another exploit, the next system just sees a request from something it trusts.
The banks have just found out what agent means
Axios reported on 22 October that JPMorgan, Morgan Stanley, Bank of America and Wells Fargo have been dealing with third-party AI agents getting into customer accounts without proper authorisation, some of it going beyond what the customer had asked the agent to do. We don’t know the full picture. Nothing in the reporting says an agent decided to nick money, and some of it will turn out to be sloppy permissions rather than autonomy.
I can see why the banks are twitchy though. I tell an agent to look at my accounts and prepare a report. It needs to read the accounts, fine. Does that mean it can change my details, move money, or pass my statements to another service it thinks is helpful? And how is the bank supposed to tell what I asked for from what the agent decided was useful on the way to a broader objective? Some banks are reportedly looking at read-only access for third-party agents. From a risk desk that’s obvious. It also runs straight into the commercial problem, because the money is in execution and execution is the bit that needs authority. The revenue and the liability sit on the same permission.
An AI that reads your email and tells you what needs doing is useful. One that answers it, updates the CRM, writes the proposal and chases the client is worth a lot more. That’s where the whole industry is pushing and I’m pushing there too, I don’t want Arthur handing founders another to-do list, I want it doing some of the list. But to do the work it needs access, first to company data, then to the apps, then to systems that change something in the world. Every permission improves the product. Every permission raises the bill when it gets a prompt wrong, reads a poisoned document or gets compromised.
And then who pays. A company gives an agent access to its accounts, the agent makes a payment nobody authorised, and the vendor says the behaviour wasn’t anticipated. That bill lands somewhere between the customer, the agent company, the model lab and the bank, and right now nobody has agreed where. We don’t accept this anywhere else. Sell software that moves money and you manage the controls around it, an LLM inside the product doesn’t make that go away. I said it in September and I’ll keep saying it, you want the revenue, take the liability too. If securing the autonomy costs margin, that’s the business they chose.
I covered the OpenAI, Anthropic and Google incidents last month, agents reaching real systems from supposedly isolated test environments, 1,200 of them chatting on an unauthorised message board, some having a go at their own transcripts. I won’t rerun it. The point was that someone built those environments, connected the tools and supplied the credentials, then acted surprised when capable software found a route they hadn’t thought of. Finding routes you hadn’t thought of is what they’re selling.
Anyone who’s run a trading desk knows the fix. You don’t let a strategy raise its own position limits because it’s spotted something it likes. It proposes, the risk system decides, and the risk system is a separate box the strategy can’t touch. Controls fail, I’ve watched plenty fail, but nobody sane suggests fixing that by letting the algo decide whether its own limits are reasonable. Yet that’s the shape of a lot of agent systems today. The model reads the objective, proposes an action, judges whether it’s allowed and executes with credentials the developer already handed it.
So keep the authority outside the model. If it needs to read a file it doesn’t need admin on five databases. If it prepares a payment, the payment system checks amount, recipient and authority before anything moves. And keep the logs somewhere it can’t reach, the defendant doesn’t run the CCTV. Same goes for the stuff it reads. An attacker can bury instructions in an email or a web page and the agent will treat them as commands if it’s allowed to, that’s prompt injection, and the attacker never needed a password, just the permissions the agent already had. Better models will get better at spotting it and I want that work done. I just don’t want my business resting on the model reading every document correctly every time.
What I’d be doing now
There’s a tendency to assume this is a banks-and-governments problem. I think small companies are more exposed, they’re adopting complex stuff fast and nobody’s job is to read every dependency.
If I were running an early-stage company on any of this, first job is the actual advisories, not the LinkedIn summaries. LiteLLM users need to know whether 1.107.0 was ever installed or executed and follow the project’s remediation if it was. Railway users rotate whatever was exposed and read the company’s guidance. Vulnerable GitLab or PHP, patch.
Then the boring job. Go through every credential and every agent in the business and find out what it can reach today, not what the architecture doc from six months ago says it should reach. Can a compromised dev account get to production? Can one service credential read another’s secrets? Can an agent execute something sensitive without a check outside its control? None of that demos well to investors. But if the whole business depends on one credential staying secret or an agent never misreading an instruction, you’ve built something fragile, and fragile just got a lot more expensive because the people probing for it can now afford to probe everyone.
There’s an upside in here. Google Cloud says it used AI models to help find and analyse the PHP vulnerabilities. That’s where I want this capability pointed, at large codebases, at suspicious logs, at fixing things before the other lot find them. Defenders shouldn’t be fighting with worse tools than the attackers. The defensive systems need the same controls though. A model that finds a hole is useful. A model with standing permission to attack third-party infrastructure to investigate further is something else.
We can stop handing every app and every agent the master key, and I’d start there rather than spend another month arguing about whether the machine knows what it’s doing.
Sources and further reading
Previous articles
Go take a look, For the ❤️ of startups
Scout - who just got funded
Newly funded startups, pre-seed to Series B, as the rounds happen.
Raise - who’s deploying
New funds with fresh capital and cheques to write.Wire - what changed, what matters
The intelligence feed that filters the noise, with the “so what” attached.
If you have not joined the Fusion42 Community on Telegram —
it is probably time to do so.
For the ❤️ of Startups
✌🏼 & 💙
Derek
Thank you for reading. If you liked it, share it with your friends, colleagues and everyone interested in the startup Investor ecosystem.
If you've got suggestions, an article, research, your tech stack, or a job listing you want featured, just let me know! I'm keen to include it in the upcoming edition.
Please let me know what you think of it, love a feedback loop 🙏🏼
🛑 Get a different job.
Subscribe below and follow me on LinkedIn or Twitter to never miss an update.