ReBAC

Expanded Definition

ReBAC, or relationship-based access control, authorises access by evaluating how a subject is connected to a resource through one or more intermediate relationships. In NHI environments, that often means a service account, workload, or AI agent is allowed to act because it belongs to an approved graph path, not because it matches a broad role label.

Compared with RBAC, ReBAC is better suited to delegated access, tenancy boundaries, resource ownership, and multi-step trust relationships. In practice, it is often paired with policy engines and graph lookups so the decision can be made at request time. Definitions vary across vendors on how much path complexity is acceptable, so the operational question is less about the label and more about how consistently the relationship graph is maintained. For a broader NHI governance view, see Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0 for access governance context.

The most common misapplication is treating ReBAC as a cleaner version of RBAC, which occurs when teams encode static roles as relationships and then let the graph grow without ownership or review discipline.

Examples and Use Cases

Implementing ReBAC rigorously often introduces graph-maintenance and latency overhead, requiring organisations to weigh precise delegation against the cost of traversing and validating relationship chains at runtime.

• A CI/CD service account can deploy only to repositories it is linked to through an approved ownership chain, rather than inheriting a broad platform role.
• An AI agent can read a ticket only when it is related to a support queue, a customer record, and a scoped workflow policy that all resolve positively.
• A partner workload can call an internal API only if a trust relationship exists between the partner tenant, the integration app, and the target data domain.
• A secrets broker can issue a short-lived token only when the requesting workload is related to a specific namespace and a current deployment event.

These patterns are easiest to reason about when the relationship model is documented and aligned to lifecycle controls described in Ultimate Guide to NHIs. For implementation language around policy evaluation and access decisions, NIST Cybersecurity Framework 2.0 remains a useful external anchor.

Why It Matters in NHI Security

ReBAC becomes critical when service identities, API keys, and AI agents need access that changes with organisational structure, data ownership, or workflow context. If those relationships are stale, duplicated, or implicitly trusted, access can expand silently across tenants, pipelines, and tool chains. That is especially dangerous in NHI estates, where NHIs outnumber human identities by 25x to 50x in modern enterprises, and relationship drift can multiply quickly across thousands of machine-mediated permissions.

NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which makes relationship-driven access especially hard to audit. ReBAC therefore matters not only for precision, but for explainability: responders must be able to answer why a token, workload, or agent had access at a given moment. The control challenge is to keep the graph current, reviewed, and revocable as systems change. See the Ultimate Guide to NHIs for the governance context and the NIST Cybersecurity Framework 2.0 for a broader risk-management frame.

Organisations typically encounter the need for ReBAC only after a workload, API key, or agent is over-permissioned during an incident, at which point relationship tracing becomes operationally unavoidable to address.