Notifications
Clear all
Topic starter
11/06/2026 11:36 pm
TL;DR: Authorization decisions can be turned into database query plans with partial evaluation in PlanResources, letting teams fetch only permitted resources while preserving policy logic, according to Cerbos. The core implication is that authorization quality now depends on how safely policy conditions are translated into query-layer enforcement, not just on policy correctness.
NHIMG editorial — based on content published by Cerbos: partial evaluation and query plans for authorization
Questions worth separating out
Q: How should teams implement query-plan based authorization without creating hidden access gaps?
A: Treat the policy-to-query adapter as security-critical code.
Q: Why does partial evaluation matter for IAM and application security teams?
A: It lets teams enforce authorization at the data layer instead of checking each resource one by one in application code.
Q: What breaks when authorization adapters map policies to the wrong database fields?
A: The system can return permitted data that does not actually match the policy or can deny valid access because the translated query no longer reflects the policy condition.
Practitioner guidance
- Validate operator coverage end to end Build tests for every supported operator, including relational cases such as some, none, is, and isNot, and compare the generated filter to the expected backend structure.
- Audit field mapping as a security control Review how policy attributes map to schema fields, especially when policy paths such as request.resource.attr.ownerId must resolve to differently named database columns or nested relationship paths.
- Benchmark authorization queries against real indexes Check whether your most common policy conditions align with existing database indexes, then inspect slow query logs for compound filters and relationship-heavy plans.
What's in the full article
Cerbos's full engineering guide covers the operational detail this post intentionally leaves for the source:
- Recursive AST traversal patterns for building your own query-plan adapter.
- Operator-by-operator mapping examples for SQL, Prisma, and MongoDB backends.
- Testing approaches for conditional, always allowed, and always denied authorization outcomes.
- Debugging techniques for filterDebug output, null handling, and unknown operator failures.
👉 Read Cerbos's guide to PlanResources query planning and adapter design →
Query planning for authorization: are your access controls keeping up?
Explore further
12/06/2026 8:20 am
Query-plan authorization shifts the control point, but not the governance burden. When authorization is translated into database filters, the security decision is no longer isolated in the application layer. The real control surface becomes the adapter that maps policy logic into backend queries, which means access correctness now depends on translation fidelity, not just policy intent. Practitioners should treat query planning as an authorization architecture decision, not an optimisation trick.
A few things that frame the scale:
- Organisations maintain an average of 6 distinct secrets manager instances, according to The State of Secrets in AppSec.
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases.
A question worth separating out:
Q: Who is accountable when a translated authorization query behaves differently from the policy?
A: The application owner remains accountable, because the adapter is part of the enforcement path. Security, platform, and data engineering teams should share ownership of query-plan translation, especially when policies are compiled into backend queries that determine who can see what.
👉 Read our full editorial: Partial evaluation turns authorization into database-query planning
