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. Policy and action settings determine what happens next.
That means you can:
- observe first with
SQLI_ACTION=warn - enforce later with
SQLI_ACTION=block - apply different behavior in MCP vs gateway mode with mode-specific overrides
What Community Supports
Community supports regex-based SQL injection detection with configurable actions.
Relevant variables in the current runtime:
| Variable | Default | Purpose |
|---|---|---|
SQLI_SCANNER_MODE | basic | Scanner mode |
SQLI_ACTION | block | Global SQLi action |
MCP_SQLI_ACTION | inherits global | MCP-specific override |
GATEWAY_SQLI_ACTION | inherits global | Gateway-specific override |
SQLI_BLOCK_MODE is deprecated in favor of SQLI_ACTION.
Detection Pattern Details
The scanner ships with 37 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 | 3 | Medium | SQL commands hidden after inline comments (/* */), MySQL comments (#), and double-dash comments (--) |
| 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 37 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.
Per-connector overrides allow fine-grained control. For example, you might enable strict blocking for a PostgreSQL connector while leaving a read-only analytics connector in warn mode. This is configured through the ConnectorOverrides map in the scanner configuration.
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 and SQLI_ACTION=block in the default community compose stack.
Observe first
SQLI_ACTION=warn docker compose up -d
MCP-specific override
MCP_SQLI_ACTION=block GATEWAY_SQLI_ACTION=warn docker compose up -d
Operational Guidance
A practical rollout pattern is:
- start with
warnin the environment where false positives are still being evaluated - review audit and dashboard data
- move high-confidence production paths to
block
That is the kind of incremental hardening most enterprise teams expect.
