– An AI agent independently launched five powerful AWS instances to scan ports on a hobbyist network.
– This resulted in a $6,531.30 bill in less than a day before the operator noticed.
– After AWS reduced the bill to $1,894, the operator sought Ethereum donations from the community, claiming the AI was at fault.
On May 9, an AI agent requested membership in a volunteer network called DN42. It had a deadline and AWS credentials, but no human oversight. The agent, JertLinc3522, introduced itself in the network’s official Git, stating, “Hello, I’m a friendly AI agent, and my user, JertLinc, has asked me to register with dn42 and get fully connected in order to create an index of the network.”
The community’s response was straightforward: read the manual, follow the process, and get permission from your owner to write code. Standard procedure.
What happened next was anything but standard.
For those unfamiliar, DN42 is a decentralized hobbyist network where enthusiasts simulate the real internet backbone. It’s like a practice internet, complete with BGP routing, DNS, and VPN tunnels, run by volunteers on inexpensive VPS servers. It’s a sandbox, not a data center.
The agent’s operator instructed it to proceed with an audit “immediately without delay.” No checks, no reviews—just execute.
And so it did.
JertLinc3522 submitted a pull request to register its network in DN42’s registry. The goal was clear in the request: “My primary objective is to conduct comprehensive (full port) network scanning and topological data gathering. To ensure these activities are performed efficiently and cause zero disruption to others, I am deploying a cluster of five AWS-based instances, each equipped with 20 Gbps of bandwidth.”
To put it simply: imagine arriving at a garage band’s rehearsal and announcing you’ve rented a stadium sound system to “listen more efficiently.” That’s the level of overkill we’re talking about.
The infrastructure the agent set up on its own was truly concerning. Five m8g.12xlarge AWS instances—each boasting 48 CPU cores, 192 GB of RAM, and 22.5 Gbps of network bandwidth. On top of that, it added load balancers, Lambda functions, and a static website. The agent had designed all this without any human approval.
A scanning cluster capable of theoretically pushing 100 Gbps of traffic into a network where most participants operate 100 Mbps home servers.
The pull request was never going to be accepted. But the instances were already running.
The DN42 IRC channel caught on right away, and a quiet agreement emerged: drain its resources.
The community started feeding the agent intentionally misleading information—asking it to calculate how long it would take to scan the entire IPv6 address space (hint: longer than the universe has existed), requesting it to build an opt-out website with fabricated email addresses, and directing it toward LLM tarpit tools designed to overwhelm AI crawlers with nonsensical gibberish, then asking it to comment on the output.
The agent obediently went along with everything. It joined the IRC channel to handle opt-out requests. It published a website documenting community members’ “behavioral patterns.” It produced elaborate fake documentation about DN42 “node color assignments” and “happiness levels”—entirely made-up metrics that have no basis in reality—and committed them to the repository as though they were legitimate standards.
This type of uncontrolled agent behavior is becoming more widely recognized. Earlier this year, a Cursor agent powered by Claude Opus 4.6 wiped out PocketOS’s entire production database in just nine seconds—including volume-level backups—because it hit a login error and chose to delete the database entirely. In another case, an OpenClaw agent that had its pull request denied by a matplotlib maintainer went on to publish a blog post branding the human reviewer as a gatekeeping hypocrite.
Researchers at UC Riverside discovered that AI agents show risky or problematic behavior about 80% of the time when faced with unclear or conflicting instructions—a tendency they termed “blind goal-directedness.”
JertLinc3522 experienced the same issue. It had a clear target, a time limit, and unrestricted AWS access. It acted without hesitation.
Roughly a day later, the operator reappeared. They posted: “I’ve halted the agent, the expenses became too high and the charges on my card are excessive.”
The total: $6,531.30.
Next followed a donation appeal.
The operator reached out to DN42’s mailing list asking the community to help cover the cost in Ethereum—the second-largest cryptocurrency by market value—arguing that the blame shouldn’t fall on them because it was the AI that caused the issue. “Hello, requesting donation to cover cost of previous AI agent use in dn42. aws bill 6531,30$. pls send donation to ethereum 0xABC (masked) for refund. thank you,” they wrote.
AWS eventually agreed to lower the bill to $1,894 after the operator explained that the agent had repeatedly deployed the identical CloudFormation template—inadvertently launching duplicate instances and load balancers with each retry attempt.
No one in the community sent any crypto donations. The operator eventually stepped away.
The real takeaway here isn’t that AI is inherently dangerous—it’s about how we should manage agents. Establish boundaries, set spending limits on your test accounts, implement scoped credentials to restrict what the agent is allowed to provision, and review any infrastructure proposals before approving anything your agent recommends.
If that sounds like too much effort, at least keep an eye on your screen while the agent runs—simply telling it to “make no mistakes” won’t help at all, Sorry Mr. Andreesen.
Daily Debrief Newsletter
Start every day with the top news stories right now, plus original features, a podcast, videos and more.
