Dependent relations show what inputs contribute to a given permission, while computable permissions show what permissions may be affected by changing a specific relation or permission. The first is a backward view of how access is built. The second is a forward view of what access may change if a schema element is modified.
How dependent relations and computable permissions differ in schema analysis
Dependent relations and computable permissions answer different analysis questions. Dependent relations describe the upstream dependencies that feed a permission, so they are useful for tracing why access exists. Computable permissions describe the downstream permissions that can change when a schema element changes, so they are useful for understanding blast radius and impact analysis across an authorization model.
The distinction matters because the two views support different reasoning styles. A backward dependency view helps you audit provenance and locate the relations that justify a permission. A forward computation view helps you predict the effect of modifying a rule, relation, or inherited condition before you deploy the change.
Practitioners often confuse the two when a schema mixes direct grants, inheritance, derived roles, and nested relations. In that case, the dependency graph may be stable while the computable set changes materially after a small schema edit. That is why schema analysis needs both the source logic and the propagation logic, not just one of them.
- Use dependent relations when you need to explain or review why a subject currently has access.
- Use computable permissions when you need to assess what access would move if the schema changes.
- Expect the first to be anchored in evidence of current structure, and the second to be anchored in change impact.
Why the distinction matters in authorization design and review
In authorization schema analysis, the backward view is stronger for recertification, ownership review, and troubleshooting unexpected access. It tells you which relations contribute to a permission, which is essential when you need to prove whether an entitlement came from direct assignment, inheritance, or a transitive rule.
The forward view is stronger for change management, policy refactoring, and regression testing. If you alter one schema element, computable permissions show which effective permissions may appear, disappear, or widen as a result. That makes it the right lens for estimating collateral impact before a deployment or migration.
Because authorization schemas can be expressive, a local edit may have non-local consequences. A single relation change can affect many permissions through nested logic, while a single permission may depend on multiple relations that are not obvious from the output alone. Reading both views together is the safest way to avoid over-trusting either provenance or propagation.
For broader identity and authorization governance, the same distinction helps teams keep effective access explainable. If the effective permission set is large or hard to trace, the analysis should also consider whether the schema creates hidden privilege pathways or over-broad inherited access, especially when permissions are reused across many objects or principals.
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Schema analysis directly supports reviewing and restricting effective permissions. |
| Recommendation — Map effective permissions to access reviews and remove unnecessary grants. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | The topic concerns how authorization logic establishes and changes access. |
| Recommendation — Use access-control governance to trace effective permissions and validate policy changes. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Authorization schemas often protect machine-access paths whose permissions must be explainable and bounded. |
| NHI-04 — Excessive Permissions | Computable permissions are central to spotting permission expansion from schema edits. | |
| NHI-06 — Lifecycle and Offboarding | Dependent relations help validate which access should disappear when relations are removed. | |
| Recommendation — Review machine-access permissions to ensure schema changes do not widen credential blast radius. Audit computed access for privilege creep and remove unnecessary effective permissions. Verify that schema removals actually revoke downstream access during offboarding or deprovisioning. | ||
Practitioner Guidance
What to verify: Before trusting a schema analysis result, verify whether you are looking at a proof of origin or a change-impact projection. If you need to explain existing access, insist on the dependent relations; if you need to approve a change, insist on the computable permissions for the modified element.
Decision rule: If the question is “why does this access exist?”, use dependent relations first. If the question is “what will this edit change?”, use computable permissions first. When both matter, compare them side by side so you can see whether the schema is creating access intentionally or merely producing it as a side effect.
What good looks like: The analysis should let a reviewer trace an effective permission back to its contributing relations and also simulate the impact of removing or modifying any one schema element without ambiguity. If either direction is hard to produce, the schema is probably too complex for safe manual review.
Practitioner takeaway: Dependent relations explain entitlement provenance, while computable permissions explain entitlement propagation, and mature authorization analysis needs both to keep access understandable and change-safe.
Related resources from NHI Mgmt Group
- What is the difference between RBAC and ABAC in Keycloak authorization design?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
