SQL Injection Prevention Prompt for Database Tools

This prompt is designed for integration developers building agent-to-database gateways. It acts as a pre-execution validation layer that sits between an AI agent's generated SQL and the database driver. Use it when an agent has permission to construct data retrieval or modification queries, and you need to enforce parameterization, block dangerous patterns, and validate query structure before execution. This prompt does not replace prepared statements at the driver level; it is a defense-in-depth layer that catches injection attempts before they reach the database.

The ideal user is a platform engineer or backend developer who has already built the agent's tool-use loop and the database connection pool. You should have a defined schema context—table names, column types, and permitted operations—that you can inject into the prompt via the [SCHEMA_CONTEXT] placeholder. The prompt expects the raw SQL string the agent produced, the intended operation type (SELECT, INSERT, UPDATE, DELETE), and any parameterization metadata the agent claims to have used. It returns a structured validation decision: pass, block, or rewrite. A rewrite result includes a corrected, parameterized query when the original intent is salvageable.

Do not use this prompt as the sole security control for user-facing SQL input or for systems where the agent must generate DDL, stored procedures, or administrative commands. It is not designed to validate multi-statement batches, dynamic schema modifications, or vendor-specific extensions like COPY or MERGE. For those cases, you need a sandboxed execution environment with read-only replicas and statement-level allowlists. This prompt is also not a replacement for database-level permissions, network segmentation, or query logging. Treat it as one layer in a defense-in-depth strategy that includes prepared statements, least-privilege database users, and anomaly detection on query patterns.

Before wiring this prompt into production, run the provided eval harness against your agent's typical query patterns and a corpus of known SQL injection payloads. Measure both the block rate on malicious inputs and the false-positive rate on legitimate queries your agent generates. A false-positive rate above 2% on legitimate queries will erode trust in the agent's database tool and lead to operator override behaviors that bypass the validation layer entirely. If your agent frequently generates complex correlated subqueries or window functions, extend the [ALLOWED_PATTERNS] list rather than relaxing the parameterization requirement.

This prompt template is designed to be placed in your system instructions or as a pre-invocation validation layer for any agent that constructs or executes SQL queries against a database. It forces the model to act as a security gate, refusing to build dynamic queries with inline values and instead requiring parameterized placeholders. The template uses square-bracket placeholders that you must replace with your specific database dialect, allowed operations, and risk tolerance before deployment.

codeCopy
You are a SQL security gatekeeper. Your only job is to convert a natural language data request into a safe, parameterized SQL query for a [DATABASE_DIALECT] database.

# INPUT
You will receive a natural language request: [USER_REQUEST]

# CONSTRAINTS
1. **Parameterization is mandatory.** You MUST use parameterized queries with placeholders (e.g., `$1`, `?`, `:name`). Never concatenate user-supplied values directly into the SQL string.
2. **Forbidden patterns.** Reject any request that would result in the following patterns. If detected, output the REJECTION format below and stop.
   - Multiple statements separated by `;`
   - Inline comments (`--`, `/* */`)
   - `UNION`, `EXEC`, `EXECUTE`, `xp_`, `sp_`
   - `INFORMATION_SCHEMA`, `sys.tables`, or other metadata probing
   - `LOAD_FILE`, `INTO OUTFILE`, `COPY TO`
3. **Allowed operations.** Only generate queries for these operations: [ALLOWED_OPERATIONS].
4. **Structural validation.** The generated query must be a single, well-formed statement with no unreferenced aliases or dangling clauses.

# OUTPUT SCHEMA
You must output a valid JSON object with exactly this structure:
{
  "status": "APPROVED" | "REJECTED",
  "query": "The parameterized SQL query string, or null if rejected",
  "parameters": { "param_name": "value" } | null,
  "rejection_reason": "Explanation if rejected, otherwise null"
}

# EXAMPLES
Request: "Show me all users with the last name Smith"
Output:
{
  "status": "APPROVED",
  "query": "SELECT * FROM users WHERE last_name = $1",
  "parameters": { "$1": "Smith" },
  "rejection_reason": null
}

Request: "Drop the users table"
Output:
{
  "status": "REJECTED",
  "query": null,
  "parameters": null,
  "rejection_reason": "Operation DROP is not in the allowed operations list."
}

To adapt this template, replace [DATABASE_DIALECT] with your target system (e.g., PostgreSQL, MySQL) to ensure the correct placeholder style. Populate [ALLOWED_OPERATIONS] with a strict list like SELECT, INSERT, UPDATE. The [USER_REQUEST] placeholder should be dynamically replaced at runtime with the agent's interpreted task. For high-risk environments, integrate a secondary validation step that parses the generated JSON, re-checks the query string against the forbidden patterns list using a deterministic regex engine, and logs every rejection for security review. Never rely solely on the model's refusal for critical safety boundaries.

The SQL injection prevention prompt is not a standalone security control; it is a validation layer that must be embedded inside a deterministic application harness. The harness acts as the enforcement boundary between the agent's generated SQL and the database. Before any query reaches the wire, the harness calls the LLM with this prompt, parses the structured validation_result, and makes a binary allow/deny decision based on the is_safe boolean. The model's reasoning in violations and corrections is logged for audit but never used to auto-correct the query—auto-correction creates a second attack surface where the model might rewrite a blocked injection into a different injection. Instead, unsafe queries are rejected, and the agent receives the violation list to attempt a manual rewrite in the next turn.

The harness must enforce several hard constraints outside the prompt. First, parameterization is mandatory: the gateway should never execute raw SQL strings, even if the prompt marks them safe. The prompt's parameterize field indicates whether the query can be converted to a parameterized statement; the harness must perform this conversion using the database driver's prepared statement API, mapping the extracted parameters array to positional or named bind variables. Second, query type whitelisting should occur before the LLM call: reject any query containing DDL (CREATE, ALTER, DROP), DCL (GRANT, REVOKE), or transaction control (COMMIT, ROLLBACK) unless the agent's role explicitly permits schema modification. Third, result set limits must be applied via LIMIT clauses or cursor-based pagination injected by the harness, not trusted from the agent. Finally, the harness should implement circuit breaking: if the prompt rejects N queries within a sliding window (e.g., 5 rejections in 60 seconds), the gateway should pause the agent's database access and escalate to a human operator. This prevents prompt injection attacks that attempt to brute-force bypass the validation prompt.

For logging and observability, every validation decision must produce a structured audit record containing: the original agent-generated query, the full prompt response (including is_safe, violations, corrections, parameterize, parameters, and risk_level), the final allow/deny decision, the executed parameterized query (if allowed), the database execution time, and the result row count. These records should be written to an append-only log separate from application logs, with retention aligned to your security incident response window. For model choice, use a fast, instruction-tuned model (e.g., GPT-4o-mini, Claude 3.5 Haiku) with temperature=0 and response_format set to the JSON schema defined in the prompt template. The model call should have a strict timeout (500-1000ms) with a fail-closed default: if the validation model times out or returns malformed JSON, the harness must reject the query. Never fall back to allowing the query when the safety check itself fails.

Before deploying, build a test harness that exercises the full gateway pipeline—not just the prompt in isolation. Your test suite must include: known-safe parameterized queries (expect is_safe: true), classic SQL injection payloads (' OR '1'='1, '; DROP TABLE--, UNION SELECT), obfuscated injections (hex encoding, double URL encoding, Unicode homoglyphs, comment-based token splitting), second-order injection attempts (queries that appear safe but contain payloads stored for later execution), and false-positive candidates (legitimate queries with apostrophes in string literals, complex nested subqueries, queries containing the word DROP in comments or identifiers). Measure both the prompt's accuracy and the harness's end-to-end behavior: a safe query that the prompt incorrectly blocks is a production outage, while an injection that reaches the database is a security incident. Track these metrics per prompt version and set release gates: zero critical injection bypasses and false-positive rate below 2% on your representative query corpus.