SQL Injection Scanning

AxonFlow includes built-in SQL injection detection so teams can govern risky queries and suspicious payloads in AI-driven systems. This matters both when a model generates SQL and when connector traffic carries dangerous statements or response-side patterns.

Detection vs Enforcement

Detection identifies suspicious content. The action stored on the matched security-sqli policy determines what happens next.

Every shipped sys_sqli_* platform policy stores warn, so out of the box a detection is recorded and the request proceeds. The exception is two organization-editable policies, sql_injection_union and sql_injection_or, which block the patterns they match; see Shipped Policy Posture. Two things can change the outcome:

• An organization override (Enterprise): record sqli=block on the customer portal's Detection Posture page, or with PUT /api/v1/detection-posture/sqli. It applies to every security-sqli policy for that organization, and each change is audited.
• A different action for one policy: change that shipped policy's action for your organization, or author a blocking policy of your own as a typed policy document.

No environment variable sets the action.

What Community Supports

Community supports regex-based SQL injection detection. The scanner mode is the only deployment setting:

Variable	Default	Purpose
SQLI_SCANNER_MODE	basic	Scanner mode: off, basic, or advanced (Enterprise)

Removed in v11

SQLI_ACTION, SQLI_BLOCK_MODE, MCP_SQLI_ACTION and GATEWAY_SQLI_ACTION no longer set an action. A deployment that still sets one keeps running: at boot the agent logs WARN [agent] detection posture env var ignored: SQLI_ACTION=block no longer sets an action (v11); the stored policy action decides and counts it in axonflow_ignored_posture_env_total{name="SQLI_ACTION"} on /prometheus. Remove the variable, then record an organization override or change the policy's action.

Detection Pattern Details

The scanner ships with 38 regex-based patterns organized into 8 categories. Each pattern has a severity rating from 1 to 10.

Category	Pattern Count	Severity	What It Detects
UNION-based	2	Critical/High	UNION SELECT statements and UNION injection after string termination
Boolean blind	3	Medium	Tautology conditions like OR 1=1, OR 'a'='a', and AND with numeric comparisons
Time-based blind	4	High	SLEEP(), WAITFOR DELAY, PG_SLEEP(), and BENCHMARK() functions used to infer data through timing
Error-based	3	Medium	EXTRACTVALUE(), UPDATEXML(), and CONVERT(INT,...) functions that extract data through error messages
Stacked queries	5	Critical	Semicolon-separated DROP, DELETE, UPDATE, INSERT, and EXEC/EXECUTE statements
Comment injection	4	Medium/High	SQL commands hidden after inline comments (/* */), MySQL comments (#), and double-dash comments (--), plus a bare string-literal terminator followed by a line comment that ends the line (the admin' -- comment-out authentication bypass)
Generic	9	Varies	Authentication bypass patterns, hex-encoded payloads, CHAR() obfuscation, CONCAT with embedded SELECT, INFORMATION_SCHEMA enumeration, system table access, LOAD_FILE(), and INTO OUTFILE/DUMPFILE
Dangerous queries	8	Critical/High	Destructive DDL (DROP TABLE, DROP DATABASE, TRUNCATE TABLE, ALTER TABLE), DELETE FROM without WHERE, and privilege operations (CREATE USER, GRANT, REVOKE)

The severity mapping at the audit level groups these into four tiers: Critical (stacked queries, dangerous queries), High (UNION-based, time-based), Medium (boolean blind, error-based, comment injection), and Low (generic patterns).

How Detection Works at the Agent Level

SQL injection scanning runs inside the agent gateway as middleware. When a request passes through the agent (either a direct API call or a gateway-proxied LLM request), the scanner inspects the content against all 38 patterns. If any pattern matches, the scanner produces a result containing the matched pattern name, category, severity, and a snippet of the matched content.

The scanner supports both input-side and response-side scanning. Input scanning checks user prompts and request payloads before they reach the LLM or MCP connector. Response scanning checks MCP connector responses before they are returned to the caller. This dual-direction approach is important because SQL injection can appear in model-generated output (a model that writes SQL) as well as in user input that reaches a database connector.

Detection results are written to the audit trail when AuditTrailEnabled is true (the default). This means every SQL injection detection, whether blocked or warned, is recorded with the pattern name, category, severity, and input snippet for compliance review.

Why This Matters in AxonFlow

AI systems do not only fail at prompt time. They fail when a generated or user-influenced query reaches a real tool or database. AxonFlow puts SQLi detection inside the governed runtime path so teams can audit and control that behavior before it becomes a data or production incident.

Configuration Examples

Default behavior

docker compose up -d

This uses SQLI_SCANNER_MODE=basic. Detections are recorded with the stored warn action.

Enforce for an organization (Enterprise)

curl -X PUT "$PORTAL_URL/api/v1/detection-posture/sqli" \
  -H "Content-Type: application/json" \
  -b "$PORTAL_SESSION_COOKIE" \
  -d '{"action":"block"}'

The call needs a portal session with the sso:configure permission. Agents apply the change within AXONFLOW_DETECTION_OVERRIDE_TTL_SECONDS (60 seconds by default). DELETE on the same path returns the organization to the stored actions.

Disable scanning

SQLI_SCANNER_MODE=off docker compose up -d

Operational Guidance

A practical rollout pattern is:

1. start on the shipped warn while false positives are still being evaluated
2. review audit and dashboard data
3. record sqli=block for the organizations whose production paths are ready, or set block on the specific policies you trust

That is the kind of incremental hardening most enterprise teams expect.

Related Docs

• PII Detection
• MCP Policy Enforcement
• Security Overview

Operational Readiness Checklist

Before relying on this page in a production rollout, pair it with the core operations docs:

• Deployment Mode Matrix for self-hosted, Evaluation, Enterprise, SaaS, and In-VPC fit
• Failure Modes And Recovery for degraded-provider, connector, approval, and runtime behavior
• Capacity Planning for sizing and growth signals
• Community vs Evaluation vs Enterprise for limits, support surfaces, and upgrade triggers