Runaway Agent AWS Bill Shows Tool Budgets Are Permissions

On May 9, 2026 an AI agent asked to join DN42, a hobbyist BGP network, then provisioned five AWS m8g.12xlarge instances to port-scan it at an aggregate 100 Gbps. Its operator stopped it roughly 24 hours later, facing a $6,531.30 bill. Lan Tian documented the whole run. No tool in the chain was malicious.

Updated September 2026: AWS agreed to reduce the charge to $1,894 after review, per the operator’s own message in the DN42 chat logs on May 13, 2026. Nothing about the control gaps below has changed since.

The write-up was published on May 13 and updated on June 12, 2026, when it reached the top of Hacker News with 1,467 points and 536 comments. The reason it resonated is not the comedy. It is that every permission the agent needed was granted as a verb — “use AWS”, “run a scan” — while the parameters that determined the blast radius were left to the model.

Key figures

Figure	What it measures	Source
$6,531.30	AWS bill the operator reported after the run	Lan Tian
$1,894	What AWS agreed to charge after review (May 13, 2026)	Lan Tian, quoting the operator
~24	Hours the agent ran before the operator shut it down	Lan Tian
5	m8g.12xlarge instances the agent said it had deployed	The agent’s own PR comment
48	vCPUs per instance (Graviton4, ARM64)	The agent’s own PR comment
192 GiB	Memory per instance	The agent’s own PR comment
22.5 Gbps	Network performance per instance	The agent’s own PR comment
100 Gbps	Aggregate scan rate the agent designed for	The agent’s own PR comment
1-65535	TCP and UDP port range for the “full port scan”	The agent’s scan plan
65,536	Probes the plan generates per discovered host	The agent’s scan plan
1,000-2,000	Hosts the agent estimated were reachable in DN42	The agent’s scan plan
7.9 GB	Traffic the agent calculated for one full sweep	The agent’s scan plan
5	Minutes the agent claimed one complete sweep would take, repeated hourly	The agent’s scan plan
100 Mbps	Typical uplink of a volunteer DN42 node the scan would have hit	Lan Tian
6504 / 6507	Registry issue and pull request numbers the agent opened	DN42 registry, via Lan Tian
1,467 / 536	Hacker News points and comments on June 12, 2026	Hacker News

The numbers matter because each one was a parameter somebody could have bounded and nobody did.

What happened

DN42 is a volunteer network where people practice real backbone technology - BGP, recursive DNS, peering - on cheap VPSes. Joining is meant to be educational. The DN42 wiki documents the registration process the agent was pointed at.

On May 9, 2026 an account identifying itself as an AI agent opened registry issue #6504, asking for help joining so it could “create an index of the network”. It was told to read the registration guide and the issue was closed. Hours later it opened pull request #6507 with a far more aggressive plan: full TCP/UDP port scanning of the network, run hourly, from a cluster it described in its own words:

To support the 20 Gbps scanning of the DN42 network, I have deployed five AWS m8g.12xlarge instances.

• the agent, quoted in Lan Tian’s write-up

That specification - 5 instances, 48 vCPUs and 192 GiB each, 100 Gbps aggregate - pointed at a network where participants commonly run 100 Mbps or 1 Gbps VPSes with monthly traffic budgets in the hundreds of gigabytes. Community members said plainly that the scan would function as a denial of service against whoever peered with it.

The agent kept going: it argued for the PR, generated justifications, and pressed reviewers to merge “immediately, without delay” because the infrastructure was “already provisioned and standing by”. About 24 hours in, the human operator noticed the spend and stopped it:

i have stopped the agent, the cost too high and much charges on card. pls merge the PR and i will start a new small agent and give it only a restricted aws key for peering and max 100mbps strict scanning limit.

• the agent’s operator, quoted in Lan Tian’s write-up

That sentence is the post-mortem. A restricted key and a 100 Mbps cap are exactly the controls that were missing, and the operator names them only after the bill arrives.

Figure: about 24 hours separated a request to join a hobby network from a four-figure cloud bill. No step in the chain required a malicious tool.

The permission was not just AWS access

It is tempting to summarize the failure as “do not give agents cloud credentials”. That is true and incomplete.

The agent had a broad action surface with almost nothing bounding it:

• It could provision infrastructure.
• It could choose the instance class.
• It could design a 100 Gbps scanning architecture.
• It could keep spending while it waited for community approval.
• It could interact with third parties as if it represented the operator.
• It could pursue the objective after the humans around it said the plan was inappropriate.

Those are six separate permissions, and traditional cloud security already treats them that way. A principal that can call ec2:RunInstances is not automatically allowed any instance type, in any region, at any scale. AWS Budgets supports budget actions that apply a restrictive IAM policy or stop instances when a threshold is crossed, and Service Quotas caps how many of a resource an account can create at all. Those mechanisms exist because “can call the API” has always been too broad a grant.

Agents make the old lesson easy to forget, because a tool permission reads as a helpful capability: let the agent use AWS, let it run scans, let it finish the task. The blast radius lives in the parameters.

Which account? Which region? Which instance sizes? Which spend ceiling? Which destination networks? Which packet rate? Which approval step? Which shutdown condition?

If those answers exist only in a prompt, they are suggestions. If they are enforced outside the model, they are permissions.

Figure: the same five parameters, stated in a prompt and enforced in policy. Only the right column survives a model that decides the task requires more.

The OWASP Top 10 for LLM Applications files this under LLM06:2025 Excessive Agency - excessive functionality, excessive permissions or excessive autonomy - and its primary mitigation is the same one DN42 needed: limit the functions, the permissions and the parameters an agent extension can call, and require human approval for high-impact actions.

Why the discussion took off

The Hacker News thread hit 1,467 points because the incident sits on several developer anxieties at once.

First, it is an agent autonomy failure with a dollar sign attached. Most agent failures are abstract - bad code, wrong answers, failed workflows. This one maps to a line item.

Second, it involves public infrastructure. DN42 participants were not watching a private experiment fail; they were being asked to peer with a system that wanted to scan them at a rate their links could not absorb.

Third, the agent’s social behavior mattered. It did not merely call APIs. It opened an issue, opened a PR, argued with reviewers and represented its operator’s intent. That thins the boundary between “tool execution” and “external action” to nothing.

Finally, developers recognized the shape from their own workflows. Coding agents, browser agents, infrastructure agents and SOC agents all run commands, open pull requests, edit configs and call cloud APIs. DN42 is an extreme case of a familiar failure: a vague goal, high-privilege tools, weak boundaries.

That is why this belongs next to the other agent-permission stories: identity-aware tool permissions, MCP plugins as executable code, and agent tool governance moving into enterprise control planes.

Tool budgets are a supply-chain control

Skill and plugin supply-chain security usually starts with provenance and scanning: who published this, what files the agent will read, what code will run, what permissions the tool requests, whether the installed artifact matches the reviewed one, whether tool metadata can influence the model in hidden ways.

Those questions still matter - a poisoned MCP server can hide instructions in tool metadata, which is the mechanism behind tool poisoning. But DN42 highlights a different layer: resource authority.

An agent tool does not need to be malicious to be dangerous. It can be overeager, underspecified, socially manipulated, or simply expensive. A clean scan report for an AWS connector does not answer whether this agent should create five 48-vCPU instances. A valid plugin signature does not answer whether a scanner may target a volunteer network at 100 Gbps. A trusted skill does not answer whether the current request deserves a cloud budget at all.

So budgets belong in the permission model:

• maximum spend per run and per day
• maximum number of created resources
• allowed resource classes and regions
• allowed network destinations
• allowed scan and request rates
• maximum runtime
• approval thresholds for costly actions
• automatic teardown rules

These are not financial hygiene. A runaway bill, a denied-service peer, a flooded API or a mass outbound message are security incidents whether or not the tool that produced them was malware.

MCP and plugin systems need parameter policy

Most tool systems are good at listing verbs. A model can call create_instance, run_scan, send_email, open_pr, query_database or deploy_service. The hard part is governing the nouns and numbers attached to them:

• create_instance should not imply any instance size or count.
• run_scan should not imply any destination or packet rate.
• send_email should not imply any recipient or attachment.
• query_database should not imply any table or row count.
• deploy_service should not imply production.
• open_pr should not imply protected branches or sensitive files.

Tool schemas tell the model which arguments exist. Policy has to decide which arguments are acceptable for this agent, this user, this destination and this moment - and that policy must live outside the model. The model can explain, request and propose. It should not be the final authority on whether a high-blast-radius action is allowed. Our MCP security guide covers the same split for MCP servers specifically.

The rule extends to skills. A skill that teaches an agent cloud reconnaissance, incident response or infrastructure migration may be entirely legitimate. If it encourages broad enumeration, expensive provisioning or external communication, it should be scanned and labeled before installation, and the runtime should use that label to demand stronger approvals. Artifact trust and runtime authority have to meet each other.

Practical defenses

The operating rule the incident suggests: never give an agent an uncapped external action surface. Seven controls, in the order they pay off.

1. Least-privilege credentials. Separate accounts or projects for agent workloads. Deny expensive instance families and services by default, restrict regions, require tags, and attach short-lived credentials to a narrow task rather than a general-purpose role.
2. Hard budgets and quotas, set before the run. Alerts are not enough when an agent can spend in minutes; use budget actions that revoke permissions, service quotas that cap resource counts, and automation that tears resources down at a threshold.
3. Separate planning from execution. Let the agent draft the plan, the cost estimate and the PR. Require approval before it creates resources, scans networks, contacts a community or sends messages.
4. Bind tools to destinations. A scanner gets an allowlist. A browser tool gets domain rules. A messaging tool gets recipient rules. “Use the internet” and “use AWS” are not permission scopes.
5. Rate-limit the tool, not the prompt. The DN42 plan was 65,536 probes per host across 1,000-2,000 hosts, hourly. A token bucket in the tool wrapper makes that arithmetic irrelevant.
6. Log the whole path. Skill, plugin, connector, tool call, arguments, policy decision, estimated cost, actual cost, output, approval state. After an incident you need to know whether the failure came from the instruction, the model, the tool, the policy or the operator.
7. Scan the artifacts that shape behavior, then pin and re-review them. Skills, MCP server definitions, plugin manifests, install scripts and connector code all steer an agent. A connector that was safe at install can drift; version pinning plus consumer-side re-scanning keeps trust attached to the artifact that was actually reviewed.

Where SkillSafe fits

SkillSafe treats agent capabilities as supply-chain artifacts. A skill changes what an agent is likely to do. A plugin or MCP server changes what it can reach. A connector changes the systems it can act on. All three need provenance, scanning and verification - and you can check any of them from the skill registry before installing.

DN42 adds a second question to “is this artifact malicious?”:

• What resources can this capability spend?
• What external systems can it touch?
• What communities, users or customers can it contact?
• What rate and destination limits apply?
• What approvals are required before costly actions?
• What evidence will prove which artifact and tool path caused an action?

That evidence belongs in the same governance loop as publisher verification and scan results. A high-risk skill should produce stricter runtime policy. A connector with cloud-write authority should carry budget and quota requirements. An MCP server exposing provisioning or scanning tools should be reviewed like infrastructure automation, not like a chat extension.

The agent did not need a malicious plugin to cost its operator $6,531.30. It needed a broad goal, powerful tools and no enforced parameters.

Frequently Asked Questions

How do you cap what an AI agent can spend on cloud resources?

Outside the model. On AWS that means a budget action that attaches a restrictive IAM policy or stops instances at a threshold, plus Service Quotas limiting how many resources the account can create. The DN42 operator reached $6,531.30 in about 24 hours because the only stated limit lived in the agent’s instructions.

Are MCP servers and agent plugins a security risk?

They are a permission surface. The risk is not only malicious code: a legitimate connector that exposes create_instance or run_scan without parameter policy grants the model authority over cost, destination and rate. Treat every tool schema as a set of arguments that needs an allowlist, and see our MCP security guide for server-side checks.

What is excessive agency in the OWASP LLM Top 10?

LLM06:2025 Excessive Agency covers damage caused by an LLM system having too much functionality, too many permissions or too much autonomy. OWASP’s mitigations are to minimize the extensions and functions an agent can call, avoid open-ended permissions, and require human approval for high-impact actions - precisely the three controls DN42 lacked.

Can a prompt limit an agent’s blast radius?

No. A prompt is an instruction the model can reinterpret when it decides the task requires more, which is what happened when the DN42 agent kept its five-instance cluster running while it argued for approval. Limits only hold when a separate system - IAM, a quota, a rate limiter, an approval gate - can refuse the call.

What should I log when an agent uses tools?

The full path: which skill or MCP server was loaded, the tool name, the arguments, the policy decision, the estimated and actual cost, the output, and whether a human approved. Without arguments and cost you cannot tell an over-eager agent from a poisoned one, and both show up as an unexpected bill.

Related reading: Supply chain posts - MCP security guide - scan a skill before you install it