Partial evaluation turns authorization into database-query planning

At a glance

What this is: This is a technical explainer on using partial evaluation to translate authorization policies into database query plans for resource listing.

Why it matters: It matters because IAM teams and application architects need to understand when access control is enforced at query time, not just at decision time.

Context

Authorization for a single resource and authorization for a list of resources are not the same problem. The first is a direct decision, while the second requires pre-filtering data so unauthorized rows never leave the database. That difference becomes important in application architectures where policy logic must be translated into query logic without widening access.

In the article's model, PlanResources uses partial evaluation to reduce a policy to conditions the database can execute. That makes the adapter layer part of the authorization boundary, which means schema mapping, operator handling, and fail-closed behaviour all become governance concerns, not just engineering details.

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. Define which policy conditions may be pushed into database filters, test the generated query structure, and fail closed when the adapter cannot represent a policy operator or field mapping accurately.

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. Field-name mismatches, unsupported operators, null handling, and relationship filters can all distort the final predicate even when the policy itself is valid.

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. Those symptoms usually mean the adapter is no longer preserving policy intent at the query layer.

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.

Technical breakdown

How partial evaluation turns policy into a query plan

Partial evaluation is a technique that evaluates the parts of a policy that are already known and leaves the rest as conditions. In PlanResources, Cerbos receives the principal, resource kind, and action, then determines whether access is always allowed, always denied, or conditional. When the result is conditional, it returns an abstract syntax tree that represents the remaining predicates. That tree can then be translated into SQL, MongoDB filters, or ORM-specific queries. The technical value is that authorization logic moves closer to the data layer without abandoning the original policy model.

Practical implication: Treat query-plan generation as part of the authorization control surface and verify that policy-to-query translation preserves intent exactly.

Why AST adapters need operator and field mapping

The adapter is the translation layer between Cerbos's policy model and the database's query language. It walks the AST recursively, maps logical and comparison operators to backend equivalents, and resolves field names that may differ between policy and schema. This includes relational filters such as some, none, is, and isNot, which matter when policies depend on related records rather than just flat attributes. If the mapper is wrong, the policy may still be correct while the resulting query is not, which creates a dangerous mismatch between authorization intent and enforcement.

Practical implication: Validate every operator and field mapping against the target schema before using query plans in production.

Why fail-closed behaviour matters in authorization adapters

An authorization adapter is not just a transformation utility, because it sits on the path between policy decision and data retrieval. The article highlights robust logging, side-by-side debugging, and fail-closed handling for unknown operators as essential design choices. If a future policy feature appears that the adapter does not understand, the safe response is denial rather than permissive fallback. That approach protects the authorization boundary when policy syntax evolves faster than the data-layer implementation.

Practical implication: Design adapters to deny on unknown structures and monitor generated queries for unexpected translation behaviour.

NHI Mgmt Group analysis

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.

Policy correctness is no longer sufficient when enforcement is expressed as a query plan. A policy can be logically sound while the generated query is still wrong because of mismatched field names, unsupported operators, or poor handling of nulls and relationships. The implication is that testing has to cover the generated filter, not only the policy decision. IAM and application teams should validate query output as an authorization artefact in its own right.

Partial evaluation exposes a useful pattern for modern access control systems: push decisions down, but never push trust down blindly. The database becomes an execution partner for authorization, which improves efficiency but also creates a second place where access can drift from intent. The practitioner conclusion is straightforward: treat query-plan adapters as privileged enforcement components and subject them to change control, regression tests, and runtime logging.

Query-plan authorization fits best when teams already understand their data model and can preserve policy semantics across the schema boundary. That is where the strongest operational discipline is required: clear attribute mappings, explicit operator support, and deterministic handling of unsupported cases. Practitioners should expect better performance only when governance over the adapter is as mature as governance over the policy engine.

What this signals

Query-plan authorization changes where access control risk concentrates. The critical control is no longer only the policy rule, but the integrity of the adapter that turns the rule into a database filter. That means teams need regression coverage for translation logic, not just for policy decisions.

Field mapping is the hidden governance layer in policy pushdown. If policy attributes and database schema drift apart, authorization can still appear to work while enforcing the wrong predicate. Practitioners should treat schema changes as authorization changes when policy conditions are compiled into queries.

For practitioners

• 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. Keep the translation boundary explicit so teams know where enforcement changes hands.
• Test generated queries, not just policy outcomes Build regression tests around the emitted query structure for always-allowed, always-denied, and conditional cases. Include relational operators, null handling, and field remapping in the test suite.
• Validate schema mapping before rollout Review every policy attribute against the actual database column or document field name, including nested relationships. A small naming mismatch can turn a correct policy into an incorrect query.
• Make unknown operators fail closed Treat unsupported or future policy operators as denial conditions until the adapter is updated. Log the event so engineering can add support without silently broadening access.
• Monitor query performance after enforcement shifts Check slow query logs and index usage after pushing authorization conditions into the database. Composite or foreign-key indexes may be needed when policy filters touch related entities or use broad OR logic.

Key takeaways

• Partial evaluation can make authorization faster by turning policy into a database predicate, but it also moves the enforcement boundary into the translation layer.
• The main operational risk is mismatch between policy intent and generated query structure, especially where fields, operators, and relationships differ from the database schema.
• Teams should test query output, validate mappings, and fail closed on unknown structures so policy pushdown does not quietly widen access.

Key terms

• Partial evaluation: Partial evaluation precomputes stable parts of a policy so repeated decisions are faster at runtime. For autonomous or high-throughput enforcement points, it helps reduce latency without changing the policy logic, but it still requires careful testing to avoid hidden complexity.
• Query planner: A query planner is the component that decides which order and direction to evaluate parts of an authorization request. In graph-based access control, it turns reachability into a cost-based routing problem, choosing paths that can reduce fan-out, short-circuit sooner, and limit unnecessary work.
• AST Adapter: A translation component that walks an abstract syntax tree and converts policy expressions into backend-specific query syntax. Its reliability depends on exact operator mapping, field-name resolution, and safe handling of unsupported nodes.
• Fail closed: Fail closed means a system denies access when a dependency, policy check, or security service cannot make a confident decision. In AI retrieval pipelines, this prevents partial or unauthorised documents from leaking into the model when the authorization layer errors or returns incomplete results.

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 building or maturing an IAM programme, it is worth exploring.