A stored record that connects a resource, a relation, and a subject in the authorization graph. Relationship tuples are the live data that make schema rules meaningful, because access checks depend on them being current. If tuples are stale or missing, effective permissions no longer match the real system state.
Expanded Definition
A relationship tuple is the atomic authorization record that ties a subject to a relation on a resource inside an authorization graph. In graph-based access control models, the tuple is what makes a schema rule executable: the schema defines possible relationships, while the tuple states which relationships currently exist. This distinction matters because access decisions are evaluated against live tuples, not against policy intent alone.
Usage is still evolving across vendors and open-source authorization systems, but the core idea is consistent. A tuple can express that a service account can administer a workload, that an agent can invoke a tool, or that a team can read a dataset. For the NHI domain, tuples are especially important because non-human identities often change faster than human role structures, and their permissions may be created, delegated, or revoked by automation. The practical reference point for governance is whether the tuple set accurately reflects current business and security state, not whether a rule exists in documentation. This aligns with broader control objectives in the NIST Cybersecurity Framework 2.0 around access control and asset visibility.
The most common misapplication is treating a relationship tuple as a static role assignment, which occurs when teams assume schema definitions alone enforce access without validating the live graph.
Examples and Use Cases
Implementing relationship tuples rigorously often introduces operational overhead, requiring organisations to balance authorization precision against the cost of keeping graph data current.
- A workload identity tuple grants a CI/CD agent permission to deploy only to a specific namespace, rather than to the entire cluster.
- A tuple records that a microservice may read from one storage bucket but not write to it, preserving least privilege at the resource edge.
- An agentic AI system uses tuples to determine which tools it may call, separating approved execution paths from blocked ones.
- A security team removes stale tuples during offboarding so an API key does not retain access after the owning integration is retired.
- An access review compares current tuples with expected business relationships to detect privilege creep and orphaned access.
These patterns are easiest to understand when paired with operational NHI guidance such as the Ultimate Guide to NHIs and identity governance models described in the NIST Cybersecurity Framework 2.0. In practice, tuple design should be narrow, explicit, and easy to revoke.
Why It Matters in NHI Security
Relationship tuples are where authorization becomes real. If they are stale, overbroad, or missing, the system can either deny legitimate automation or, worse, allow access that no longer matches the actual trust relationship. That failure mode is especially dangerous for NHIs because service accounts, API keys, workload identities, and agents often outnumber human identities by 25x to 50x in modern enterprises, increasing the likelihood that tuple drift goes unnoticed until an incident occurs. The same Ultimate Guide to NHIs also notes that only 5.7% of organisations have full visibility into their service accounts, which makes tuple accuracy a governance problem, not just a developer concern.
Mismanaged tuples also undermine Zero Trust Architecture because continuous evaluation depends on the authorization graph reflecting reality. If an agent still appears connected to a tool after its task is complete, the tuple becomes a latent exposure point. Likewise, incident response teams need tuple history to explain why access was granted and when it should have been removed. The practitioner lesson is that relationship tuples matter most after a breach, privilege escalation, or failed offboarding exposes how much access the live graph still contains.
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 NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Relationship tuples encode live NHI authorization paths and expose stale access risk. |
| NIST Zero Trust (SP 800-207) | AC-1 | Zero Trust relies on continuously evaluated, current authorization relationships. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed as current, auditable relationships. |
Review tuple freshness and revoke any NHI access path that no longer matches the intended relationship.
Related resources from NHI Mgmt Group
- Who is accountable for third-party access when a vendor relationship ends?
- How should security teams handle third-party NHI access that outlives the vendor relationship?
- What do teams get wrong about RBAC, ABAC, and relationship-based access control?
- When should teams re-evaluate a verification vendor relationship?
