WisdomAI keeps row security out of the prompt—and applies it after SQL generation

Generated SQL is only an intermediate artifact in WisdomAI’s analytics stack. The company says it parses each query into a dialect-independent dataframe, runs deterministic transformations over that structure, and then renders SQL for the target warehouse. The important design choice is what happens in that middle stage: row-level security, column-level security, masking, k-anonymity and partition predicates are applied as code rather than entrusted to the language model. Source

Put invariants after generation

WisdomAI’s row-level-security example makes the boundary concrete. An administrator defines a mandatory rule once in the data model. The rule is not shown to the model and is not regenerated for each request. If a user asks to see all accounts, the model can produce an unsafe broad query; the deterministic layer then rewrites it so the requesting user’s identity constrains the result before execution. Source

That pattern is more useful than the vendor’s broader claim that its harness is enterprise-grade. For builders, it supplies a testable rule: controls that must hold on every execution should not depend on prompt compliance. They should be represented separately, injected or verified after generation, and covered by ordinary software tests.

The same architecture also handles semantic expansion and performance rewrites. WisdomAI says it replaces derived tables and columns with their definitions and can inject partition predicates to avoid scanning very large tables. The transformations are written in Rust and run for chats, apps, dashboards, agents and background jobs, according to the company. Source

The compiler becomes part of the security boundary

This design does not eliminate risk; it moves the critical risk into the parser, intermediate representation and rewrite engine. WisdomAI acknowledges that complex, recursive and dialect-specific SQL can require repeated decomposition, namespace lookup and recomposition, creating both correctness and latency pressure. Source

A production review should therefore ask for evidence at that layer: unsupported syntax behavior, nested-query and alias tests, dialect coverage, proof that every execution path invokes the transforms, and failure behavior when parsing or rewriting cannot be completed. The company’s post describes the architecture but does not publish accuracy rates, latency distributions or adversarial test results, so buyers still need those measurements.

After transformation, WisdomAI either serves a cache hit or sends the rendered SQL to the external warehouse. Returned data is materialized as Parquet in WisdomAI’s object store for preview, pagination and later processing. That adds another control surface—cache keys, stored-result permissions and retention—that teams should evaluate alongside warehouse authorization. Source

The broader lesson is simple: the model can propose SQL, but it should not be the component that guarantees security. Deterministic post-generation enforcement gives teams a place to inspect, test and fail closed.