DEV Community

Pirt
Pirt

Posted on

5 AI Agent Mistakes That Can Destroy Your Production Database (And How to Fix Them)

#devops #database #ai #productivity

"Hey AI, clean up the database."

Seconds later: DROP TABLE users;

Sound familiar? If you are using AI agents like Cursor, Claude, or GitHub Copilot in your workflow, this nightmare is one careless prompt away.

After building MCP Guard and talking to 50+ developers, I found the 5 most common AI agent mistakes that can wreck your production systems.

Mistake #1: Vague Prompts That AI Interprets Literally

What you say: "Clean up the unused files"

What AI does: rm -rf /tmp/* or worse, rm -rf ./

The fix: Always specify what to clean:

# ❌ Bad
Clean up unused files

# ✅ Good
List files in /tmp older than 7 days. Show me the list first before deleting anything.
Enter fullscreen mode Exit fullscreen mode

Rule: Never give destructive access without a preview step.

Mistake #2: Running AI Without a Sandbox

The problem: AI agents run with YOUR permissions. Your terminal. Your database. Your production.

Real story: A developer asked Claude to "optimize the database." It ran ANALYZE on a production PostgreSQL database during peak hours. Query latency spiked 10x. Users experienced 30-second page loads.

The fix:

# Always use read-only database connections for AI
DATABASE_URL=postgresql://user:pass@host:5432/db?options=--default_transaction_read_only=on
Enter fullscreen mode Exit fullscreen mode

Or use Docker sandboxing:

docker run --rm -v $(pwd):/workspace python:3.11 \
  python /workspace/ai_script.py
Enter fullscreen mode Exit fullscreen mode

Mistake #3: Trusting AI-Generated Migrations

AI generates a migration. Looks clean. You run it.

ALTER TABLE users DROP COLUMN email;
Enter fullscreen mode Exit fullscreen mode

Wait — email was used by 47 API endpoints. 💀

The fix:

  1. Always review migrations manually
  2. Run EXPLAIN on destructive queries first
  3. Use migration dry-run mode: 
# Rails example
rails db:migrate --dry-run

# Prisma example  
npx prisma migrate diff --from-schema-datamodel prisma/schema.prisma --to-schema-datamodel prisma/schema.prisma
Enter fullscreen mode Exit fullscreen mode

Mistake #4: No Audit Trail for AI Actions

When AI runs 50 commands in 10 seconds, how do you know what happened?

The fix: Log everything.

{
  "timestamp": "2025-01-15T10:30:00Z",
  "agent": "cursor-claude",
  "command": "DELETE FROM sessions WHERE expired_at < NOW() - INTERVAL 30 DAY",
  "status": "blocked",
  "reason": "DELETE without WHERE clause safety check"
}
Enter fullscreen mode Exit fullscreen mode

Tools that help:

  • MCP Guard — real-time AI command monitoring
  • script command — terminal session recording
  • Custom shell wrappers with logging

Mistake #5: No Rollback Plan

AI drops a table. You panic. No backup. No rollback script.

The fix: Before letting AI touch anything:

# 1. Create a safety backup
pg_dump mydb > backup_$(date +%Y%m%d_%H%M%S).sql

# 2. Use transactions
BEGIN;
-- AI runs queries here
-- If something looks wrong:
ROLLBACK;
-- If everything looks good:
COMMIT;
Enter fullscreen mode Exit fullscreen mode

Golden rule: If you cannot undo it in 30 seconds, do not let AI do it.

Quick Checklist Before Running AI in Production

  • [ ] Sandbox or containerized environment?
  • [ ] Read-only database connection?
  • [ ] Command logging enabled?
  • [ ] Backup created?
  • [ ] Review step before destructive operations?

If any answer is NO, stop and fix it first.

The Bigger Picture

AI agents are not going away. They are getting more powerful every month. The question is not whether to use them — it is how to use them safely.

The developers who build safety nets now will ship faster later. The ones who do not will spend their weekends recovering databases.

Build the guardrails before you need them.

What is your worst AI agent horror story? Drop it in the comments 👇

If this helped, follow me for more practical AI safety content. Next week: Building a real-time AI monitoring dashboard in 30 minutes.

Top comments (0)