Externalized authorization shifts policy enforcement into the query layer

At a glance

What this is: This is a technical guide to externalized authorization for Drizzle ORM, showing how PlanResources turns policy into query plans that databases can execute as filters.

Why it matters: It matters because IAM teams increasingly need authorization to scale beyond app-layer checks, especially where workload and service identities depend on centrally governed policy enforcement.

👉 Read Cerbos' guide to query-plan authorization in Drizzle ORM

Context

Externalized authorization moves access control out of application code and into a policy engine that can be queried at runtime. For identity teams, the key question is not whether a subject can access one object, but how to enforce policy efficiently when a user may only be allowed to see a subset of records. That is a governance and performance problem at the same time, especially in applications that rely on workload identities and database-backed authorization.

The central limitation is obvious once you think in identity terms: checking every row individually forces the application to fetch data it should never expose. Cerbos’ PlanResources approach addresses that by translating policy into a query plan that the database can apply natively. For teams mapping authorization into modern application stacks, this is the same control problem expressed at the data layer rather than inside business logic.

Key questions

Q: How should teams implement externalized authorization without adding query overhead?

A: Use a policy engine to generate a conditional query plan, then let the database execute the filter natively. That keeps authorization logic centralized while avoiding row-by-row checks in application memory. The best pattern is to branch on plan kind, short-circuit denied access, and only build SQL when the plan is conditional.

Q: Why is query-layer authorization better suited to service identities than app-layer checks?

A: Service identities often need to evaluate large result sets, and app-layer checks force unnecessary reads before the system knows what is allowed. Query-layer authorization pushes the decision closer to the data, which reduces wasted I/O and keeps entitlement scope aligned with the actual query being executed.

Q: What do security teams get wrong about policy-to-database translation?

A: They often treat the mapper as a simple integration detail, when it is really part of the authorization control surface. If attribute paths or relation mappings are wrong, the database may enforce a faithful query shape that no longer matches the intended policy. Governance must cover the mapping layer, not just the policy file.

Q: How do teams know whether externalized authorization is working correctly?

A: Look for three signals: denied requests return empty sets without extra reads, conditional plans translate into database-native filters, and relation-based rules resolve correctly across joins. If the application still fetches broad datasets and filters afterward, the control is not operating at the query layer.

Technical breakdown

Partial evaluation turns policy into a query plan

PlanResources uses partial evaluation to interpret policy without evaluating a single concrete resource instance. Instead of returning a yes or no for one object, it returns an abstract syntax tree that captures the conditions under which access is allowed. That tree can then be translated into the target query language. In practice, this means authorization logic remains expressed once in policy, while execution shifts to the database layer where filters, indexes, and joins already operate. The important distinction is between decision making and query generation: one answers who may access, the other shapes what data is even retrieved.

Practical implication: keep authorization rules centralized in policy, then translate conditional plans into database filters instead of post-query row checks.

Always allowed, always denied, and conditional plans

The adapter reduces every plan to one of three outcomes. Always allowed means no filter is needed. Always denied means the caller should receive an empty set immediately. Conditional means Cerbos returns an expression tree that can be compiled into a native WHERE clause. This triage matters because it avoids wasting application work on cases that do not require query construction. It also creates a clear operational boundary for developers: the adapter is not enforcing policy itself, it is converting a policy decision into a query structure the database can execute efficiently.

Practical implication: branch your data access layer on plan kind so you can short-circuit denied access and avoid unnecessary query overhead.

Relation mappings extend policy to joins and nested data

Real policies often depend on related records rather than flat columns. The Drizzle adapter handles that by allowing relation mappings that generate EXISTS subqueries, including nested relations and many-to-many joins. This is the difference between simple attribute lookup and authorization that understands relational data models. It matters because many access rules are really ownership, tenancy, or membership rules spread across tables. When the adapter resolves those relationships in the database, policy enforcement stays aligned with schema structure instead of being reimplemented as custom application logic.

Practical implication: map policy attributes to real schema relations so ownership and tenant rules can be enforced as database-native joins and subqueries.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Externalized authorization is becoming a data-layer governance pattern, not just an app design choice. The article shows a shift from scattered in-code checks to centrally evaluated policy that can be translated into query execution. That reduces policy drift, but it also changes where identity control is actually enforced. For IAM and application security teams, the decision is no longer whether to authorize, but where to place the decision so it can scale with the workload and the database.

Query planning is the right mental model for machine access control at scale. When the identity subject is a service account or application runtime, row-by-row checks are a poor fit because they consume resources before the application knows whether a result set is even valid. The named concept here is identity query-plan translation: policy becomes a database-executable structure instead of a post-query filter. That framing is useful for workload identity, API backends, and data-access governance.

Central policy only helps if the schema mapping is trustworthy. The adapter depends on attribute-to-column and relation-to-table mappings that must accurately reflect the data model. If those mappings drift, the policy engine can remain correct while enforcement becomes materially wrong. That is a governance problem as much as a developer problem. Practitioners should treat mapper maintenance as part of authorization governance, not as routine integration glue.

For modern identity programmes, authorization and data access are converging controls. This matters across NHI and application governance because service identities increasingly gate access to sensitive records through application layers, not through standalone admin workflows. The operational implication is that access policy, query efficiency, and entitlement scope now need to be reviewed together. Teams that separate them will miss how much of their real control surface sits in the data layer.

Externalized authorization will keep expanding because it matches how distributed applications actually decide access. The pattern scales better than embedded conditionals, but it also raises the bar for policy design, testing, and schema governance. Teams should expect more authorization logic to move into reusable engines and adapters, which makes consistency easier and mistakes more visible. The practical conclusion is straightforward: govern the policy model as carefully as the application code that consumes it.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means query-layer controls still depend on incomplete identity inventory in many environments.
• For broader lifecycle context, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for how provisioning, rotation, and offboarding shape effective non-human identity governance.

What this signals

Identity query-plan translation: as authorization moves closer to the database, teams will need to govern policy syntax, schema mapping, and relation handling as one control surface. That is especially relevant where service identities query sensitive data at scale, because the enforcement point now sits inside the execution path rather than around it.

Service-account governance becomes harder when visibility is poor, and the programme risk is not abstract. Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs, which means any query-layer authorization design still depends on incomplete identity inventory.

Teams should expect externalized authorization to expose weak data models quickly. If policies rely on attributes that are inconsistently named, duplicated, or hidden behind ad hoc joins, the database layer will faithfully enforce the wrong abstraction. The operational response is to align policy design, schema governance, and identity lifecycle controls before scaling the pattern.

For practitioners

• Centralise policy decisions before query execution Move access rules out of scattered if statements and into a single policy engine so application code only consumes decisions or query plans. This reduces duplicated logic and makes access behaviour easier to test across services.
• Branch data access by plan kind Handle always-allowed, always-denied, and conditional results separately in the data layer so the application can short-circuit empty results and avoid unnecessary reads.
• Treat attribute mappings as governance assets Review every mapper from policy attributes to schema columns or relations as part of authorization design, because a stale mapping can produce correct policy logic and wrong enforcement.
• Use relation-aware filters for ownership and tenancy rules Model cross-table checks with EXISTS subqueries or equivalent relational filters rather than rechecking ownership in application code after retrieval.

Key takeaways

• Externalized authorization moves access decisions out of application code and into a central policy engine that can generate query plans.
• The scale benefit comes from letting the database enforce conditional access directly instead of fetching data and filtering it in memory.
• Practitioners should govern mapper accuracy, relation handling, and plan kind branching as part of the authorization control surface.

Key terms

• Externalized Authorization: A design pattern that moves access control decisions out of application code and into a separate policy engine. The application asks for a decision at runtime, while the policy engine evaluates rules centrally and returns allow, deny, or a query-shaping result for the caller to execute.
• Partial Evaluation: A method for evaluating policy with incomplete information so the system can simplify rules before a concrete resource is known. In authorization systems, it produces a decision structure or query plan that can later be applied to specific data rows or objects without re-encoding the policy logic.
• Query Plan Adapter: A translation layer that converts an authorization decision or abstract policy plan into a database-native query expression. The adapter maps policy attributes to schema fields, handles relations where needed, and lets the database enforce access conditions efficiently.
• Relation Mapping: A way of connecting policy attributes to data stored across related tables instead of flat columns. It allows authorization rules to express ownership, tenancy, or membership through joins and subqueries, which is essential when access depends on relational context rather than a single field.

Deepen your knowledge

Externalized authorization and workload identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing database-facing access controls in a similar environment, it is worth exploring.

This post draws on content published by Cerbos: Externalized authorization and query plans for Drizzle ORM. Read the original.