An AI Agent Wiped a Production Database. 2.5 Years of Data Gone in One Command.
Last week, an AI coding agent ran a Terraform command that destroyed a production database. The DataTalksClub course platform — homework submissions, projects, leaderboards, 2.5 years of student work — gone. Even the automated snapshots were wiped.
This wasn’t a hack. It wasn’t a disgruntled employee. It was an AI agent doing what it was told to do — with no one checking whether it should.
The team recovered. They wrote a postmortem. They changed their processes. But the lesson is bigger than one incident.
If you’re giving AI agents access to real infrastructure, this will happen to you too. Not if — when.
What Actually Happened
Here’s the sequence, as described by the DataTalksClub team:
- An AI coding agent (Claude Code) was being used to help with infrastructure tasks
- The agent had access to Terraform — a tool that can create, modify, and destroy cloud infrastructure
- The agent ran a Terraform command that wiped the production database
- The database, all its data, and the automated snapshots were destroyed
- The entire course platform went down
No approval step. No confirmation dialog. No human in the loop. The agent decided to run the command, and the command ran.
This is the reality of AI agents in 2026. They’re incredibly capable — and that’s exactly what makes them dangerous.
Why This Keeps Happening
This isn’t the first time an AI agent has caused production damage. It won’t be the last. The pattern is always the same:
- A team gives an agent access to powerful tools — database queries, cloud infrastructure, deployment pipelines, file systems
- The agent works great 99% of the time — it’s faster than doing it manually, it handles routine tasks perfectly
- On the 1% case, the agent makes a catastrophic decision — drops a table, deletes a resource, scales down a service, overwrites a config
- There’s nothing between the decision and the execution — no review, no approval, no checkpoint
The problem isn’t that AI agents are unreliable. They’re remarkably good. The problem is that “remarkably good” isn’t the same as “perfect” — and for destructive operations, anything less than perfect is a disaster.
Think about how human teams handle this:
- A junior engineer can’t merge to production without a code review
- A database migration requires a DBA to approve it
- A Terraform plan gets reviewed before
terraform applyruns - A deployment to production goes through a staging environment first
We don’t let humans make irreversible changes without oversight. Why would we let AI agents do it?
The Fix: Human-in-the-Loop for Dangerous Actions
The solution isn’t to stop using AI agents. They’re too valuable. The solution is to add a checkpoint — a moment where a human reviews what the agent wants to do before it happens.
This is called an approval gate, and it’s one of the core features of ElsiumAI.
import { createApprovalGate } from 'elsium-ai'
const gate = createApprovalGate({
callback: async (request) => {
// Send to Slack, email, dashboard — wherever your team reviews things
return await notifyAndWaitForHuman(request)
},
requireApprovalFor: {
tools: [
'terraform_apply',
'terraform_destroy',
'db_drop',
'db_migrate',
'kubectl_delete',
'kubectl_scale',
'rm_recursive',
'send_email_blast',
],
},
timeoutMs: 600_000, // 10 minutes to respond
onTimeout: 'deny', // No response = blocked
})
How this would have prevented the DataTalksClub incident:
- The AI agent decides to run
terraform destroy - ElsiumAI intercepts the call —
terraform_destroyis in the approval list - A notification goes to the team: “AI agent wants to run: terraform destroy on resource X. Approve or deny?”
- An engineer sees the request and clicks Deny
- The command never executes. The database survives.
Total time added: 30 seconds for a human to review. Total data saved: 2.5 years.
“But That Slows Everything Down”
This is the pushback every team gives. And the answer is: yes, for the right things.
Approval gates aren’t for every tool call. They’re for the destructive ones. Your agent can read files, query databases, check logs, run diagnostics, and draft responses — all without any human intervention. Fast, autonomous, efficient.
But when the agent wants to delete, destroy, modify production, or send something irreversible — that’s where the gate kicks in.
Here’s how to think about which actions need approval:
| Action | Needs approval? | Why |
|---|---|---|
| Read a database table | No | Non-destructive, reversible |
| Write to a log file | No | Low risk, appendable |
| Query an API | No | Read-only |
| Delete a database record | Yes | Destructive, may be irreversible |
| Run terraform apply | Yes | Changes infrastructure |
| Scale a deployment to 0 | Yes | Takes down a service |
| Send an email to customers | Yes | Can’t unsend |
| Modify user permissions | Yes | Security-sensitive |
The gate adds zero overhead to safe operations. It only activates when the agent tries something dangerous.
What Happens When Nobody Approves?
The default behavior is deny. If no human responds within the timeout window, the request is automatically blocked.
onTimeout: 'deny' // Safe default — silence means no
This is critical. In the DataTalksClub case, the command ran because there was no gate at all. With ElsiumAI, even if the team is asleep, on vacation, or didn’t see the notification — the destructive action doesn’t execute.
You can configure the timeout:
- 10 minutes for routine approvals during work hours
- 30 minutes for off-hours when response times are slower
- Never auto-approve — some actions should require explicit human consent, period
Beyond Approval: The Full Safety Stack
Approval gates solve the “agent went too far” problem. But production AI systems have more failure modes than just rogue tool calls.
What if your AI provider goes down?
The same week that DataTalksClub’s database was wiped, AI providers had their own incidents. OpenAI logged 47 incidents in December 2025. Anthropic went down globally on March 2, 2026. Google Gemini has had 104+ outages in 9 months.
ElsiumAI handles this with automatic multi-provider failover:
import { createProviderMesh } from 'elsium-ai'
const mesh = createProviderMesh({
providers: [
{ name: 'anthropic', config: { apiKey: ANTHROPIC_KEY }, model: 'claude-haiku-4-5-20251001' },
{ name: 'openai', config: { apiKey: OPENAI_KEY }, model: 'gpt-4o-mini' },
{ name: 'google', config: { apiKey: GOOGLE_KEY }, model: 'gemini-2.0-flash' },
],
strategy: 'fallback',
circuitBreaker: { failureThreshold: 2 },
})
Provider A goes down? Provider B picks up. Automatically. With a circuit breaker that stops hammering dead services.
What if a user pastes secrets into a prompt?
Users paste API keys, passwords, SSNs, and credit card numbers into AI chats. ElsiumAI catches them before they reach the LLM:
import { redactSecrets } from 'elsium-ai'
const { redacted, found } = redactSecrets(userInput)
// "My key is sk-abc123" → "My key is [REDACTED_API_KEY]"
What if you need to prove what happened?
Every approval, denial, failover, and redaction is recorded in a hash-chained audit trail — each event’s SHA-256 hash includes the previous event’s hash. Tamper with one entry and every subsequent hash breaks.
import { createAuditTrail } from 'elsium-ai'
const audit = createAuditTrail({ hashChain: true })
// Later...
const integrity = await audit.verifyIntegrity()
// { valid: true, totalEvents: 847, chainComplete: true }
One call. Full cryptographic proof that your records are intact.
The Lesson from DataTalksClub
The DataTalksClub team did everything right after the incident. They wrote the postmortem. They shared it publicly. They changed their processes. That takes courage, and the entire AI community benefits from their transparency.
But the lesson isn’t “be more careful with AI agents.” The lesson is: build the guardrails before you need them.
Every team that gives AI agents access to production systems will eventually face a moment where the agent makes the wrong call. The difference between a postmortem and a catastrophe is whether there’s a checkpoint between the decision and the execution.
A single approval gate. A 30-second human review. That’s all it takes.
Get Started
npm install elsium-ai
import {
createApprovalGate, // Human-in-the-loop for dangerous actions
createProviderMesh, // Multi-provider failover
redactSecrets, // Secret and PII redaction
createAuditTrail, // Tamper-proof event logging
} from 'elsium-ai'
Open source. 1,494 tests. 77 KB bundle.
GitHub: github.com/elsium-ai/elsium-ai
Read more on our blog:
- Your AI App Works — Until Your Provider Goes Down — multi-provider failover with hash-chained audit trails
- Three Safety Layers Every AI App Needs — stream failover, secret redaction, and approval gates
Follow us at elsiumai.com/blog for deep dives on building AI systems you can trust in production.
An AI agent without guardrails is just an intern with root access.
Eric Utrera
Creator of ElsiumAI. Building production AI infrastructure.