A permissioned data change that records who can access a resource through an explicit relationship model. It matters in fine-grained authorization because creating a resource often requires writing ownership or sharing relationships at the same time.
Expanded Definition
Relationship Write is the authorization action that creates or updates a relationship edge, such as “service account can access dataset” or “agent may act on behalf of user.” In fine-grained authorization systems, the write itself is security-sensitive because it determines who can later read, modify, or delegate access through relationship checks. This is distinct from a normal data write: the object being changed is the access graph, not merely a business record.
In NHI environments, Relationship Write commonly appears in systems that model ownership, sharing, delegation, consent, or impersonation through tuples or graph edges. Definitions vary across vendors, but the core idea is consistent: an authenticated actor must be allowed to create a durable authorization relationship, and that action should be tightly scoped, auditable, and often tied to policy enforcement. NIST’s NIST Cybersecurity Framework 2.0 supports this kind of control through identity, access, and governance outcomes.
The most common misapplication is treating relationship creation as a routine application write, which occurs when developers fail to separate business data permissions from authorization graph permissions.
Examples and Use Cases
Implementing Relationship Write rigorously often introduces extra policy checks and audit overhead, requiring organisations to weigh safer delegation against slower request paths.
- A file-sharing service writes an ownership edge when a user uploads a document, then writes a second edge to permit a teammate to access it.
- An AI agent records a relationship that allows it to act on behalf of a human for a narrowly defined task, rather than granting broad standing access.
- A CI/CD platform creates a relationship edge when a deployment service account is approved to read a specific secret or repository.
- A healthcare workflow writes a temporary sharing relationship for a specialist, then removes it after the consultation window closes.
- An access platform uses relationship writes to model group membership, tenant scoping, or delegated administration instead of hardcoding permissions.
These patterns align with the lifecycle and access governance concerns described in the Ultimate Guide to NHIs, especially where service accounts and API keys are involved.
Why It Matters in NHI Security
Relationship Write becomes critical because a single improper edge can expose far more than one record. If an attacker or over-privileged agent can create access relationships, they can silently expand reach across datasets, secrets, or administrative functions. In NHI environments, that risk is amplified because machine identities often operate at scale, and each relationship may be reused automatically by applications, pipelines, or agents. NHIMG reports that 97% of NHIs carry excessive privileges, which makes relationship-level controls especially important when deciding who can grant access to whom.
Practitioners should treat relationship creation as a privileged security event, not a low-friction app function. The control should be logged, narrowly authorized, and reviewed for abuse paths such as self-granting, privilege escalation, and unintended inheritance across tenants or resource hierarchies. When relationship writes are missing or weak, incident response also becomes harder because investigators cannot tell whether access came from a legitimate grant or an unauthorized graph mutation. Organisationally, this issue often surfaces only after an access review, breach investigation, or failed least-privilege audit, at which point relationship write governance becomes operationally unavoidable to address.
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 CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Relationship writes control how non-human identities gain or propagate access. |
| NIST CSF 2.0 | PR.AC-4 | This term maps to managing access permissions through enforced authorization decisions. |
| NIST Zero Trust (SP 800-207) | PA-3 | Zero Trust requires policy decisions to govern access relationships continuously. |
Authorize and log every access-graph mutation that grants, delegates, or revokes NHI permissions.
Related resources from NHI Mgmt Group
- How should security teams govern AI tools that write into workspace settings?
- Who is accountable for third-party access when a vendor relationship ends?
- How do security teams decide whether HRIS write-back is safe in joiner automation?
- What breaks when a document parser can write files outside its temp directory?
