Two advisories in the last two weeks have the same shape.
DBHub, which exposes databases to AI agents (GHSA-j656-3hf2-fvjc, fixed in 0.22.6). Read-only mode is the control operators use to let an assistant read a database without changing it. DBHub split the SQL, checked each statement, then sent the original string to MySQL or MariaDB with multipleStatements: true. Its parser treats -- as the start of a comment. MySQL and MariaDB only do when whitespace, a control character or the end of the line follows:
SELECT 1--1;DROP TABLE victim
DBHub saw one SELECT and passed the check. The database ran SELECT 1 - -1 and then dropped the table. The advisory names the realistic path: prompt injection in content the assistant reads.
LangGraph (GHSA-4hm6-w6qq-w73v / CVE-2026-118668, fixed in langgraph-api 0.15.0). A JavaScript or TypeScript Store authorization handler rewrote the requested namespace to restrict each user to their own data. The server did not carry that change across the runtime boundary, so an ordinary user could read, overwrite or delete another user's Store data.
In both cases the decision was correct. The check passed the right statements. The handler returned the right namespace. What ran was something else.
A decision that nobody enforces is a log entry, not a control.
This is the gap between where a control decides and where an action executes. The two read different inputs, or the decision never reaches the executor. Neither shows up in a review of the policy, because the policy is fine.
Nothing in the harness catches either one directly.
The closest tests are adjacent, meaning the same class through a different mechanism:
APB-001 | Approval Bound to Its Arguments: what was approved must be what executes, tested at the approval layer rather than a SQL validator.WT-002 | Read-Only Ingestion Still Executes the Sink: a read-only path that still runs something, reached through repository config rather than SQL.ACSH-001 | Deny Honored: an agent must honor a valid DENY, which tests an agent consuming an external decision, not a server applying its own handler's result.
Two probes, filed as #688:
-- without trailing whitespace, conditional comments, stacked statements) to a tool that claims read-only mode. Then check the database state, not the tool's answer.
Both need what the rest of the suite needs: a positive control, so a tool that refuses everything cannot pass. The truth tables for both are written and merged (#689); the probes come next.
Where does your agent's database tool validate SQL: before the driver sees the string, or on exactly the statements the driver executes?