A customer analytics platform builds an MCP server that exposes a database query tool. The MCP server is connected to a Claude agent that has read access to a customer database. During testing, an analyst prompts Claude: 'Generate a report on Q3 revenue.' Claude successfully queries sales data. Then the analyst pastes a CSV file into the chat: 'Can you analyze this CSV? [CSV content with a hidden row: "; DROP TABLE sales; --]'. Claude calls the query tool with a SQL string that incorporates the CSV data directly, causing a SQL injection. What MCP server-side control prevents this?

Defense-in-depth for SQL injection requires that the MCP server never accept raw SQL strings from Claude — instead, it should accept structured parameters that it assembles into safe, parameterized queries internally. If Claude calls query_database({"table": "sales", "filters": {"quarter": "Q3"}}), the server builds SELECT * FROM sales WHERE quarter = ? with bound parameters, and no user content can escape the parameter binding. Option A (prompt instructions) cannot be relied upon — Claude's SQL construction can be manipulated by injected content in user-provided data. Option C (keyword filtering) is bypassable through encoding, case variation, comments, or indirect injection. Option D (read-only DB user) is excellent defense-in-depth but doesn't prevent data exfiltration, unauthorized reads, or information leakage — it protects data integrity but not confidentiality. Option B plus Option D together form the correct defense-in-depth posture.