Partial evaluation turns authorization into database-query planning

At a glance

What this is: This is a technical guide to Cerbos PlanResources and partial evaluation, showing how authorization policies can be converted into database query plans to fetch only permitted resources.

Why it matters: It matters because IAM, NHI, and application security teams increasingly need authorization controls that scale without leaking access through brittle application logic or slow per-record checks.

👉 Read Cerbos's guide to PlanResources query planning and adapter design

Context

Authorization becomes harder when a system must decide both whether a principal can act and which records they are allowed to see before retrieval. In practice, the second problem is where many access-control designs become slow, inconsistent, or difficult to maintain, especially when policy logic has to be enforced at query time across many resources.

Partial evaluation shifts that burden into the database layer by turning policy conditions into executable filters. For identity programmes, that means policy quality, field mapping, and fail-closed behaviour become part of the access-control control plane, not just implementation details. For teams governing human users, service accounts, and workload identities, that is a material change in how authorization is designed and tested.

Key questions

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. Test every operator, verify field mapping against the live schema, and require fail-closed behaviour when a condition cannot be translated safely. The safest implementations compare the generated filter with the intended policy logic before deployment and again after schema changes.

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. That improves performance and consistency, but only if the policy translation remains faithful. The main benefit is scalable access enforcement without duplicating policy logic across services.

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. That is why schema mapping must be tested, versioned, and reviewed whenever the database model changes.

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.

Technical breakdown

How partial evaluation turns policy into a query plan

PlanResources evaluates a policy with only the principal, resource kind, and action, then returns either always allowed, always denied, or conditional. In the conditional case, the system emits an abstract syntax tree that represents the remaining access criteria. That AST is not yet a database query. It is a structured policy result that can be translated into SQL, MongoDB, or ORM filters without reinterpreting the policy logic in application code.

Practical implication: Translate the AST into backend-native filters, and validate that your adapter preserves policy meaning exactly.

Field mapping and operator translation in authorization adapters

An adapter must reconcile policy fields with database schema names, such as mapping request.resource.attr.ownerId to owner_id. It also has to translate operators like eq, and, in, some, none, is, and isNot into the target query language. This is where authorization logic often breaks, because a correct policy can still produce the wrong data-layer filter if path mapping or relational handling is inconsistent.

Practical implication: Treat field mapping and operator coverage as security-sensitive code paths, not convenience features.

Query-plan performance and fail-closed behaviour

Query plans can improve performance because they push authorization conditions into indexed database operations instead of evaluating every record in application memory. But that efficiency only holds if the adapter handles unknown operators and null semantics safely. The guide's fail-closed guidance matters because future policy features or mismatched schema assumptions can otherwise turn an authorization extension into an access-control bypass.

Practical implication: Benchmark the generated queries, inspect slow logs, and fail closed whenever the adapter cannot map a policy expression safely.

NHI Mgmt Group analysis

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.

Field mapping is the hidden trust boundary in partial-evaluation systems. The article makes clear that policy paths and database columns are rarely identical, so the adapter becomes a semantic bridge between identity policy and data access. If that bridge is wrong, access decisions can drift from the policy model without any visible policy change. Teams should review schema mapping as part of authorization assurance, not as a developer convenience task.

Fail-closed adapter design is the right default for evolving authorization engines. Unknown operators, null handling, and relational edge cases are exactly where policy translation becomes unsafe. A query planner that cannot translate a condition cleanly should deny access rather than guess. Practitioners should require closed failure paths, because authorization systems become brittle when future policy features outrun adapter support.

Partial evaluation makes access control more scalable, but also more dependent on data-model discipline. Once authorization is pushed into the database, indexing strategy, query shape, and schema consistency all influence security outcomes. That collapses the old separation between IAM policy design and application data modelling. Teams should align authorization engineering with database governance from the start.

Dynamic authorization now behaves like a compiled control, not a runtime check. The article's query-plan model shows that access decisions can be pre-shaped into executable filters before data is fetched. That improves efficiency, but it also means the system's security quality depends on compilation correctness across every supported operator and relationship path. Practitioners should validate the entire translation pipeline as part of access-control assurance.

From our research:

• 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.
• That fragmentation and concern reinforce why teams should study the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs alongside query-time authorization design.

What this signals

Query-plan authorization will expose weak schema governance faster than weak policy design. Once access decisions depend on translated filters, teams will discover that field naming, null semantics, and relationship modelling are part of the security boundary. The practical signal is simple: if the generated query is hard to reason about, the control is harder to trust.

With 43% of security professionals already worried about AI systems reproducing sensitive patterns from codebases, according to The State of Secrets in AppSec, the same translation discipline that protects secrets handling should be applied to authorization adapters. A compiled control is only as safe as the mapping layer that turns policy into execution.

Authorization-as-query-planning: this is the point where IAM, application logic, and database governance converge into one operational control surface. Teams that already manage identity lifecycle and secrets sprawl should extend those disciplines to query-plan review, because the enforcement path now crosses all three layers.

For practitioners

• 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.
• Require fail-closed behaviour for unknown policy constructs If the adapter encounters an operator it cannot translate safely, deny access, log the event, and add support before deploying the new policy version.
• Log the query plan and translated query together Capture the input query plan and the generated native query side by side so translation errors, null handling issues, and schema mismatches are visible during development and incident review.

Key takeaways

• Partial evaluation moves authorization decisions into the query layer, which improves scale but raises the stakes for translation accuracy.
• Adapter quality now determines whether policy intent survives contact with schema mapping, relational operators, and backend-specific query syntax.
• Teams should test, log, and fail closed at the translation layer, because access control is only as trustworthy as the query plan that enforces it.

Key terms

• Partial Evaluation: A policy evaluation method that resolves what it can from limited input and leaves the rest as structured conditions. In authorization systems, it turns a high-level policy into a reusable decision artifact that can later be translated into a database filter or enforcement rule.
• Query Plan: A machine-readable description of the conditions a resource must satisfy for access to be granted. In authorization contexts, the plan is not the final decision itself, but the structured output that allows a database or adapter to fetch only permissible records.
• Field Mapping: The process of translating policy attribute names into the actual names used by a database schema or document model. It is security-sensitive because a mismatch can cause incorrect allow or deny decisions even when the policy itself is valid.
• Fail-Closed: A security behaviour where a system denies access when it cannot confidently evaluate or translate a rule. In authorization adapters, fail-closed handling prevents unknown operators, schema mismatches, or parsing errors from turning into unintended access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Cerbos: partial evaluation and query plans for authorization. Read the original.