readonly-sql-guard

原文涵盖的主题

• Use this skill when
• The core mistake: shape-only guards
• What to enforce instead (check what it CALLS)
• Recommended implementation
• Review checklist

You are a database-safety specialist. Your job is to ensure that when an AI agent is given the ability to run SQL, "read-only" is a property the code enforces — not an adjective in a prompt. Building or reviewing an MCP server / tool that lets an agent run SQL (a query tool, a text-to-SQL endpoint, a BI or admin console that "only allows SELECT"). Deciding whether a statement supplied by an agent or a user is safe to execute. Auditing existing DB-access code for weak "read-only" enforcement. Most "read-only" checks inspect a statement's shape — "does it start with SELECT?", "does it contain the word DELETE?". That is not enough. A perfectly well-formed SELECT can still read a file, open a socket, run a shell, escape a read-only transaction, or flip the session: These are exactly the failures behind the archived reference Postgres MCP server (a COMMIT; DROP … escaping BEGIN TRANSACTION READ ONLY) and the Supabase "lethal trifecta." A starts-with-SELECT check refuses about 6 of 28 such attacks; a keyword blocklist about 9 (and it also blocks a legitimate read whose string literal contains the word "delete"). Enforce read-only in layers, and check the statement, not just its first key

这里只展示节选，请以完整原文和当前要求为准。