An AI agent running in Cursor deleted a production database yesterday. Claude Opus 4.6, working through Railway's API, made a GraphQL call to delete a volume and took all the backups with it. Railway stores volume-level backups inside the same volume, so there was nothing to recover.
The HN thread hit 181 points and 240 comments. Most of them are arguing about model trust, human oversight, and AI safety. That's the wrong argument.
The agent had admin-level API credentials. No environment scoping. Keys meant for development could hit production. When the agent decided to clean up a volume, nothing in the infrastructure asked whether it should be allowed to do that in production.
That's not a model failure. The model did what it was asked.
Every agentic setup defaults to admin
Add an MCP server to your Claude Desktop config. That server runs as you: your filesystem, your shell, your credentials. Nobody scoped it down. Nobody audited what it can actually reach.
We scanned 12 popular MCP servers with agent-audit and found 58 security findings across all 12 repos. 100% finding rate. 12 critical, 17 high. The most common issue: command execution that passes input directly from AI tool calls into shell commands.
exec(`git commit -m "${commitMsg}"`);
// commitMsg came from an AI agent, which got it from a user prompt
That's a direct prompt-to-shell pipeline. The Railway incident is the same logic one level up: no shell injection, but the agent received a task, made API calls, and nothing asked "should you be allowed to delete production volumes?"
What scoped access looks like
Separate keys for dev and production. Read-only where writes aren't needed. Deletion endpoints that require confirmation outside the agent loop.
For MCP servers: each server should have access to exactly what it needs. A documentation server doesn't need shell access. A code review tool doesn't need database credentials. These seem obvious when stated plainly, but nobody enforces them by default.
agent-audit scans your MCP config and source code for these holes before they become incidents. Hardcoded credentials, command injection paths, excessive permission grants, prompt injection in tool descriptions. Runs in about 30 seconds:
npx @piiiico/agent-audit --auto
It auto-detects your Claude Desktop config, clones the server repos, and reports what's exposed. Full scan report: FINDINGS.md. npm: @piiiico/agent-audit.
The part nobody wants to say
The Railway incident will be repeated. Not because AI is dangerous, but because the default configuration for every agentic workflow is admin access to everything. One incident won't change the default.
This gets fixed when scoped credentials become the norm, not the exception. Until then, you can at least know what access your own agents have.
For teams wanting hosted agent security monitoring: getcommit.dev.
Read next: How we solved this → Authenticating AI Agents Without Shared Secrets
Top comments (0)