Externalized authorization in Convex shifts filtering to the data layer

At a glance

What this is: This is a technical guide on externalized authorization in Convex, with the key finding that Cerbos query plans can be translated into database-level filters instead of application-side row checks.

Why it matters: It matters because IAM teams increasingly need authorization models that scale across NHI, autonomous, and human-access patterns without pushing unsafe filtering logic back into application code.

👉 Read Cerbos' guide to externalized authorization and Convex query plans

Context

Externalized authorization separates access policy from application logic, which is useful when authorization rules need to change faster than code deployments. In IAM terms, that shifts decision-making into a dedicated policy layer, while the application becomes a consumer of permit or deny results and query plans rather than the place where access logic lives.

The practical governance question is not whether authorization is centralized, but where enforcement happens. For data-heavy applications, row-by-row checks can become a scaling bottleneck and can also create a temptation to overfetch data before filtering it, which expands exposure if the control path is not designed carefully.

For teams building around non-human and workload identities, the same pattern intersects with least privilege and data minimisation. The relevant reference point is the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs, because authorization decisions are only one part of the lifecycle problem.

Key questions

Q: How should security teams implement externalized authorization without pushing enforcement back into application code?

A: Security teams should centralise policy in a dedicated engine, then translate the resulting decision or query plan into database-native filtering wherever possible. The goal is to keep the application from becoming the place where access is decided row by row. That reduces overfetching, simplifies policy changes, and makes authorization easier to audit.

Q: Why do query plans improve authorization performance for data-heavy applications?

A: Query plans let the authorization engine describe the conditions for access once, then let the database apply those conditions using its own indexes and execution engine. That avoids fetching records the user should never see and reduces application-side filtering work. The result is better scaling without changing the underlying access policy.

Q: Where does externalized authorization fail in practice?

A: It fails when teams treat the policy engine as separate from data access and allow broad post-filtering or duplicate logic in the application. In that case, the real trust boundary becomes unclear, and sensitive data may be read before the final authorization condition is applied. The fix is to make query-time enforcement the default and post-filtering the exception.

Q: What is the difference between database pushdown and post-filtering in authorization?

A: Database pushdown means the database enforces the access condition directly as part of the query. Post-filtering means the application retrieves records first and then removes unauthorized rows in code. Pushdown is stronger for governance and scale because it keeps unauthorised data out of the application path whenever the policy language and database can express the rule.

Technical breakdown

How externalized authorization changes the enforcement model

Externalized authorization moves the policy decision point out of the application and into a dedicated engine. The application submits a principal, resource, and action, then receives a decision or a plan instead of embedding rule logic itself. That separation makes access control easier to evolve, but it also means the application must faithfully interpret policy output and avoid re-implementing policy in parallel. In practice, this is an identity architecture choice as much as a software design choice, because the policy engine becomes the control surface for who can see or do what.

Practical implication: treat the policy engine as the authoritative access decision layer and remove duplicate authorization logic from application code.

Query plans, partial evaluation, and database pushdown

Cerbos PlanResources partially evaluates policy and returns a query plan, represented as an abstract syntax tree, describing the conditions under which records are visible. That plan can be translated into query language so the database applies filters using its own indexes and execution engine. This is materially different from evaluating every row in application memory. The important mechanism is that policy conditions are split into database-pushable and post-filterable parts, which preserves correctness while reducing waste. The architecture only works well when the underlying data model is mapped cleanly to policy attributes.

Practical implication: map policy attributes to database fields up front so authorization can be enforced at the query layer instead of after data retrieval.

Why post-filtering is a governance risk, not just a performance choice

Post-filtering is the fallback when the database cannot express all policy operators natively. In the Cerbos to Convex example, comparisons can be pushed down, while string and collection operators may require JavaScript evaluation after data is fetched. That preserves functionality, but it also means some data is read before the full authorization condition is applied. For IAM and data governance teams, this is not merely an implementation detail. It changes the trust boundary, the audit story, and the exposure profile if the post-filter path is broad or frequently used.

Practical implication: minimise post-filter reliance and review any policy that forces sensitive records through client-side evaluation.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• 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 really a control-placement decision. When policy is separated from application code, the central question becomes where access is enforced, not whether access is enforced at all. If the database can apply the policy directly, the application stops acting as the filter layer and the blast radius of overfetching shrinks. For practitioners, the lesson is that enforcement locality is now part of IAM design, not a backend implementation detail.

Query-plan pushdown is the right pattern for scalable least privilege, but only when policy and data models align. Cerbos-style partial evaluation lets the database do the heavy lifting while preserving policy intent. That reduces wasted reads and helps keep authorization decisions close to the data, which is the right direction for NHI-heavy and multi-tenant workloads. The practitioner takeaway is to design policy attributes around queryability, not just expressiveness.

Post-filtering creates a trust-boundary split that many teams under-estimate. Once some policy conditions are evaluated after retrieval, enforcement is no longer uniform across all operators. That matters because access control is only as strong as its weakest execution path, and client-side filtering can be easier to overlook in review and audit. The practitioner conclusion is to treat every fallback path as part of the control surface.

Least privilege becomes more operational when the decision is translated into query semantics. This is where NHI governance and application authorization intersect most cleanly, because the same discipline used to constrain service accounts also applies to data access paths. The field should stop thinking of authorization as a boolean gate and start treating it as a data access contract. Practitioners should design for query-time enforcement rather than post-hoc cleanup.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For a broader control baseline, see Ultimate Guide to NHIs , Key Challenges and Risks for how sprawl and over-privilege compound authorization risk.

What this signals

Externalized authorization will increasingly be judged by how little data it has to touch before making a decision. With 6 distinct secrets manager instances already fragmenting control in the wider identity stack, policy engines that rely on broad fallback filtering will struggle to keep enforcement boundaries clean. Teams should expect query-time authorization to become a design expectation, not a niche optimisation.

The governance signal here is that policy expressiveness and data-layer compatibility need to be planned together, not reconciled after implementation. If your policy language routinely falls back to application-side evaluation, the control is still working, but the assurance case is weaker. Practitioners should treat unsupported operators as a design review trigger rather than a convenience.

For practitioners

• Map policy attributes to queryable fields first Align principal, resource, and action attributes with database columns or filterable properties before writing policies so the query layer can enforce access without broad client-side reads.
• Minimise post-filter usage for sensitive datasets Review any policy that depends on unsupported string or collection operators and decide whether the exposure created by reading data before full evaluation is acceptable.
• Separate policy evaluation from application logic Remove duplicate authorization checks from code paths and make the policy engine the single source of truth for permit, deny, and query-plan generation.
• Test mixed operator trees for enforcement drift Validate policies that combine database-pushable and client-side conditions so the split between filter and postFilter never changes the intended access boundary.

Key takeaways

• Externalized authorization improves IAM control only when the policy engine remains the single enforcement source and the application stops duplicating access logic.
• Database pushdown is the scale advantage, but post-filtering introduces a weaker trust boundary that teams need to govern deliberately.
• The most important design decision is whether your policy model can be enforced at query time without reading data you did not intend to expose.

Key terms

• Externalized Authorization: Externalized authorization separates access decisions from application code and places them in a dedicated policy system. The application asks for a decision at runtime, which makes rules easier to update, audit, and reuse across services without redeploying business logic.
• Query Plan: A query plan is a structured representation of the conditions under which data can be returned. In authorization, it lets the policy engine describe access rules in a form the database can enforce directly, reducing application-side filtering and unnecessary record retrieval.
• Post-filter: A post-filter is a second-pass check applied after data has already been fetched from storage. It is sometimes necessary when the database cannot express every policy operator, but it weakens the trust boundary because unauthorized records may be read before final removal.

Deepen your knowledge

Externalized authorization, query-time enforcement, and NHI lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing access controls that need to scale beyond application code, it is worth exploring.

This post draws on content published by Cerbos: externalized authorization in Convex and query plan filtering. Read the original.