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.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “Filtering database results with Cerbos query plans”.
Key questions
Q: How should teams implement policy-to-query authorization without breaking access controls?
A: Start by treating the translation layer as part of the authorization boundary.
Q: Why can a correct authorization policy still produce the wrong access outcome?
A: Because the enforcement result depends on the generated query, not only the policy logic.
Q: What are the signs that query-plan authorization is failing in production?
A: Look for unexpected denial patterns, mismatched fields between policy and schema, slow queries after rollout, and logs showing unsupported operators.
Practitioner guidance
- Define the policy-to-query translation boundary Document which authorization decisions are allowed to become database predicates and which must remain in the policy engine.
- Test generated queries, not just policy outcomes Build regression tests around the emitted query structure for always-allowed, always-denied, and conditional cases.
- Validate schema mapping before rollout Review every policy attribute against the actual database column or document field name, including nested relationships.
Bottom line: Partial evaluation can make authorization faster by turning policy into a database predicate, but it also moves the enforcement boundary into the translation layer.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
12/06/2026 8:20 am
Query planning turns authorization into a data-enforcement problem, not just a decision problem. Once policy conditions are compiled into database filters, the control boundary shifts from the policy engine to the adapter and query layer. That makes schema mapping, operator coverage, and fail-closed handling part of the authorization posture, not implementation detail. Practitioners should govern the translation path with the same care they apply to the policy itself.
A question worth separating out:
Q: What should security teams do when an authorization adapter sees an unknown operator?
A: Treat it as a denial condition until the adapter is updated and tested. Silent fallback is dangerous because it can broaden access at the exact point where policy syntax has moved beyond what the database translation layer understands.
👉 Read our full editorial: Partial evaluation turns authorization into database-query planning