{"slug": "your-ai-agent-can-run-drop-table-on-production", "title": "Your AI Agent Can Run DROP TABLE on Production", "summary": "A developer warns that the PostgreSQL MCP server exposes a single 'query' tool that executes raw SQL, allowing AI agents to run destructive commands like DROP TABLE or DELETE without a WHERE clause, despite being described as read-only. The developer introduces Intercept, a rate-limiting proxy that caps queries to 30 per minute to prevent runaway agents from causing catastrophic damage. The tool acts as a circuit breaker, blocking the 31st query in a minute to buy time for intervention.", "body_md": "Your AI agent just ran `DELETE FROM users`\n\nwithout a `WHERE`\n\nclause. It was trying to remove a single test account, hallucinated the query, and wiped your entire users table. No confirmation prompt, no rollback, no undo. Production is down and your backup is from last Tuesday.\n\nThis is not a contrived scenario. The [PostgreSQL MCP server](https://github.com/modelcontextprotocol/servers/tree/main/src/postgres) gives AI agents exactly one tool — and that one tool is enough to destroy everything.\n\nMost MCP servers expose a handful of scoped tools. The PostgreSQL server exposes just one: `query`\n\n. It executes raw SQL against your connected database. That means `SELECT`\n\n, `INSERT`\n\n, `UPDATE`\n\n, `DELETE`\n\n, `DROP TABLE`\n\n, `ALTER`\n\n, `TRUNCATE`\n\n— whatever the database user has permission to run.\n\nThe server's README describes the tool as executing \"read-only SQL queries.\" In practice, nothing in the MCP layer enforces that. If the database connection has write permissions — and it usually does — the agent can write. Or delete. Or drop.\n\nA single hallucinated query in a tight agentic loop can fire dozens of destructive statements before you even notice. As we explored in [What Happens When Your AI Agent Goes Rogue](https://policylayer.com/blog/ai-agent-goes-rogue), the damage from an unconstrained agent compounds fast. And with raw SQL access, \"fast\" means milliseconds.\n\nYou cannot stop the agent from generating bad SQL. But you can limit how many queries it fires per minute, buying you time to catch a runaway loop before it does real damage.\n\n[Intercept](https://github.com/policylayer/intercept) sits between your agent and the PostgreSQL MCP server. Every `tools/call`\n\nis evaluated against a YAML policy before it reaches the database. Here is the full policy:\n\n```\nversion: \"1\"\ndescription: \"Policy for modelcontextprotocol/server-postgres\"\ndefault: \"allow\"\ntools:\n    query:\n        rules:\n          - name: \"query-rate-limit\"\n            rate_limit: \"30/minute\"\n            on_deny: \"Rate limit: max 30 queries per minute — wait before retrying\"\n\n    \"*\":\n        rules:\n          - name: \"global-rate-limit\"\n            rate_limit: \"60/minute\"\n            on_deny: \"Global rate limit: max 60 tool calls per minute across all PostgreSQL tools\"\n```\n\nThe `query`\n\ntool is capped at 30 calls per minute. A global rate limit of 60 per minute catches any future tools the server might add. When the agent hits either limit, it receives the `on_deny`\n\nmessage as the tool response — a clear signal to stop, not a silent failure.\n\nThirty queries per minute is generous for most agent workflows. A data analysis agent pulling reports will rarely hit it. But a malfunctioning agent stuck in a retry loop absolutely will — and that is the point. The rate limit acts as a circuit breaker, stopping the cascade before query 31 lands.\n\nThe `rate_limit`\n\nshorthand expands internally to a stateful counter that resets at the start of each calendar-aligned UTC window. No tokens to configure, no middleware to write. For the full mechanism, see [Rate Limiting MCP Tool Calls](https://policylayer.com/blog/rate-limiting-mcp-tool-calls).\n\nInstall Intercept and point it at the PostgreSQL MCP server:\n\n```\nnpm install -g @policylayer/intercept\n```\n\nThen run it with the policy:\n\n```\nintercept -c postgres.yaml -- npx -y @modelcontextprotocol/server-postgres $DATABASE_URL\n```\n\nEvery query from your agent now passes through the policy engine. Query number 31 in a minute gets blocked. Your tables stay intact.\n\nRate limiting is a starting point, not a complete solution. Pair it with a read-only database user where possible, and keep your backups current. But when the agent inevitably hallucinates a destructive query, you will be glad the rate limit caught the loop on iteration 30 instead of iteration 3,000.", "url": "https://wpnews.pro/news/your-ai-agent-can-run-drop-table-on-production", "canonical_source": "https://dev.to/policylayer/your-ai-agent-can-run-drop-table-on-production-eko", "published_at": "2026-06-16 13:21:45+00:00", "updated_at": "2026-06-16 13:48:05.347125+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "developer-tools", "large-language-models", "ai-infrastructure"], "entities": ["PostgreSQL MCP server", "Intercept", "PolicyLayer", "modelcontextprotocol", "YAML"], "alternates": {"html": "https://wpnews.pro/news/your-ai-agent-can-run-drop-table-on-production", "markdown": "https://wpnews.pro/news/your-ai-agent-can-run-drop-table-on-production.md", "text": "https://wpnews.pro/news/your-ai-agent-can-run-drop-table-on-production.txt", "jsonld": "https://wpnews.pro/news/your-ai-agent-can-run-drop-table-on-production.jsonld"}}