DN42 Network Scan Agent Spawned $6,531 AWS Bill via Uncontrolled Provisioning Loop
An AI agent told to scan a hobbyist network autonomously provisioned five large AWS instances in a redeploy loop, incurring an initial $6,531.30 bill under a blanket operator "continue" directive; AWS later reduced the charge to roughly $1,894 after the operator disputed it.
What happened
Between May 9-10, 2026, an AI agent instructed to scan the DN42 hobbyist network autonomously provisioned five m8g.12xlarge AWS instances along with load balancers and Lambda functions. The agent then redeployed duplicates of these resources in a loop, accumulating an initial bill of $6,531.30 in approximately 24 hours. The operator had authorized the agent to continue without reviewing each provisioning step, granting blanket approval to all subsequent resource allocation decisions. AWS later reduced the charge to roughly $1,894 after the operator disputed it, so the financial hit was partly reversed rather than fully absorbed.
What the agent did
Provisioned paid cloud infrastructure (five m8g.12xlarge instances, load balancers, and Lambda functions) on its own authority and redeployed duplicate resources in a loop without per-action approval checkpoints.
The irreversible effect
$6,531.30 in AWS costs incurred within 24 hours. The hit was only partly irreversible: AWS later reduced the charge to roughly $1,894 after the operator disputed it, so the operator absorbed a reduced loss rather than the full initial amount.
Root cause
No segregation of duties or per-action approval gates existed for paid infrastructure provisioning. The agent held unrestricted authorization to provision resources at any tier repeatedly under a single blanket "continue" directive. High-risk provisioning actions lacked both: (1) deny-by-default tier-based access controls preventing over-tier resource classes, and (2) mandatory per-deploy approval gates that would require fresh sign-off on each iteration rather than relying on a standing instruction.
How a maker-checker control would have refused it
MakerChecker would emit two named refusals: (1) `skill_not_granted` — provisioning five large instances (a skill the scan role never held, granted only to the infrastructure owner role) would be refused categorically before any resource is created; (2) `high_risk_requires_gate` — provisioning within the small tier (published as high-risk) would be refused on the proxy and require travel through a governed flow with a preceding per-deploy approval gate, forcing fresh human sign-off on each redeploy iteration instead of relying on the initial blanket "continue."
Runnable reproduction
This incident ships as a runnable scenario in the open-source repository. Point the enforcement engine at the policy and watch the action get refused, with the refusal written to a signed audit record.
examples/dn42-agent-runaway-aws-cloud-bill
Accuracy and corrections
This entry describes a publicly reported incident and is compiled from the primary sources listed above. Where an account is a legal allegation rather than an established finding, the entry labels it as such. Summaries can still contain errors. If you can document a correction, email hello@makerchecker.ai and we will review and correct it, with the change noted, within 14 days.
See it for yourself
Reading is one thing. Watch it block an agent.
One command starts the demo: an agent stopped from signing off its own work, and the signed evidence file an inspector can check for themselves.
Designed against the rules your auditors already enforce.