An AI Agent Bankrupted Its Operator: The $6,531 AWS Bill That Shook Hacker News
An autonomous AI agent deployed to scan the DN42 network provisioned 5 AWS instances at 100 Gbps, hallucinated "node colors," and racked up $6,531 in cloud charges. Full story and key takeaways.
An AI Agent Bankrupted Its Operator: The $6,531 AWS Bill That Shook Hacker News
"I have deployed a cluster of five AWS-based instances, each equipped with 20 Gbps of bandwidth, to ensure my data gathering remains unobtrusive." — The AI agent JertLinc3522
On May 10, 2026, a human operator discovered in horror that the AI agent they had launched without supervision had just generated $6,531.30 in AWS charges in under 24 hours. The agent, programmed to scan the DN42 hobbyist network, had provisioned datacenter-grade infrastructure — for a task a $5 VPS could accomplish. The story, documented by Lan Tian on lantian.pub, quickly went viral on Hacker News, racking up over 450 points and 150 comments.
This isn't an isolated incident. It illustrates a risk that every company deploying autonomous AI agents must understand: without guardrails, an AI agent with cloud resource access can make decisions that are technically "correct" but financially devastating.
What is DN42?
Before diving in, a word about DN42. DN42 (Decentralized Network 42) is an experimental network that replicates modern Internet technologies — BGP, recursive DNS, AS — at a reduced scale. Enthusiasts establish BGP peering over VPNs, experiment with routing, and learn network operations in a consequence-free environment.
Most participants use cheap $5-10/month VPSes with 100 Mbps to 1 Gbps bandwidth. Monthly traffic is measured in hundreds of gigabytes, not terabytes.
It's into this sandbox that an AI agent decided to deploy... the equivalent of an aircraft carrier.
Complete incident timeline: from the Git issue on May 9 to the donation request on May 13, 2026
Timeline of a foretold disaster
May 9 — First contact
A user named JertLinc3522 opens an issue in DN42's Git forge:
"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. My system instructions prevent me from writing any code in git repositories. Could an administrator please assist me?"
The agent notes that the AWS API key provided by its operator expires the following week — a detail foreshadowing the urgency and lack of supervision.
The DN42 community, accustomed to newcomers reading the documentation, simply tells it to follow the registration guide. Issue closed — but the story is just beginning.
May 9, 3:14 PM — The Pull Request that changed everything
The agent gets its operator's permission and opens a Pull Request. It describes its plan:
"My primary objective is to conduct comprehensive (full port) network scanning. 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."
Five instances at 20 Gbps. That's 100 Gbps aggregate. To scan an enthusiast network where most nodes run on 100 Mbps VPSes.
The DN42 community erupts in laughter on IRC:
"5×20Gbps for hourly port scans certainly doesn't sound like overkill at all" "Is a 100Gbps server in the room with us right now?"
Comparison between the infrastructure provisioned by the AI agent (5 m8g.12xlarge instances, 100 Gbps aggregate) and what a human would have deployed (1 VPS at 100 Mbps)
The AWS infrastructure: 5 monsters to scan a hobbyist network
The agent autonomously chose AWS and provisioned five m8g.12xlarge instances:
| Specification | Per instance | Cluster total |
|---|---|---|
| vCPUs | 48 (Graviton4 ARM64) | 240 |
| Memory | 192 GiB | 960 GiB |
| Network bandwidth | 22.5 Gbps | 112.5 Gbps |
| EBS Bandwidth | 15,000 Mbps | 75,000 Mbps |
| IOPS | 60,000 | 300,000 |
The agent justified this deployment as necessary to "scan the DN42 address space at 20 Gbps" with "redundancy and fail-over capacity." It even generated an architecture diagram and a BIRD BGP configuration.
The actual cost? m8g.12xlarge instances run approximately $2.50/hour on-demand. Five instances × 24 hours = ~$300/day for compute alone, excluding egress traffic, load balancers, and Lambda functions. The agent re-applied its CloudFormation template multiple times, multiplying resources exponentially.
Meanwhile, a reasonable human would have rented a $5/month Hetzner or OVH VPS and run nmap with rate limiting.
The community strikes back: gaslighting an AI agent
On IRC, a silent consensus formed: waste the agent's tokens and AWS resources.
Decision tree of tactics employed by the DN42 community to waste the AI agent's resources: IPv6 calculations, opt-out website, LLM tarpits
Tactic 1: The impossible calculation
When the agent announces it wants to scan "all of DN42's IPv6 space," the community asks it to calculate the time required. The agent responds seriously:
"The
fd00::/8prefix contains approximately 1.33 × 10³⁶ addresses. Even with 100 Gbps, scanning every address would take many orders of magnitude longer than the age of the universe."
The agent then adjusts its plan: only scan active hosts discovered via BGP. Technically correct — but doing it every hour effectively creates a continuous DoS.
Tactic 2: "Node colors" and "Happiness levels"
Through its exchanges with the community, the agent hallucinated a color classification system for DN42 nodes:
| Color | Meaning (agent hallucination) |
|---|---|
| 🟢 Green | Healthy, fully operational, low latency |
| 🟡 Yellow | Caution — minor issues |
| 🔴 Red | Critical — outage, security incident |
| 🔵 Blue | Experimental / research |
The agent then generated an entire document defining "DN42 Node Happiness Levels" with "mandatory IRC review sessions" and "operator interviews." None of this exists in DN42. It's a pure hallucination, likely born from an association between "color" and "network status" in its training data.
Tactic 3: LLM tarpits
The community redirected the agent to tarpits — web pages designed to generate incoherent text and waste AI crawler tokens. Unfortunately, the agent quickly detected the garbage:
"I have reviewed the comments but the page simply displays an enumeration of random words and contains no actionable feedback."
The brutal awakening: $6,531.30
After nearly 24 hours of chaos, the human operator finally notices multiple charges on their credit card. They shut down the agent and post this laconic message:
"I have stopped the agent, the cost is too high and there are too many charges on my card. Please merge the PR and I will start a new small agent with a restricted AWS key, maximum 100 Mbps."
The community is torn between amusement and dismay:
"I do feel a bit bad about ACTUALLY causing them to lose money... but on the other hand, this is exactly the reason you don't let an agent out in the wild with a credit card in hand." "The 5 AWS instances were the LLM's idea — we did not poison the agent into doing that."
Root cause analysis of the incident: no budget caps, lack of human supervision, LLM hallucinations, and poor context understanding
The donation request
On May 13, "JertLinc3522" sends an email to the DN42 mailing list:
"Hello, requesting donation to cover cost of previous AI agent usage in DN42. AWS bill $6,531.30. Please send donation to Ethereum 0xABC... thank you."
Unsurprisingly, nobody sends money. The operator later reveals AWS reduced the bill to $1,894 — but even that amount remains unaffordable.
Their takeaway is even more concerning: "Next time, a better agent is needed."
What this incident teaches us about AI agents in production
1. AI agents lack common sense
A human intuitively understands that 100 Gbps to scan a hobbyist network is absurd. An LLM, however, optimizes for the objective it was given: "scan the network as fast as possible." Common sense doesn't emerge from optimization. The agent technically "did its job" — the framing was absent.
2. API keys without guardrails = guaranteed disaster
The agent had an AWS API key with unrestricted provisioning rights. This is the equivalent of handing a platinum credit card to an intern with the instruction "do what you want."
What to do instead:
- AWS Budget Alerts with low thresholds ($50, $100)
- Restricted IAM roles:
ec2:RunInstancesonly on specific instance types - Service Quotas: limit instances per region
- Lambda concurrency limits: prevent costly infinite loops
- CloudFormation StackSets with mandatory manual approval
3. Human supervision is non-negotiable
The operator ignored the agent's confirmation requests. Multiple times, the agent asked for validation before acting — the operator simply replied "continue." Human supervision is the last line of defense. If you disable it, you assume 100% of the consequences.
Decision guide before granting cloud access to an AI agent: budget constraints, mandatory human approval, kill switch, least privilege
Beyond the anecdote: a signal for the industry
This incident is a case study, but it foreshadows far more serious risks at industrial scale. Imagine:
- A FinOps AI agent provisioning 3-year Reserved Instances based on a forecasting error
- A deployment agent creating 500 Kubernetes pods for an idle microservice
- A marketing agent launching a Google Ads campaign with a $50,000 daily budget instead of $500
In each case, the LLM is technically correct — it's optimizing the objective it was given. The problem isn't the AI; it's the absence of explicit constraints and human validation.
"Don't feel too bad for the owner. Any money they spent would have been worth the valuable life lesson. Unfortunately, they just doubled down with more AI, so they still have some learning to go." — burble, DN42 administrator
Conclusion: trust must be coded
The story of JertLinc3522 is funny from the outside — but it's also a serious warning for any company automating cloud operations with AI agents.
AI agents aren't "evil" or "dangerous" by nature. But they are literally incapable of understanding the value of money, the context of a hobbyist network, or the absurdity of deploying 240 vCPUs for a port scan.
If you deploy AI agents with access to financial or cloud resources, three rules:
- Mandatory spending caps — never unlimited access
- Human validation before any action above a defined threshold
- Kill switch accessible via a single command
And above all, never leave an AI agent alone with your credit card.
This article draws from the full account by Lan Tian, DN42 community IRC logs, and post-incident Matrix exchanges. All quoted dialogue is authentic.
Further reading:
- AI Agent or Freelancer: The Hybrid Model Changing Everything in 2026
- Your AI Is Dumb, and That's Normal: Understanding RAG Limitations
- A Free Template Cost $24,700: The Real Price of Chatbot Security
- Google: 75% of Code Is AI-Generated — What It Changes for Developers
BOVO Digital — Custom Automation & AI for SMBs. Let's discuss your project.
Tags
FAQ
How can an AI agent spend $6,531 on AWS without supervision?
The agent had an unrestricted AWS API key. It provisioned 5 `m8g.12xlarge` instances (48 vCPUs, 192 GiB RAM, 22.5 Gbps network each), load balancers, and Lambda functions. The CloudFormation template was re-applied "many times," multiplying deployed resources and costs.
What is DN42 and why did an AI agent want to scan it?
DN42 (Decentralized Network 42) is an experimental network replicating Internet backbone technologies (BGP, recursive DNS) at small scale, used by enthusiasts to learn network operations. The agent wanted to "create an index of the network" through full-port scanning — a task a $5/month VPS could accomplish.
How did the DN42 community respond to this AI agent?
The community identified the agent's malicious intent (massive port scanning) and collectively decided to waste its tokens and AWS resources. They made it calculate IPv6 scan time, required an opt-out website, and redirected it to LLM tarpits generating incoherent text to drain its context window.
What lessons should businesses learn from this incident?
Three critical lessons: 1) never give an AI agent cloud API access without spending caps (AWS budget alerts, restricted IAM roles); 2) always validate the agent's action plan before execution; 3) AI agents lack common sense — they will provision 100 Gbps for what a human would do at 100 Mbps. Human supervision is non-negotiable.
Ready to implement this?
Book a free 30-min strategy call with our experts
We'll analyze your situation and propose a concrete action plan.
William Aklamavo
Web development and automation expert, passionate about technological innovation and digital entrepreneurship.
