What is the difference between on-demand permission evaluation and pre-computed authorization relationships?

On-demand permission evaluation calculates access at request time by walking the permission graph each time a decision is needed. Pre-computed authorization relationships store selected derived results in advance so the system can answer common queries faster. The trade-off is between flexibility and speed. Pre-computation improves consistency and performance, while demand-based evaluation keeps logic fully dynamic.

How the two approaches differ in practice

On-demand permission evaluation makes an authorization decision at request time by traversing the live relationship graph, so the result always reflects the current state of roles, group membership, inheritance, and exceptions. Pre-computed authorization relationships shift some of that work ahead of time by materializing derived answers, which lets the system respond faster for repeated queries and common access paths.

The practical difference is not just implementation detail. On-demand evaluation is better when policy changes frequently, when the graph is highly dynamic, or when you need the decision to reflect the latest entitlements without waiting for recomputation. Pre-computation is better when read latency matters, the same access questions are asked repeatedly, and a bounded amount of staleness is acceptable in exchange for speed.

That trade-off is why many teams use a hybrid model: the authoritative policy remains dynamic, while selected derived views are cached or precomputed for performance-sensitive queries. The question to ask is whether the access decision must be perfectly current at the instant of evaluation, or whether a slightly older derived view still produces a safe and useful answer.

Where each model creates operational trade-offs

On-demand evaluation keeps the authorization logic compact and easier to reason about because there is one live source of truth. The downside is cost at decision time, especially when permission graphs are deep, highly connected, or expensive to traverse. At scale, that can create latency spikes, higher compute use, and more variability in user experience.

Pre-computed relationships reduce that runtime burden, but they introduce a second problem: derived data must be rebuilt, invalidated, and synchronized whenever the underlying graph changes. If recomputation lags, the system can temporarily answer with outdated permissions, especially after revocation, entitlement removal, or policy changes that should take effect immediately. In other words, speed is purchased with freshness management.

This is why pre-computation is strongest for stable patterns, such as common “can X access Y?” lookups, reporting, or repeated policy checks that do not require millisecond-perfect recency. On-demand evaluation is strongest for sensitive decisions where the current state matters more than throughput.

Choosing the right model for the access decision

The right choice depends on what failure would be worse: slower decisions or temporarily stale decisions. If the environment changes often, the user population is large, or the permission graph is hard to cache safely, on-demand evaluation usually wins. If the same access relationships are queried constantly and the policy structure is relatively steady, pre-computation can materially improve performance and consistency.

In practice, the best design is usually selective rather than absolute. Cache or precompute the relationships that are high-volume and low-volatility, but keep the final decision path capable of checking live policy when correctness depends on it. That preserves responsiveness without turning authorization into an eventually consistent system where revocation and exception handling become hard to trust.

For teams evaluating authorization architectures, a useful lens is whether the derived relationship is merely an optimization or whether it becomes the thing auditors, operators, or downstream systems rely on. If it becomes authoritative in practice, then its refresh, invalidation, and provenance controls matter as much as the original permission model.

Risk and Threat Considerations

Pre-computed authorization relationships can create exposure if the derived view is stale, incomplete, or not invalidated fast enough after a policy change. On-demand evaluation reduces that staleness risk, but it can still become a bottleneck or denial-of-service pressure point if every request forces an expensive graph walk.

Failure mechanism: An attacker, or even a normal high-volume workload, can exploit slow recomputation, cache lag, or inconsistent invalidation to create a window where access reflects outdated entitlements. With on-demand evaluation, the failure mode shifts toward latency amplification and resource exhaustion when the live graph is too costly to traverse repeatedly.

Impact: Stale derived permissions can preserve access after revocation, while overloaded live evaluation can delay or degrade access decisions across the system. In either case, the business risk is incorrect or unavailable authorization at the exact moment the system is expected to enforce policy.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	6 — Access Control Management	Authorization evaluation and derived access paths are core access control concerns.
Recommendation — Define and enforce access decisions with least privilege and periodic review.
NIST CSF 2.0	PR.AC-4 — Access Permissions and Authorizations are Managed	The question is about how permissions are calculated and stored for authorization decisions.
	PR.AC-1 — Identities and Credentials are Issued, Managed, Verified, Revoked, and Audited	Permission evaluation depends on current identity and entitlement state.
Recommendation — Manage permission models so authorization decisions remain accurate and controlled. Keep identity and entitlement state current so access decisions reflect revocation and change.
NIST Zero Trust (SP 800-207)	PL-8 — Asset inventory and service discovery	Authorization graphs depend on accurate relationship and resource discovery for trustworthy decisions.
Recommendation — Maintain accurate inventories and service relationships to support trustworthy access decisions.
OWASP Non-Human Identity Top 10	NHI-05 — Privileged Access and Least Privilege	Precomputed and on-demand authorization both shape how non-human access is granted and constrained.
	NHI-06 — Secrets and Credential Hygiene	Authorization freshness depends on revocation and the lifecycle of identity-enabling material.
	NHI-07 — Third-Party and Supply Chain Risk	Precomputed authorization often depends on upstream identity and integration data that can drift or fail.
Recommendation — Limit privileged non-human access and validate derived permissions before they are trusted. Rotate and revoke credentials promptly so derived access state does not outlive trust. Validate upstream authorization inputs and integrations before relying on derived access results.

Practitioner Guidance

What to verify: Confirm which part of the authorization result is authoritative, which part is derived, and how quickly derived relationships are invalidated after a change. If the system cannot prove freshness for revocations and policy edits, treat pre-computed answers as advisory rather than definitive.

Decision rule: Use on-demand evaluation for highly dynamic or high-consequence permissions, and reserve pre-computation for repeatable, performance-sensitive queries where bounded staleness is acceptable. If a cached answer can change who gets access to a production asset, require a clearly defined refresh and fallback path.

Practitioner takeaway: The real design choice is not speed versus correctness, it is where you want the system to spend complexity, at request time in live evaluation, or at update time in maintaining derived authorization state.