SQL injection patterns
Configuration, evaluation scope, and practical limits for sql_injection.
sql_injection is the policy type used by the API and policy editor.
What it checks
Detects SQL attack patterns in LLM input and optional output.
Configure the policy
Create a policy under Dashboard → Security → Policies. Choose this policy type, set the agent scope, and start in warning mode while you measure results. Use blocking only after verifying the application’s decision gate.
The following is the config object, not a complete policy-creation request:
{
"check_output": true,
"blocked_predicates": [
"destructive_sql",
"tautology",
"union_select"
]
}Scope and limits
Omit blocked_predicates for the full built-in set. Pattern labels also include stacked_query, sql_comment, exec_call, xp_cmdshell, time_based and comment_termination. This detector does not parse database permissions or execute a query. Parameterized queries, least-privilege database roles and application authorization remain necessary. Documentation containing legitimate SQL can trigger findings.
Verify before rollout
Test a representative safe input, a synthetic positive case, and an unavailable-detector case. Inspect evaluation_status, errors, policies_evaluated, findings and allowed. A clean empty finding list is useful only when the required checks completed.
The policy mode determines the decision: warning findings can coexist with allowed: true. Your application must act on a blocking decision before the protected operation. Evaluation does not automatically redact text or cancel an operation that already happened.