AI
An AI agent that can write to a database is, from a security standpoint, no different from any other piece of software that turns user-supplied text into a database write — the same SQL injection risk applies, just with an LLM instead of a web form generating the query. The agent-specific wrinkle is that the "user input" might be a natural-language request the model itself translates into SQL, which means validation has to happen at the query layer, not by trying to guess what phrasings are dangerous.
Step-by-step implementation
1. Use parameterized queries for every value, always. Never build a SQL string by concatenating or f-string-interpolating a value the agent produced. Pass values as bound parameters so the database engine — not string logic — decides what's code and what's data.
2. Restrict the database role the agent connects as. A model that only needs to insert order records shouldn't hold a database role that can drop tables, alter schema, or read unrelated tables. If the query layer has a bug, a restricted role limits the damage.
3. Handle table and column names separately from values. Parameterized queries protect data values, but they don't work for identifiers like table or column names — OWASP's own SQL injection guidance is explicit about this gap. If an agent needs to pick which table to write to, validate that choice against an explicit allowlist of real table names, never interpolate a model-generated identifier directly into the query string.
# Parameterized SQLite query engine for agent-generated writes,
# including an allowlist for the one part parameterization can't cover:
# the table name itself.
import sqlite3
# Explicit allowlist - the agent can never write an arbitrary table name
ALLOWED_TABLES = {"orders", "support_tickets"}
def secure_agent_write(table: str, name: str, value: str):
if table not in ALLOWED_TABLES:
raise ValueError(f"Table '{table}' is not on the write allowlist.")
conn = sqlite3.connect("enterprise_records.db")
cursor = conn.cursor()
# Table name came from the allowlist check above, not raw model output.
# Values are still bound as parameters, never string-interpolated.
query = f"INSERT INTO {table} (field_name, field_value) VALUES (?, ?)"
cursor.execute(query, (name, value))
conn.commit()
conn.close()| Query approach | SQL injection risk | Notes |
|---|---|---|
| Raw string interpolation of agent output | High | Any value the model produces can alter query logic |
| Parameterized queries for values | Low for data values | OWASP: the database "will always distinguish between code and data" for bound parameters |
| Table/column names (identifiers) | Still exposed if interpolated directly | Parameterization doesn't cover identifiers — use an allowlist instead |
None of this is specific to AI agents — it's the same defense web applications have used against SQL injection for years. What changes with an agent in the loop is that the "attacker" doesn't have to be malicious at all: a model can generate an unsafe query just by misunderstanding a request, so the validation layer needs to hold regardless of whether the input was adversarial or just wrong.
Practical Challenge
Write an SQLite script that takes a user-provided email and updates a profile field securely using parameterized syntax — then add a table-name allowlist check in front of it, so the function rejects any table name that isn't explicitly permitted, even before the parameterized query runs.
Concept Check
Sources & Further Reading
- OWASP SQL Injection Prevention Cheat Sheet — the source for the parameterized-query mechanism above, including the explicit note that identifiers like table names aren't covered by parameter binding and need allowlist validation instead.