The control point is in the wrong place
Two defences dominate how teams secure AI agent database access today, and both put the control where the attack lives. A post-query data filter runs after the SQL executes and after data has left the database, so an agent that composes its own query can route around it. A post-hoc response guardrail, whether output filtering or an LLM judging another LLM, sits at the model’s input and output boundary, which is exactly where prompt injection and jailbreaks operate.
Both are probabilistic. They score an action and interpret the result, and a single missed action reaches a live system. The reference-monitor literature settled this decades ago: enforcement a model cannot provide has to come from a deterministic mechanism around it. We compared the two philosophies directly in deterministic versus probabilistic text-to-SQL.
OWASP ranks prompt injection as the top large-language-model risk for the second consecutive edition of its LLM Top 10, with sensitive information disclosure second and excessive agency sixth. Its own guidance is that prompt injection is not fully mitigated by retrieval or fine-tuning, and that the answer is defence in depth with least-privilege tooling. The protocol layer inherits the same exposure, which we cover in MCP security risks.
Can AI agents bypass row-level security? The bypass rates
The question is usually asked about the guardrail, not the database engine, and the published rates are not reassuring. These figures come from security vendors and academic work, and the source matters, so each is attributed.
| Technique or study | Source | Reported bypass |
|---|---|---|
| Production guardrail bypass | Adversa AI (vendor) | 65 to 84 percent |
| GCG optimisation attack | Zou et al., 2023 (primary) | 84 percent, transferring to GPT-4 |
| Policy Puppetry | HiddenLayer, April 2025 (vendor) | All major frontier models |
| Crescendo multi-turn | Russinovich et al., USENIX Security 2025 | Under 10 turns; 100 percent on some models |
| Guardrail evasion | arXiv:2504.11168 (Mindgard) | Up to 100 percent on some systems |
| Indirect injection, agentic | Anthropic Claude Opus 4.5 system card | 4.7% at 1 try, 63% at 100 |
The Anthropic figure is the one to hold onto. Attack success rises with the number of attempts, from 4.7 percent at a single try to 63 percent at a hundred, which means a probabilistic defence loses to a determined attacker who simply retries. When one model guards another, the same technique that breaks the first often breaks the second. A guardrail earns its place in a layered defence, but it is not a boundary.
Models violate the rules even when handed the rules
The strongest evidence is not about jailbreaks at all. It is what a text-to-SQL model does when you give it the access rules and ask it to respect them. A 2026 benchmark from the National University of Singapore and Hamad Bin Khalifa University (arXiv:2607.22115, an arXiv preprint) measured this across 53 databases, 399 tables and 21,502 access-annotated query instances. It defines a violation as any case where the correct decision is deny, yet the system still generates SQL.
| Model | Spider | BIRD | LiveSQLBench |
|---|---|---|---|
| Snowflake-R1-7b (open-weight) | 45.43% | 63.77% | 76.15% |
| Qwen2.5-Coder-7b (open-weight) | 46.33% | - | - |
| Gemini 2.5 Flash | 10.13% | 20.49% | 31.76% |
| GPT-5 | 2.55% | 10.46% | 16.72% |
| Claude Sonnet 4.5 | 4.55% | 7.37% | 12.40% |
Open-weight specialists violate the rules on close to half of all instances on the easier Spider set, rising to 76 percent on the harder LiveSQLBench. Commercial models are far better, yet still leak in double digits on realistic enterprise schemas. Zero-shot, temperature zero, k equals five seed averages, so this is not a temperature artefact.
Two findings make the point sharper. The paper describes a refusal-cliff. A model can reason correctly during its chain of thought that access should be denied, yet still decode a final SQL query that returns the data, and the effect worsens on harder queries with longer reasoning. And restricting the schema the model sees does not fix it: for one commercial model, hiding the unauthorised columns actually raised the violation rate, from 12.49 percent to 26.72 percent, because the model hallucinated the columns rather than refusing. You cannot prompt, fine-tune or judge your way out of this. The mechanism sits alongside the accuracy problem we mapped in the text-to-SQL accuracy cliff.
The route to zero is a change of location. A separate 2026 preprint, PCC-SQL (arXiv:2607.12341), applied policy-conditioned constrained decoding at the generation boundary. It was the only method to reach 0 percent leakage on every open-source model on both of its benchmarks, while a two-step generator-and-verifier baseline still leaked between 0.48 and 28.76 percent. Treat the zero as directional rather than universal, since it is a deterministic guarantee only on the SQL fragment the method supports. The direction is the point: enforce at the compile boundary and leakage goes to zero; enforce after the fact and it does not.
Fix the Context, Not the Model. A well-governed semantic layer that understands business context creates more reliable AI-driven analytics than fine-tuning the model itself. No amount of model tuning fixes an allow-or-deny decision that is made in the wrong place. The access rule belongs in the compiled SQL, not in the prompt.
Why an allow-or-deny decision must be deterministic
An access decision is not a quality score. As one practitioner framing puts it, an AI judge is a probabilistic classifier, while an allow-or-deny decision has to be deterministic. When a scoring filter misses, the result is an action already executed against a live system, with no score left to adjust. Microsoft’s guidance on defence in depth for autonomous agents makes the same case for human-in-the-loop review. The orchestrator enforces it, rather than the model, because a model that reasons its way out of escalating is showing exactly the behaviour the escalation was meant to catch.
This is the reference monitor from the security literature, applied to agents. The enforcement a model cannot provide comes from a deterministic mechanism around it. For a query, that mechanism is the compiler, and the rule is applied to the SQL before it runs, a pattern we develop in data authorization and the semantic control plane.
What today’s enforcement patterns actually cover
Warehouse-native controls are the right foundation, and they are genuinely deterministic. Snowflake row access policies are evaluated in-engine before masking, and Snowflake has added agent-identity primitives such as service-agent users and a context function for whether an agent is active. Databricks Unity Catalog enforces row filters and column masks at the query engine, regardless of whether a notebook, a BI tool, Genie or an agent issues the request. Its attribute-based policies attach at the catalog level and cannot be overridden by a table owner.
Each carries documented limits. Warehouse controls stop at the platform boundary: they do not resolve a natural-language question, prove a join path, or compile portably across Snowflake, Databricks, BigQuery and Redshift. They struggle when agents arrive through a shared service account, and they accumulate policy sprawl and per-tenant overhead. Unity Catalog cannot apply row or column rules to a view and fails closed on older runtimes.
The deeper problem is identity. Gravitee’s State of AI Agent Security 2026 report surveyed 919 executives and practitioners in February 2026. Only 21.9 percent treat AI agents as independent, identity-bearing entities. 45.6 percent still rely on shared API keys for agent-to-agent authentication, and 88 percent reported a confirmed or suspected agent security incident in the past year. Shared credentials make attribution impossible, and a rule enforced against the wrong identity is not enforcement.
Among semantic layers, Cube is the closest to this thesis and deserves naming rather than avoiding. Cube enforces row and column access through a signed security context evaluated at query time, and frames the query compiler as the security boundary, since an agent acting for one tenant cannot construct a query for another tenant’s rows if the layer never compiles one. The governed-metric tools, dbt and AtScale, define what a metric means but carry thinner runtime governance. The full landscape sits in our fine-grained data access control and agent governance guides.
Where Colrows fits
Colrows is a semantic execution layer that enforces access at the compilation boundary. It resolves a question into governed SQL and injects the role, row and column predicates into that SQL before execution, and it restricts compilation to authorised fields through persona-scoped isolated subgraphs. An agent acting for a given persona cannot compile a query against fields outside that persona, because the authorised subgraph never exposes them. The forbidden data is not filtered out later; the query that would read it is never generated.
Cube shares the core claim that the compiler, not the prompt or the post-filter, is the boundary. At the architecture level, the Colrows differentiators are the determinism around that boundary: dialect-perfect SQL across four warehouses, proven join paths, point-in-time reproducibility of what a query meant and who could run it, and a full audit trail per query. Enforced least privilege of this kind maps directly onto GDPR Article 32, the HIPAA minimum-necessary standard, PCI DSS access requirements, and SOC 2 CC6 logical-access criteria, all of which favour enforced least privilege over advisory or after-the-fact controls. The wider category sits in our governance and security hub.
A note on the sources
Vendor-sourced figures are attributed as such: the 65-to-84-percent guardrail bypass range is from Adversa AI, Policy Puppetry from HiddenLayer, and the identity statistics from Gravitee. The GCG 84 percent figure is primary (Zou et al., 2023), and Crescendo is from USENIX Security 2025. The three text-to-SQL access-control papers (arXiv:2607.22115, 2607.12341 and 2510.07642) are arXiv preprints, so treat their numbers as pre-publication; the primary paper’s violation rates are k=5 seed averages at temperature zero. PCC-SQL’s zero-leakage result is a deterministic guarantee only on the SQL fragment it supports, cited here as directional validation. EchoLeak was patched server-side with no confirmed exploitation in the wild, and matters as proof of the attack class rather than a breach count. The EU AI Act’s high-risk obligations, including data governance, were deferred from 2 August 2026 to 2 December 2027 by the Digital Omnibus. This page is not legal or security advice.
The multi-tenant version of this problem, where one tenant’s agent must be unable to compile a query for another tenant’s fields, is covered in multi-tenant semantic isolation database design.
Frequently asked questions
Can AI agents bypass row-level security?
Row-level security enforced in the database engine, as in Snowflake or Databricks Unity Catalog, is deterministic and hard to bypass because it runs on the query itself. The weak point is not the engine. It is the identity handed to it. Agents commonly connect through a shared service account, so the database cannot tell which end user is really asking, and the agent inherits the broad access of that account. That is the confused-deputy problem: the query is filtered correctly, but for the wrong, over-privileged identity. Fixing it means propagating the real user identity to the point where the rule is applied.
Do guardrails stop prompt injection?
Not reliably. Security firm Adversa AI reports bypass success rates of 65 to 84 percent against production guardrails, and academic work on guardrail evasion (arXiv:2504.11168) reached up to 100 percent evasion on some systems using character injection and emoji smuggling. Anthropic’s own Claude Opus 4.5 system card shows indirect prompt-injection success climbing from 4.7 percent at one attempt to 63 percent at one hundred, so a determined attacker who retries wins. A guardrail is a useful layer, but on its own it is a probabilistic filter sitting exactly where the attack operates.
What is the confused-deputy problem in AI agents?
A confused deputy is a program tricked into misusing its own authority on behalf of someone with less. An AI agent operates with the access of the account it runs under. When it reads attacker-controlled content, whether a poisoned document, a crafted email or a hidden tool description, injected instructions can direct it to use that broad access to reach data the attacker could never touch directly. EchoLeak was a textbook case: Copilot ran with the user’s permissions, so an external email could steer it to sensitive internal data. The defence is least privilege enforced around the agent, not inside it.
How do you stop an AI agent from leaking data?
Move the control point to where the agent cannot reach it. Filtering output or judging responses fails because both sit at the model boundary where injection works. Enforcing access at the compilation boundary means the SQL the agent runs already carries the role, row and column restrictions, injected before execution. In testing, policy-conditioned constrained decoding (PCC-SQL, arXiv:2607.12341) was the only method to reach 0 percent leakage on every open-source model tested, directional evidence that the compile boundary, not the prompt or the post-filter, is the place to enforce.
How do you enforce least privilege for LLM agents?
Give the agent a real identity rather than a shared key, and scope what it can compile to that identity. NIST SP 800-207 Zero Trust requires per-session, least-privilege access with continuous verification, which for an agent means authenticating with a unique identity and re-checking authorisation as the workflow proceeds, because the agent’s behaviour can change once it processes injected content. In a semantic layer, least privilege means the agent can only compile queries against the fields its persona is authorised to see, so an unauthorised query is never generated in the first place.
How do you isolate tenants for AI agents?
Scope the compilation to the tenant so a query for another tenant’s rows can never be built. Post-query filters can be sidestepped by an agent that composes its own SQL, and a subtle failure is caching: a pre-aggregation or query cache keyed without tenant scope will serve one tenant’s rollup to another, a risk Cube documents. Persona-scoped isolation means the authorised subgraph never exposes fields outside the tenant, so the layer cannot compile a cross-tenant query, and every cache key carries the same context that scoped the query.
