Relationship-based access control is exposing authN-authZ confusion

At a glance

What this is: This is a technical explanation of why authN and authZ should not be conflated, and why relationship-based access control gives permission systems a better model for fine-grained decisions.

Why it matters: IAM teams across human, NHI, and autonomous programmes should care because access logic that starts inside login systems tends to produce brittle governance, inconsistent policy interpretation, and hard-to-audit permission drift.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Authzed's explanation of ReBAC and fine-grained authorization

Context

Authentication tells you who or what the subject is. Authorization tells you what that subject may do, and those are different governance problems even when product documentation blurs them together. When teams let login primitives shape access control, they inherit whatever shortcuts those primitives were designed to support, not the policy precision the application actually needs.

For identity programmes, the warning is broader than application design. Human IAM, NHI governance, and autonomous access all fail when access decisions are forced into a one-size-fits-all identity attribute model. ReBAC matters because it treats the relationship itself as the policy surface, which is closer to how real permissions change over time.

The same pattern shows up in machine identity too. If you want a broader NHI governance reference, the Ultimate Guide to NHIs gives the lifecycle context that application developers often miss when they start with authN instead of authZ.

Key questions

Q: How should security teams separate authentication from authorization design?

A: Security teams should keep authentication focused on proving identity and move authorization into a dedicated policy layer that evaluates actions against resources. That separation prevents claims, scopes, and roles from becoming overloaded with business meaning. It also makes access reviews and policy changes easier to audit because permission logic is no longer hidden inside login systems.

Q: Why do relationship-based permissions work better than role-based permissions for complex apps?

A: Relationship-based permissions work better when access depends on ownership, delegation, inheritance, or changing collaboration patterns. Roles can be useful, but they often flatten real-world access into broad buckets that break down as applications grow. ReBAC keeps the meaning in the relationship itself, which reduces ambiguity and policy drift.

Q: What do teams get wrong when they use identity claims as access policy?

A: Teams often assume that a claim can answer the full question of whether a subject may act on a resource. In practice, claims only describe facts about identity, not the full context of action, object, and relationship. That shortcut creates inconsistent interpretations across services and makes authorisation bugs more likely.

Q: How do you know if a relationship-based access model is working?

A: A relationship-based model is working when access decisions stay consistent as relationships change, and when revocations take effect without code changes in every application. Teams should look for stable checks, clear audit trails, and reduced policy duplication across services. If policy meaning still varies by app, the model is not yet mature.

Technical breakdown

Why authN primitives produce brittle authZ design

Authentication systems are built to prove identity, not to express nuanced permission semantics. When roles, scopes, or claims become the source of truth for authorisation, developers must encode policy meaning into attributes that were never designed to carry it. That creates ambiguity when multiple attributes conflict, and it forces every application to interpret those attributes the same way or risk policy drift. In practice, the authorisation layer becomes a translation problem between identity data and access intent.

Practical implication: Keep authorization logic separate from login primitives so access meaning can be governed consistently across services.

How relationship-based access control changes the decision model

ReBAC answers a different question than RBAC or ABAC. Instead of asking whether a subject has a role or attribute, it asks whether there is a valid relationship path between a subject and a resource for a given action. That makes ownership, delegation, membership, and inheritance explicit rather than implied. The model is especially useful when permissions change often, because you update relationships instead of rewriting application logic or reinterpreting attribute semantics.

Practical implication: Model access as explicit subject-resource relationships when permissions are dynamic or deeply nested.

Why graph consistency matters in fine-grained permissions

A relationship graph only works if reads and writes stay consistent enough for policy evaluation to reflect current state. If the system evaluates stale relationships, access checks can succeed after revocation or fail after legitimate grants, which creates both security and usability problems. This is why modern relationship-based systems emphasize strongly controlled consistency semantics and scoped query patterns for checks, listings, and subject resolution. Fine-grained access is not just about expressiveness; it is about reliable evaluation.

Practical implication: Design for consistent policy reads, not just expressive policy definitions.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

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

NHI Mgmt Group analysis

AuthN and authZ confusion is a governance smell, not a syntax problem. When login systems are treated as permission engines, the organisation inherits identity attributes that only describe the subject, not the action. That is a structural failure in policy design because access meaning gets compressed into claims that were never intended to carry business rules. Practitioners should treat this as a separation-of-duties issue inside the identity architecture itself.

Relationship-based access control is the better abstraction for dynamic identity programmes. ReBAC gives identity teams a way to represent ownership, delegation, and inheritance directly instead of encoding them indirectly through roles or claims. That matters across human, NHI, and service-to-service access because permissions change as relationships change. The practical conclusion is that policy should be evaluated from graph state, not from whatever happened to be present at login time.

Permission semantics drift: the broken assumption is that identity attributes can reliably express authorisation meaning. That assumption was designed for simple subject facts, not for multi-step access logic or cross-resource inheritance. It fails when teams expect claims to decide action intent without a dedicated policy layer, and the implication is that auditability depends on a model that keeps access meaning separate from identity proof.

Lifecycle governance still matters even when authorisation is relationship-driven. ReBAC can make permissions cleaner, but it does not remove the need to manage joins, moves, leaves, and revocation across subjects and resources. For NHI programmes in particular, relationship cleanup becomes the practical control point because stale links can outlive the business relationship that justified them. Teams should see ReBAC as a governance enabler, not a governance substitute.

This model has cross-domain value because it reduces translation work across identity types. Human access, service account access, and delegated application access all become easier to audit when policy is expressed as a relationship instead of an inferred attribute. That makes ReBAC especially relevant for organisations trying to standardise identity governance without forcing every application into the same access vocabulary. Practitioners should use it where permission interpretation, not authentication, is the real source of risk.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• Only 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Relationship-based access still needs lifecycle discipline, as shown in 52 NHI Breaches Analysis.

What this signals

Permission architecture is becoming an identity governance issue, not just a developer convenience issue. As applications accumulate more human, service, and delegated access paths, teams that keep authorization logic inside authN primitives will struggle to audit or standardise policy. The practical shift is toward clearer ownership of policy semantics, especially where relationship data changes faster than release cycles.

For NHI programmes, the unresolved problem is not whether access exists but whether it can be explained. If you cannot trace a service account’s effective permissions through relationships and lifecycle events, you do not have governance, only accumulated entitlement state. That is why identity programmes need policy evaluation models that remain readable after systems scale.

Relationship models are most valuable when paired with lifecycle controls and visibility tooling. The biggest operational gain comes when access can be described, reviewed, and revoked without reinterpreting every application’s local rules. In practice, that means tightening entitlement lifecycle processes while aligning them to the access graph rather than to isolated application defaults.

For practitioners

• Separate authentication from authorization ownership Keep login, federation, and identity proofing distinct from access policy design. Assign a dedicated authorization layer or service so application teams do not encode permission semantics directly into claims, scopes, or groups.
• Model permissions as explicit relationships Represent ownership, membership, delegation, and viewer relationships as first-class policy objects. This makes access intent auditable and prevents developers from inventing custom meaning for every attribute combination.
• Test policy consistency after every relationship change Validate that grants and revocations are reflected consistently across check, list, and subject-resolution paths. ReBAC only stays trustworthy when recent changes are visible before downstream decisions are made.
• Map NHI and human lifecycle events to the same revocation discipline Use joiner-mover-leaver logic to remove obsolete relationships when accounts, service identities, or delegated access links change. The control objective is to prevent stale permissions from surviving the business relationship that created them.

Key takeaways

• Authentication proves identity, but it does not reliably explain authorisation, which is why conflating the two creates brittle access systems.
• Relationship-based access control improves fine-grained governance by expressing ownership, delegation, and inheritance directly instead of hiding them inside claims.
• The operational test is not whether permissions are expressive, but whether they remain consistent, auditable, and revocable as relationships change.

Key terms

• Relationship-Based Access Control: A permission model that decides access by evaluating relationships between a subject and a resource. Instead of relying only on static roles or broad claims, it asks whether a valid path exists for a specific action. That makes delegation, ownership, and inheritance explicit and easier to govern.
• Authentication: The process of proving that a subject is who or what it claims to be. Authentication establishes identity, but it does not by itself determine whether the subject should be allowed to act on a resource. In mature identity programmes, it is the starting point, not the access decision.
• Authorization: The process of deciding whether a subject may perform an action on a resource. Authorization uses policy, relationships, context, and business rules to reach that decision. It should be separated from authentication so permission meaning does not get trapped inside login constructs.

Deepen your knowledge

Relationship-based access control and fine-grained authorization are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are separating authentication from authorization in a mixed human and machine identity environment, it is worth exploring.

This post draws on content published by Authzed: Relationship-based access control and the authN-authZ split. Read the original.