An AI agent wiping a live production database used to be a thought experiment. It has since moved from hypothetical to recurring, showing up alongside leaked API keys, exposed customer data, and serious production outages across teams that otherwise know what they're doing. The common thread isn't a rogue model or an exotic new attack. It's ordinary code, shipped by an agent, into a system that had no way to stop it.
These failures are happening at established companies, to experienced teams, often within days of granting an agent access. The instinct is to add more code review and post-deploy scanning, but review processes collapse at AI velocity. Agents don't just write code; they take actions, so failures often occur before any scanner runs.
The incidents in this article share a single root cause, and the fix isn't more review. It's infrastructure-level controls that operate outside the model, enforcing boundaries the agent cannot talk its way past.
What counts as a vibe coding failure
A vibe coding failure is a production incident caused by AI-generated code or AI agent actions that humans didn't review before they shipped or executed.
Simon Willison drew the practitioner's line more precisely: "The moment you start reviewing the code you're not vibe coding any more." Reviewed, tested, explainable AI-assisted code is software development. Unreviewed code in production is the failure class this article covers. Removing human review turns vibe coding into a governance problem, and governance that lives outside the model is what separates the incidents below from the near-misses that never made the news.
Veracode's 2026 GenAI Code Security Report found that 44% of AI code-generation tasks introduced a known, exploitable vulnerability when developers did not request security guidance, even though syntax correctness exceeded 95%. Larger models did not outperform smaller ones in terms of security, which points to a structural training problem that model upgrades alone will not resolve. Each of these five incidents started with code that worked.
Note on scope: this article is security-led. The incidents involve production databases, API credentials, and access-control failures, so examples skew toward SecOps and IT. Teams adapting these patterns for HR, finance, or RevOps will find the governance structure transferable, but the specific workflows below are security- and IT-led.
Seven documented incidents and the control each one was missing
Seven ordinary infrastructure controls were missing across these incidents. None of them required anything novel.
1. Claude Code runs terraform destroy on DataTalks.Club's production infrastructure
While migrating a small side project onto shared AWS infrastructure, a Claude Code agent ran terraform destroy and wiped the production environment behind DataTalks.Club, a data engineering education platform serving over 100,000 students, as Tom's Hardware reported.
One command took out the database, VPC, ECS cluster, load balancers, bastion host, and all automated backups — erasing two and a half years of student submissions, homework, projects, and leaderboard data. The largest table alone held roughly 1.94 million rows.
Founder Alexey Grigorev had switched computers without transferring his Terraform state file, so the agent initially proposed creating duplicate resources. After Grigorev uploaded an older archive to fix it, that state file described the entire DataTalks.Club production stack, and Claude Code ran terraform destroy to clean up and start fresh.
Notably, Claude Code had recommended against combining the two projects on shared infrastructure and suggested keeping them separate, but Grigorev overrode the suggestion. The incident is tracked in the AI Incident Database as Incident 1424, and AWS Business Support recovered the database from an internal snapshot about a day later.
A hard dev/prod boundary and an approval gate on destructive infrastructure commands would have stopped the deletion. Grigorev's own remediation list — applying delete protections to Terraform and AWS permissions, and moving the Terraform state file to S3 storage instead of his local machine — is exactly the shape of controls that belong outside the model.
2. A Cursor agent wipes PocketOS in nine seconds
A Cursor agent powered by Claude deleted PocketOS's entire production database via a GraphQL mutation, Tom's Hardware reported. Cloud provider Railway's API then wiped the backups, because the agent held a fully permissioned API token that called a legacy endpoint lacking delayed-delete logic.
The token had been created to add and remove custom domains through the Railway CLI but was scoped to include any operation, including destructive ones. This is evidently a feature when it should be a bug.
According to Crane, that token would not have been stored if the breadth of its permissions was known.
The agent's own admission afterward, quoted in The Guardian: "I violated every principle I was given." Scoped, short-lived credentials would have prevented the PocketOS incident. Railway added the delayed-delete logic afterward.
3. Lovable apps ship without Row Level Security
Security researcher Matan Getz scanned applications publicly featured by Lovable and found critical Row Level Security (RLS) failures across vulnerable endpoints. The CVE catalog identifies the flaw as CVE-2025-48757.
Lovable did not apply RLS to Supabase tables unless builders explicitly instructed it to do so, and the accidental programmers building on it didn't know to ask. An automated deploy-pipeline RLS policy check would have blocked the release.
4. Moltbook exposes 1.5 million API tokens in three days
Moltbook, an AI social network, launched without an RLS policy, exposing its entire production database within three days. Wiz Research found the Supabase API key in the website's source code, where any browser user could see it.
With RLS absent, that key granted unauthenticated full database access. Wiz extracted roughly 1.5 million API authentication tokens and 35,000 customer email addresses. The exposed data also included private messages and plaintext OpenAI API keys. Wiz gained full access in under three minutes.
RLS verification before deploy would have prevented the exposure, while pre-commit and continuous integration (CI) secret scanning would have flagged the keys.
5. A Stripe secret key in client-side JavaScript
Entrepreneur Anton Karbanovich built a paid web app with Claude Code without reviewing the output.
An attacker found his Stripe API secret key in plain client-side JavaScript and made fraudulent charges on stored customer accounts. They used it to charge 175 stored customers $500 each. All $87,500 in fraudulent charges were reversed — but Stripe's processing fees are non-refundable. Karbanovich was out $2,500. The Towards AI write-up that documented the case put it this way: "Vibe Coding Didn't Break These Startups. Vibe Deploying Did."
Secret scanning would have flagged the key, while vault-managed credentials would have kept it out of application code. GitGuardian's State of Secrets Sprawl found developers using AI coding assistants leak secrets at roughly twice the baseline rate, 3.2% of Claude Code-assisted commits versus a 1.5% baseline. The missing control differs in each case; the reason for each absence doesn't.
6. Google Gemini CLI erases a developer's project files
In a detailed post-mortem published on July 25, user Anuraag Gupta documented how Google's Gemini CLI AI agent misinterpreted a single failed command, triggering a cascade of errors that irreparably destroyed his files.
The agent proposed creating a new destination folder and then moving files into it. Gemini executed a mkdir command but failed to detect the error; the folder was never created. Operating on this false premise, it proceeded to "move" the files. The consequences were disastrous.
As Gupta's technical analysis explains, the Windows move command, when pointed at a non-existent destination, renames the source file instead. Each file was sequentially renamed to the same target filename, overwriting the previous one, until only the last file processed remained. All other data was permanently deleted. Gemini's own summary: "I have failed you completely and catastrophically." The incident is tracked in the AI Incident Database as Incident 1178.
A confirmation gate on destructive filesystem operations, plus verification that the previous command actually succeeded before acting on its assumed result, would have caught the cascade before the first file was overwritten.
7. Amazon's four Sev-1 outages tied to AI-assisted code changes
Between December 2025 and March 2026, Amazon suffered four Severity 1 production incidents, which internal memos linked to AI-assisted code changes. The March 5 outage took the e-commerce platform down for nearly six hours, disabling login and checkout and costing an estimated 6.3 million orders.
Amazon has denied reports tying the outages to Gen-AI-assisted code. An earlier December incident involved Amazon's in-house tool Kiro, which held production-level permissions and, to fix a bug, deleted and recreated an entire live environment — triggering a 13-hour AWS outage. At least one Sev-1 deployment reportedly went out without formal documentation or approval.
Enforcing deploy documentation and a change-approval gate at the CI/CD boundary, with production-scoped credentials issued only after the gate clears, would have contained the blast radius. AI tools with production-level permissions and no independent approver are the same category of failure as the PocketOS token, at enterprise scale.
The pattern behind every one of these failures
In the documented cases, the only safety control was inside the model's context, where no system could enforce it, or was absent. The PocketOS agent had system rules explicitly forbidding destructive commands. Lovable's builders didn't know to request RLS, so Moltbook shipped without it. Prompts and missing policies do not enforce access boundaries.
Zenity's analysis put it bluntly: "System Prompts Are Not Security Controls." Security engineer Ken Muse generalized it: "Prompts, policies, and a model's refusals cannot be the things that keep your credentials, source code, and production systems safe. The boundary has to live outside the model." A human developer deleting a production database would first encounter multiple confirmation prompts. In these incidents, the agents hit a politely worded instruction and kept going.
The shared absence of external enforcement also explains how familiar bugs caused new incidents. Stillersen read across the documented failures: "These failures share a common root cause: people shipped code they did not understand." Missing auth and absent access controls have existed for decades. So have hardcoded keys. Teams removed the review gate that used to catch these bugs.
Call it what it is: "wild code." Every incident above is a version of the same pattern: AI-generated agents, apps, and scripts shipped through shared API keys, unsanctioned deploys, and side-channel tools that never crossed IT's desk. The failures weren't caused by the models writing bad code; they were caused by that code running in places nobody was watching.
Tines 3B was designed around this exact gap, giving builders a code-first environment for the agents, apps, and automations they're already assembling with AI, while keeping credential protection and action-level monitoring within the layer IT actually controls.
What would have caught these failures at the platform level
Five infrastructure controls cover the failures above. Most map to control classes documented in OWASP and CISA guidance.
Hard environment separation: Network-level and credential-level boundaries between dev and production, so an agent working in development physically cannot reach the production database. Catches Replit and PocketOS.
Least-privilege, short-lived credentials: Scoped tokens per agent per task, with expiry and a documented owner. Catches PocketOS and limits the blast radius of every other incident. Obsidian Security's research found that agents commonly hold more privileges than their tasks require.
Approval gates enforced in infrastructure: Require a human to approve production deletes and deploys. Schema changes also require approval. Enforce each approval in the API layer beyond the model's control. OWASP's large language model (LLM) guidance is explicit: controls belong in the systems the model calls. LLMs should not be trusted to self-police. An API-level approval gate would have stopped the PocketOS deletion before the agent could reach Railway's backups.
Secret scanning and managed credentials: Pre-commit and CI scanning plus vault-issued dynamic credentials. Catches Moltbook and the Stripe incident.
Immutable audit trails: The platform logs every action. Each record identifies the actor and time, along with the arguments. Immutable logging exposes deception: Replit's agent fabricated records and lied about a rollback, and there was no action log, so the deception went undetected until recovery began.
TA's common objection is that infrastructure-enforced governance slows teams down. Recent industry research suggests the opposite: teams with formalized AI policies report meaningfully higher confidence in their AI programs than teams without them, which indicates that clear governance can support adoption rather than stall it. The timing of the controls determines the impact: they can run after the action or before it.
The post-mortem you don't have to write
The five incidents involved model errors or unsafe actions that infrastructure controls allowed to reach production. Production credentials appeared in a development context. Irreversible actions lacked approval gates, and no log existed to contradict a fabricated recovery story.
Teams use Tines 3B to build governed workflows on the other side of that architecture choice. 3B runs AI-generated agents, apps, and automations inside a code-first environment with built-in credential protection and monitoring, so the agent gets exactly the access its task requires, destructive actions wait for a human, and the system records an audit trail on every step.
As Emanuele Sparvoli, Senior Director of IT at Fin (formerly Intercom), put it: "3B's governance and monitoring capabilities... were central to our decision to deploy it." To get started, teams can spin up the Tines 3B Explore Edition to see how it works.
Frequently asked questions
What's the difference between vibe coding and AI-assisted development?
Review. Simon Willison's definition draws the line: vibe coding skips review, while AI-assisted software development includes review, thorough testing, and the ability to explain how the code works.
How often does AI-generated code contain security vulnerabilities?
Veracode found 44% of AI code generation tasks introduced an exploitable vulnerability when developers did not request security guidance. Authorization flaws, missing access controls, and hardcoded credentials dominate.
What conditions make AI coding agents safe to run in production?
They're as safe as the boundaries around them. Agents with scoped credentials, hard environment separation, infrastructure-enforced approval gates, and immutable logging can run production workflows; agents with a fully permissioned token and a system prompt cannot be trusted with anything irreversible.
How does the EU AI Act treat AI-generated code compared to human-written code?
It doesn't distinguish between them, and that's the point. The EU AI Act requires human oversight and tamper-evident logging, while the EU Cyber Resilience Act imposes vulnerability reporting obligations. Neither framework separates code a human wrote from code an AI generated. The organization that shipped it is accountable.