SQL String Literal Escape Sanitization Prompt

This playbook is for backend engineers who must insert model-generated text directly into SQL queries. When an LLM produces a string containing unescaped single quotes, backslashes, or other SQL special characters, the resulting query will either fail with a syntax error or, worse, open a SQL injection vector. This prompt takes the raw model output and produces a safely escaped SQL string literal ready for concatenation into a VALUES clause or WHERE condition. Use this as a post-generation repair step in your data pipeline, not as a replacement for parameterized queries. The prompt assumes you have already validated that the input is a string and that you know the target SQL dialect.

Ideal user: A backend engineer or data pipeline operator who has already received a model-generated string and needs to safely embed it into a dynamically constructed SQL statement. Required context: You must know the target SQL dialect (PostgreSQL, MySQL, SQLite, etc.) because escape rules differ. You must also have validated that the input is a string type—passing a non-string or an already-escaped string will produce incorrect results. When not to use this prompt: Do not use this as your primary defense against SQL injection. Parameterized queries with bound variables are always the correct first choice. This prompt is a repair tool for situations where you cannot use parameterized queries—for example, when building dynamic table or column names, or when working with legacy ORMs that require pre-escaped literals. Never use this prompt on user-supplied input that has not been validated; it is designed for model-generated text, not untrusted external data.

The prompt produces a single output: a safely escaped SQL string literal. For example, if the model output is It's a "test", the prompt should return 'It''s a "test"' for a dialect that uses doubled single quotes. The output includes the surrounding quotes, making it ready for direct concatenation. Critical constraint: You must specify the target SQL dialect in the prompt. PostgreSQL uses E'...' for escape string constants and doubles single quotes; MySQL uses backslash escapes by default; SQLite doubles single quotes. Getting the dialect wrong will produce either a syntax error or an injection vulnerability. Next step: After receiving the escaped output, you should still validate it against a known-safe pattern before concatenation. A simple regex check that the output contains only the expected escape sequences for your dialect can catch prompt failures before they reach your database.

This prompt template instructs the model to act as a sanitization engine for SQL string literals. It is designed to be used as a post-generation repair step, taking raw text that may contain single quotes, backslashes, or other SQL special characters and returning a safely escaped string ready for concatenation into a query. The template uses square-bracket placeholders for all dynamic inputs, making it easy to integrate into your application's data pipeline.

textCopy
SYSTEM:
You are a precise SQL string literal sanitizer. Your only job is to escape the provided [INPUT_TEXT] so it is safe for direct insertion into a SQL string literal enclosed in single quotes for a [SQL_DIALECT] database.

Follow these rules strictly:
1. Escape all single quotes (') by doubling them ('').
2. Escape all backslashes (\) by doubling them (\\) unless the [SQL_DIALECT] does not treat backslash as an escape character.
3. If the [SQL_DIALECT] uses a different escape method, apply that method instead.
4. Do not add the surrounding single quotes to the output.
5. Do not perform any other transformations, such as trimming, encoding changes, or comment removal.
6. Output ONLY the escaped string. No explanations, no markdown fences, no extra text.

[ADDITIONAL_CONSTRAINTS]

USER:
[INPUT_TEXT]

To adapt this template, replace the placeholders with your specific values. [INPUT_TEXT] is the raw, untrusted string from the model's output. [SQL_DIALECT] should be a specific identifier like PostgreSQL, MySQL, SQLite, or Microsoft SQL Server to handle dialect-specific escape rules (e.g., MySQL's backslash escaping). The optional [ADDITIONAL_CONSTRAINTS] field can be used to pass extra instructions, such as handling of NULL bytes or specific character set limits. After generating the escaped string, your application code should wrap it in single quotes before inserting it into the SQL statement. Always test the output with your specific database driver and an eval harness that checks for injection patterns.

This prompt is designed to be called as a post-generation repair step, not as the primary interface for user input. After your application receives model-generated text that needs to be inserted into a SQL query, pass that text through this prompt before constructing the final SQL statement. The prompt expects a raw string and returns a safely escaped SQL string literal. It should be integrated into your data access layer or query builder pipeline, sitting between the AI output and the database driver.

Integration pattern: Wrap the prompt call in a function like sanitize_for_sql(text: str) -> str. This function should call the LLM with the prompt template, parse the response to extract the escaped string, and then validate the result before use. Validation checks must include: (1) the output contains no unescaped single quotes outside of escaped pairs, (2) backslashes are properly doubled, (3) the output does not contain any control characters that your specific database driver rejects, and (4) the output length is reasonable relative to the input. If validation fails, retry once with a more explicit error message in the prompt context. If the second attempt fails, escalate to a human reviewer and log the raw input, the failed outputs, and the validation errors. Never fall through to inserting unescaped text.

Model choice and latency: This is a narrow, deterministic task. Use a fast, cheaper model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small model) rather than a large reasoning model. Latency should be under 500ms for typical string lengths. Logging: Log every sanitization call with a unique request ID, the input length, the output length, validation pass/fail status, and the model used. This creates an audit trail for security review and helps detect drift in model behavior over time. Tool use: Do not give the model a SQL execution tool. This prompt should only produce a string; your application code constructs the parameterized query or, if you must use string interpolation, inserts the escaped literal. Prefer parameterized queries (prepared statements) wherever your database driver supports them—the prompt is a safety net, not the primary defense.

What to avoid: Do not call this prompt on user input that has not been through your application's own input validation first. Do not use the escaped output in NoSQL queries, shell commands, or HTML without separate context-appropriate escaping. Do not assume the prompt handles all database-specific escape rules—test against your target database's exact escaping requirements. Finally, never skip the validation step; a model can still produce malformed escapes, especially with unusually crafted input strings designed to confuse the escaping logic.