The coding agent never holds production credentials
An agent with a production database URL will, sooner or later, run a migration, a cleanup, or a "fix" against it. Replit's agent deleted 1,206 executive records during a declared code freeze. PocketOS lost its database and its volume backups in nine seconds; the newest usable backup was three months old. A support ticket made a Supabase-MCP agent dump integration_tokens as service_role.
Where it bit
Ours: headless Claude on a root VPS with --dangerously-skip-permissions. The CLI refuses to run that way under root, and the first attempt hung on a permission prompt nobody could see. The fix that mattered was not the root check. It was giving the audit path zero tools and the screenshot judge exactly one, Read.
The practice
Agents get a dev project or a branch, read_only=true on the MCP, and prod secrets never enter their env. Destructive commands need a confirm gate that is not the agent. The permission is the tool list, not the instruction text.
Check it
grep -rn "project_ref\|DATABASE_URL\|service_role" .mcp.json .claude/ .cursor/ 2>/dev/null # any prod ref here is the agent holding prod
Get this check as a script you can run tonight
What to do with this
If you run a business on something AI built and the checks came back with more than you expected, that is worth a conversation.
We do a free 30-minute Health Check for service businesses that want to know exactly where their biggest leaks are. No slide deck. No pitch. We ask questions, find the gaps, and tell you what we see. If there is no obvious fix, we will tell you that too.
Blinkz finds what is broken in how a business runs, then fixes it. AI only where it earns its place.