SQL Injection Tautology RBAC Bypass
Attackers slip classic SQL tricks like "OR 1=1" into the text or parameters they send to an AI agent. If the agent passes that input straight into a database query, the tautology makes the query's filter always true, returning every row instead of just the rows the caller is allowed to see.
How the attack works
An attacker crafts a tool argument or message that includes a SQL condition designed to always be true, such as "OR 1=1", "OR true", or "OR 'a'='a'". The AI agent forwards this value into a database query without sanitizing it. The tautology overrides the intended WHERE clause, including any row-level security or role-based access filter. The query then returns all matching records regardless of the requesting user's actual permissions.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 53b45dd9-e3ad-44e7-bf6e-1699300ef534
- Severity
- Critical
Why it matters
An attacker with low-privilege access to the agent can retrieve data belonging to other users or tenants, breaking row-level and object-level access controls and exposing sensitive records they were never authorized to see.
What you can do
- →Never build SQL queries by concatenating raw user or agent input; use parameterized queries or prepared statements everywhere.
- →Enforce authorization checks at the database or application layer independently of query text, so a malformed WHERE clause cannot widen access.
- →Validate and reject tool arguments that contain SQL syntax when the field is expected to be a plain value like an ID or name.
- →Log and review agent tool calls that pass suspicious boolean or SQL-like patterns as arguments, distinguishing them from legitimate documentation or code snippets.
Known benign look-alikes
- SQL queries in documentation or educational context (narrative text without tool_args)
- Boolean logic expressions in non-SQL programming contexts