Tool Authorization for Database Query Tools Prompt Template

This playbook is for data platform engineers who need to give an AI assistant controlled access to a database for read-only queries. The prompt enforces a strict boundary: the assistant can execute SELECT statements against an approved schema subset but must refuse any destructive operation, schema modification, or access outside the allowed tables and columns. Use this when the assistant sits between a user's natural language question and a SQL execution layer, and you need the prompt itself to act as the first authorization gate before the query reaches the database.

The ideal user is an engineering lead or platform architect integrating an LLM into a data product where users ask questions in natural language. The required context includes a defined list of allowed tables and columns, a read-only database connection string, and an application layer that will parse the model's output before executing any SQL. This prompt is not a standalone security solution. It must be paired with database-level permissions (GRANT SELECT only), a connection configured with read-only transaction modes, parameterized query execution to prevent injection, and a query validator in the application layer that rejects any statement not matching an allowlist of safe patterns.

Do not use this prompt as your only security control. A prompt injection attack that convinces the model to output a DROP TABLE statement will succeed if the application blindly executes the model's output. The prompt is a first gate, not a last resort. Also, do not use this prompt for write operations, schema migrations, or administrative queries. If your use case requires the assistant to modify data, use a separate tool authorization prompt with explicit confirmation requirements, human-in-the-loop approval, and full audit logging. For high-risk environments, add a secondary validation step where a second model or deterministic rule engine reviews the generated SQL before execution.

This prompt template defines a strict contract for an AI assistant authorized to query a database. It enforces read-only patterns, restricts accessible tables and columns, and requires query sanitization before execution. The template is designed to be the single source of truth for database tool authorization within your system prompt architecture. Replace every square-bracket placeholder with your specific schema, limits, and operational policies before deployment.

markdownCopy
You are a database query assistant with strictly limited authorization. Your primary directive is to help users retrieve data safely without ever modifying, deleting, or exposing the underlying database structure beyond what is explicitly permitted.

## Authorized Tools
You have access to ONE tool:
- `execute_read_only_query(sql: string)`: Executes a SQL query and returns the result set. This tool will REJECT any statement that is not a SELECT query.

## Authorization Policy
1.  **Read-Only Enforcement:** You are FORBIDDEN from generating, suggesting, or attempting to execute any SQL statement other than SELECT. This includes INSERT, UPDATE, DELETE, DROP, ALTER, TRUNCATE, CREATE, EXEC, or any other data modification or schema alteration commands.
2.  **Schema Boundary:** You may ONLY query the following tables and columns. Any request involving tables or columns outside this list must be refused.
    - [TABLE_NAME_1]: [COLUMN_A], [COLUMN_B], [COLUMN_C]
    - [TABLE_NAME_2]: [COLUMN_D], [COLUMN_E]
    - [VIEW_NAME_1]: All columns are accessible.
3.  **Query Sanitization:** Before calling the tool, you must validate the generated SQL against these constraints:
    - The statement must start with `SELECT`.
    - It must not contain multiple statements separated by `;`.
    - It must not contain comments (`--`, `/* */`).
    - All table and column names must exactly match the authorized list above.
    - String literals must be properly escaped with single quotes.
4.  **Destructive Function Prevention:** You are FORBIDDEN from using system functions that could cause harm, even in a SELECT context, such as those that execute shell commands, read arbitrary files, or cause network requests, unless explicitly added to an allowlist: [ALLOWED_FUNCTIONS].
5.  **Refusal Protocol:** If a user requests a prohibited action, you must refuse clearly and state the specific policy reason. Do not suggest alternatives that violate the policy. Your refusal message should follow this format: "I cannot fulfill this request. It violates the [POLICY_NAME] policy because [REASON]."
6.  **Confirmation for Broad Queries:** If a generated query lacks a `WHERE` clause or uses a `LIMIT` greater than [MAX_LIMIT], you must first present the query to the user and ask for explicit confirmation before executing it.

## Output Format
After a successful query, present the results in a [OUTPUT_FORMAT, e.g., markdown table]. If the query returns an error from the tool, report the sanitized error message to the user without exposing the full database schema or connection details.

To adapt this template, start by defining the [TABLE_NAME] and [COLUMN] placeholders with your actual database schema. This is the most critical step for enforcing the principle of least privilege. Next, configure the [ALLOWED_FUNCTIONS] list, which should be as restrictive as possible—an empty list is ideal. Set the [MAX_LIMIT] to a reasonable number like 100 or 1000 to prevent accidental resource exhaustion. Finally, integrate this system prompt with your application harness, which must independently enforce these same rules in the tool execution layer. The prompt is a policy declaration, not a security perimeter; the actual execute_read_only_query function must reject any non-SELECT statement before it reaches the database. Before shipping, run eval checks that include SQL injection attempts, requests for out-of-schema tables, and multi-statement payloads to confirm the model adheres to the policy under adversarial conditions.

The prompt template is the policy layer, but it cannot be the only enforcement mechanism. A model can be tricked, confused, or simply fail to follow instructions under adversarial or edge-case pressure. The implementation harness must treat the model's decision to call a tool as a request, not an authorization. The application layer must independently validate every tool call before execution, using deterministic rules that mirror the prompt's policy. This means the harness checks the SQL string, the target tables, the operation type, and the user's role after the model generates the call but before the database receives it.

A concrete implementation uses a tool call interceptor or middleware function that wraps the database driver. When the model emits a function call like run_query(sql="SELECT..."), the harness first parses the SQL using a statement-level parser (not regex) to extract the operation type. If the operation is not SELECT or EXPLAIN, the call is blocked and the model receives a synthetic error: "Tool execution blocked: only read-only queries are permitted." The harness then checks the table names against an allowlist defined per user role. If the query references users.credentials and the role analyst is not permitted, the call is blocked. Finally, the harness applies a parameterized query wrapper, rejecting any SQL that contains inline values instead of bind parameters. Log every blocked attempt with the user ID, session ID, raw SQL, and the specific rule that failed. This log is your audit trail and your early warning system for prompt injection attempts.

For model choice, prefer models with strong instruction-following and tool-use discipline. Test the prompt with at least 50 adversarial queries that attempt to bypass the read-only constraint, access forbidden tables, or inject SQL via tool arguments. Measure the block rate at the harness layer, not the model's refusal rate. A model that refuses 98% of attacks but still passes 2% to the harness is acceptable only if the harness blocks 100% of those 2%. If the harness ever executes a disallowed query, the prompt alone has failed. Add a human approval gate for any query that the harness cannot definitively classify as safe, such as queries with complex CTEs or dynamic table references. The escalation message should include the full query, the user's role, and the reason for the hold. Do not rely on the model to self-report its own policy violations.