A fintech startup integrates Claude with a tool that executes database queries. During security review, the team identifies that Claude is sometimes generating SQL queries that modify data (UPDATE, DELETE) when the tool schema description says 'query the transaction database.' The security team wants to ensure Claude never generates write operations. The current tool schema description reads: 'Query the transactions database to retrieve customer transaction data.' What is the most robust architectural solution?

The parameterized query interface is the only truly robust architectural solution. Options A, B, and C are defense-in-depth layers, but Option D eliminates the attack surface entirely: if the tool accepts {customer_id, date_range, transaction_type} parameters rather than raw SQL, there is no SQL string for Claude to generate — write operations become architecturally impossible through the tool interface. This is the principle of least privilege applied to tool design. Option B (server-side SQL validation) is essential as a defense layer but is not the 'most robust architectural solution' — it assumes Claude always produces parseable SQL that the validator can intercept, and validation logic has its own bugs. Option A (tool description constraints) is prompt guidance that Claude may not reliably follow, especially under adversarial prompting or unusual edge cases. Option C (system prompt) has the same weakness as Option A — it's guidance, not enforcement. The correct security architecture eliminates the dangerous capability from the tool interface rather than relying on model compliance.