WrenAI can now plug authorization into semantic planning—but the application must bind the identity

WrenAI’s semantic core 0.5.0 adds a pluggable access-control interface for applications that need authorization rules beyond those stored in Wren’s own modeling layer. The release exposes a Rust AccessControlProvider that can inject row filters, allow or deny individual columns, and identify fields required to evaluate those filters while semantic SQL is being planned. (WrenAI release; implementation commit)

Authorization moves into the planner

The useful change is where policy is applied. A provider can deny an entire model by returning a permission error, omit denied columns from wildcard expansion, and reject an explicit reference to a prohibited column. Columns needed only to compute a row filter are still checked, and they do not become extra user-visible result columns. Provider errors stop planning rather than falling back to another provider. (implementation commit)

That gives an application a place to connect its own tenant, role or policy system to Wren’s semantic compiler instead of relying only on static model rules or filtering results after query execution. The same provider is used for query planning and permission-error diagnostics, according to the new documentation. (implementation commit)

The identity boundary is still outside Wren

The extension does not authenticate a user. Wren’s documentation says applications remain responsible for authenticating the identity bound to the provider. Providers must also support concurrent planning calls without sharing mutable traversal state; request-specific identity can be carried by the provider or read from session properties. (implementation commit)

There are two other limits practitioners should keep visible. The new API does not provide column masking, and provider registration is currently a Rust extension point rather than a Python or JavaScript API. Wren also warns that analyzing an unfiltered schema for remote SQL generation prepares schema and lineage but does not authorize a query; the chosen provider still has to be applied during the transform or planning step. (implementation commit)

For teams embedding WrenAI behind a conversational analytics service, the rollout test should therefore cover more than whether a row filter works. Verify that each request carries the intended identity, wildcard expansion cannot reveal denied columns, explicit references fail closed, provider-introduced subqueries inherit policy, and every code path invokes the provider-aware transform. The release creates a stronger enforcement hook; using it safely remains an application integration task.