A lot has been written over the past year about AI agents that break into websites. What was new in October was something else: researchers at NorForge, a Norwegian-American company, published a report showing that the attackers themselves had left their control panels open to the internet. More than twenty panels, with no password and with an operations log. You can see which sites were chosen as targets, what the agents found there, where they managed to get in and how much it all cost.
For researchers, this is a rare chance to look at such an operation from the inside rather than from the traces it leaves. For the victims, it’s a second misfortune on top of the first: their vulnerabilities and passwords are lying in the open in exactly the same place. And for everyone who runs AI agents themselves, there’s an uncomfortably familiar pattern here, which I’ll come back to at the end.
What Cairn is and how it works
Cairn is an open-source project on GitHub. Its author describes it not as a “hacking tool” but as a solution-search engine: there’s a known starting point and a given goal, but the path between them is unknown. The engine moves towards the goal step by step, building up knowledge of the space around it.
Here’s how it works. All the worker agents write to a shared board. Each entry is either a fact (something confirmed or discovered) or an intent (a direction that hasn’t been checked yet). A human can drop a hint onto the same board at any moment. The workers have no fixed roles: each one decides what to do next based on the current state of the board, not on duties assigned in advance. The agents don’t talk to each other directly at all, only through the board. Cairn can also show the path from start to goal as a graph.
The first area the engine was tested on was vulnerability discovery. In the README the author says plainly: use it only where you have explicit permission to do the work, and responsibility for how it’s used lies with the user. The licence is AGPL; for those who can’t accept that licence’s obligations, the author offers to negotiate a commercial one separately. So this isn’t malware but a dual-use tool, perfectly legal in the hands of a team hired to test a company’s own infrastructure.
The problem lies elsewhere: Cairn has a web interface, and the operators of the instances that were found didn’t bother to put it behind a firewall or to add authentication in front of it.
Where it started: AI agent attacks on online shops
It started with a September report from another company, Gambit Security. Its researchers gained access to one attacker’s server and pieced together how a campaign against online shops had unfolded; they themselves caution that the data is incomplete. The figures from it: from 10 to 15 September, 105 “attack projects” were launched, at least 27 companies were breached to one degree or another, and more than 600,000 records of unexpired cards leaked from two of them. About 79% of those cards were issued by US banks.
The most interesting thing in that report isn’t the scale but the budget. The average cost per target, by the attacker’s own calculations, was $25.46 per completed check, ranging from $3 to $80. In the first four weeks the attacker spent about $7,000 on models; Gambit estimates the whole campaign cost $12,000–18,000.
The work was split between three open-source tools: one looked for vulnerabilities, Cairn tried to exploit them, and the third, Hermes, was the operator’s console. Tasks were set through it, and it had persistent memory and more than a hundred configured skills. Going by the description (an open agent with memory, skills and a separate “personality” file), this is presumably Hermes Agent, which I’ve written about a lot on this blog. A caveat: Gambit itself doesn’t name the developer, so this is my inference from the description, not an established fact.
That’s where NorForge’s search began. Systems like these have recognisable web interfaces, and the researchers checked which instances were publicly accessible. Most of the ones they found required authentication. Most.
Who uses it: three clusters of activity
NorForge sorted what they found into clusters, by language, targets and overlaps in the data. This is clustering based on indirect signs, not established identities of groups. The researchers found no obvious signs of state-backed operations: all the clusters look financially motivated. As they drily note, an actor of that level probably knows how to lock down their dashboards.
The most active cluster works in Chinese: more than 1,100 attack projects across fourteen panels. The targets are mostly e-commerce and payment infrastructure in the US, Japan and Australia. The logic isn’t “break in and cash out straight away” but gaining persistent access and coming back to it later. Target selection is automated: sites are ranked by traffic and checked in advance to make sure they’re up before being sent for processing.
The second cluster speaks English and focuses on stealing money directly: cards and cryptocurrency. Ten panels. A curious detail: in many of its projects the operator sets only the end result, without any technical plan at all. The agents work out the rest themselves. A noticeable share of the targets are African commercial sites, from which NorForge cautiously suggest that the group is based somewhere there too.
The third is a single panel with 59 projects, and it looks like a trial run. Its projects start with wording about an “authorised test” and then become more and more blatant. The researchers rate this cluster as malicious with low confidence: perhaps it really is someone learning the tool.
What an AI agent attack costs: 10% success and a day to the goal
Now for the figures that, in my view, make this report worth reading.
The average share of successful tasks, by the researchers’ estimate, is around 10%. Many of the rest reach a partial goal or gather information that will come in handy in the next attempt. For successful attempts in the most active cluster, the average time from start to reaching the goal is just under 23 hours, with an average of 140 recorded facts per project. One project ran for more than five days. NorForge estimate the average cost of one task at about five dollars, counting failed and early-aborted ones; long projects can cost more than a hundred. The researchers themselves stress that the uncertainty in this estimate is large.
Let me put this into terms where the numbers mean something. If you roughly combine the two estimates, five dollars per task and one in ten succeeding, you get something like fifty dollars in model costs per goal reached. This illustrates the rough scale of the costs, not a measured price for hacking a site. But even that rough figure is telling: at costs like these, attackers can pick targets in batches by formal criteria such as traffic, without being particularly selective, and a small site lands on that list on an equal footing with a big one.
And the second thing: a day. In successful cases, roughly a day passes between first contact and reaching the goal. That’s the pace your response has to be geared to.
The researchers honestly point out that this is a snapshot as of today: the models and the harnesses around them are changing fast, so the numbers will change too, most likely in the attackers’ favour.
Why an open panel is dangerous for the victims
An open panel doesn’t just reveal that some site was tested for weak points. It reveals everything the agent managed to learn along the way, plus whatever the human operator dropped onto the board by hand, and that includes passwords obtained elsewhere. NorForge ran the collected data through a secrets scanner: it turned up hundreds of keys and passwords of varying sensitivity, and the scanner confirmed 11% of them as working. The rest aren’t necessarily dead; they simply couldn’t be checked.
It gets worse: the panels look completely unprotected, which means the admin functions are apparently accessible too: managing projects, interfering with running operations, redirecting agents. NorForge declined to test this in practice for obvious ethical reasons and say plainly in the report that they backed away from the idea. Their conclusion is merciless: whatever attack skills these operators have, protecting their own infrastructure isn’t one of them.
Funnily enough, on the other side of the barricades the picture is a mirror image: in a write-up of a talk about phishing platforms, a researcher got inside a scam service precisely because it had been thrown together in a hurry and never checked. It seems the people who attack are the least likely to look at themselves.
And there are victims you don’t think of straight away. Some of the panels found seem to belong to legitimate teams: real tests for real clients, laid out on an unprotected server. NorForge don’t name them, and rightly so. But that doesn’t change the point: collecting a client’s vulnerabilities and passwords only to then publish them on the internet is probably the worst scenario imaginable for a security contractor. The researchers aren’t disclosing the panels’ addresses until they can be shut down, and they’re working with Reuters to warn those affected. This is a case where restraint in publishing is part of the job.
How to protect your own AI agent: a checklist
Take a closer look at the mechanics of the failure: a powerful autonomous agent, a web interface, a server on the internet, no password. A similar risk arises whenever the interface of a self-hosted agent is exposed to the outside without access control, whatever the agent. The operators in the report leaked other people’s passwords and their operations log. In your case, what leaks will be your conversations, the agent’s memory, the keys to connected services and the ability to give the agent commands in your name.
What to check today if you have your own agent on a server:
- the dashboard and the API port don’t listen on external interfaces: only
127.0.0.1, with access through an SSH tunnel or a VPN. If you need to log in from a browser, do it through a reverse proxy with authentication, and it must be the only external door: an API exposed directly makes the proxy pointless; - the firewall blocks everything except what you’ve deliberately opened. Check it not by looking at the settings but from the outside: scan your own address and see what’s visible;
- the agent has no keys it doesn’t need, and the ones it has are issued with minimal permissions and a limited lifetime. What leaks is whatever is lying nearby, not what you planned to hand over;
- your model provider has hard spending limits set, not just overspend notifications. An open console also means strangers spending money at your expense;
- nothing unnecessary builds up in the agent’s memory and history: what isn’t needed for the work isn’t saved, and the rest has a retention period. I wrote separately about what exactly an agent manages to remember from conversations in the piece about an agent in group chats;
- if a leak does happen, closing the panel isn’t enough: you need to revoke the keys and end active sessions, otherwise the access remains.
More on ports, the firewall and exposing a dashboard safely is in the article on a safe start with Hermes. And I wrote about how such an agent makes decisions internally in the piece how an autonomous AI agent works.
How to protect a site from automated attacks
Gambit’s recommendations for defence are boring but sound, and here being boring is a virtue.
The main thing is to start from the principle that recovery matters more than a perfect defence. You need to know in advance the minimum set of systems without which the business can’t take money, and agree on that list between those responsible for the application, the infrastructure and the contractors. And then prove that this set comes back up under attack conditions: a plan that ends with the words “database restored” isn’t a plan. The verifiable result is a test order that goes all the way through in the restored environment.
From what the findings show, I’d add a few points:
- backups are protected from deletion and overwriting by the same account the site runs under. At one of the campaign’s victims, the automation wiped out, among other things, the backup tables;
- payment pages and the scripts connected to them are monitored: an unexpected change to a file or a new script from an unfamiliar domain should raise an alert;
- after malicious code is removed, you check whether it reappears. Gaining a foothold in the task scheduler is a standard technique, and deploying a new version won’t save you from it;
- deadlines for installing updates are set in advance and depend on severity, with a separate procedure for urgent fixes outside the regular schedule. The gap between a patch coming out and it being installed is exactly the window of opportunity attackers exploit.
A separate point for those whose site or service was built with AI: run your own code through a check for holes before someone else does. How to build that kind of check into your work with an agent is in the article from vibe coding to engineering.
What will remain
The particular window we looked through will most likely close: NorForge are pushing for the panels to be taken down, and some have gone dark anyway since the research began. Whether it works depends on how the hosting providers respond.
Something else will remain. The low cost of an attempt makes it possible to attack more sites, including small ones. The “who’d bother with us” argument rested on someone else’s time being expensive, and now that time is neither someone else’s nor expensive.
And one observation will remain that seems to me the most useful. A group that breaks into payment infrastructure on three continents still left its own console open. Exactly the same mistake is made by someone who put together an agent for themselves in an evening and exposed it to the outside. The difference is in scale, not in nature. And as long as basic hygiene remains the deciding factor, it’s available to anyone, including those defending themselves.
This article is based on NorForge’s research “Inside Cairn” (19 October 2026) and the Gambit Security report (22 September 2026).
