Data filtering

Authorization-aware data filtering for SQLAlchemy

Convert Cerbos query plans into native SQLAlchemy filters, return only the data your users are authorized to see.

Extend user roles

Fine-grained access controls extending the roles defined in SQLAlchemy models

Enrich with context

Request-time attribute-based authorization enables more contextual access controls

Avoid token bloat

Independent authorization logic avoids bloated tokens and workarounds

How Cerbos works with SQLAlchemy

When users should only see a subset of data, traditional approaches filter results in application code, leading to duplicated logic, inconsistencies, and performance problems at scale.

Cerbos query plan evaluation converts your authorization policies into native SQLAlchemy filters. Instead of fetching all data and filtering after the fact, your database only returns rows the user is authorized to see.

The same YAML policies that control API-level access now drive data-level filtering, one source of truth for who can see what, managed by product and security teams without touching application code.

Policy-as-codeHuman-readable YAML policies managed like source code Scalable PDPStateless policy decision point with sub-millisecond latency Centralized managementManage, test, and deploy policies from a single control plane

How Cerbos filters data in SQLAlchemy

Define authorization policies in YAML, Write resource policies that describe who can see which records, using roles and attributes.
Request a query plan from Cerbos, Your application calls the PlanResources API, and Cerbos returns an abstract query plan.
Convert the plan to a native SQLAlchemy filter, Map the Cerbos query plan to a SQLAlchemy query predicate so filtering happens at the data layer.
Database returns only authorized rows, The query executes with the authorization filter baked in, no post-fetch filtering required.

FAQ

How does Cerbos filter data in SQLAlchemy?

Cerbos evaluates your authorization policies and produces a query plan. The SQLAlchemy adapter converts that plan into a native query filter, so your database only returns rows the user is authorized to see.

Does this replace application-level authorization checks?

Data filtering complements API-level checks. Cerbos handles both, the same policies that control who can access an endpoint also determine which rows are visible at the data layer.