A can assume role edge is the explicit relationship showing that one identity can take on another role’s permissions. For AI agents, this edge is critical because it preserves accountability in the graph and prevents delegated privileges from being mistaken for native agent permissions.
Expanded Definition
A can assume role edge is the explicit graph relationship that shows one identity may take on another role’s permissions. In NHI governance, that distinction matters because the edge represents delegated authority, not native entitlement. It is the control point that lets practitioners reason about who can become what, under which conditions, and with what traceability.
Definitions vary across vendors when identity graphs are flattened into generic “access” labels, so NHI Management Group treats this as a first-class authorization relationship rather than a UI convenience. That matters for AI agents, service accounts, workload identities, and federated identities that may inherit privilege only at runtime. The edge should be paired with policy, approval, and observability so that role assumption is auditable and bounded. The concept aligns closely with NIST Cybersecurity Framework 2.0 principles for access governance, and with identity graph models used in modern NHI programs.
The most common misapplication is treating assumed permissions as if they were permanent identity attributes, which occurs when teams inventory effective access but fail to preserve the role-assumption path.
Examples and Use Cases
Implementing can assume role edges rigorously often introduces additional policy and telemetry overhead, requiring organisations to weigh cleaner accountability against more complex access design.
- An AI agent assumes a short-lived cloud role to query internal data, while the graph records the agent identity, the target role, and the approval path.
- A CI/CD workload assumes a deployment role only during a release window, then loses that access automatically when the job ends.
- A third-party integration assumes a support role for ticket resolution, but the edge is restricted to a narrowly scoped set of actions.
- A service account assumes a break-glass role during incident response, with alerts generated for every invocation and session replay retained for review.
- An identity team reviews whether role assumption paths are documented in the Ultimate Guide to NHIs model of lifecycle governance before expanding automation.
In practice, a role-assumption edge is most useful when combined with standards such as NIST Cybersecurity Framework 2.0 so that access assignment, monitoring, and review remain measurable rather than implicit.
Why It Matters in NHI Security
When this relationship is not tracked precisely, organisations lose the ability to distinguish standing privilege from delegated privilege. That can lead to false confidence in least privilege, failed attestations, and incomplete incident investigations. For NHI programs, the edge is also essential for proving whether an AI agent acted within an approved scope or merely appeared to have broad authority because effective permissions were collapsed into one record.
NHIMG research shows that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, which is why preserving delegated-authority paths is not optional. The same governance problem appears in broader NHI hygiene, as detailed in the Ultimate Guide to NHIs, especially where secrets, service accounts, and automation are left without clear ownership or review. Role assumption edges help security teams prove whether access was temporary, approved, and revocable, instead of assuming the identity itself was meant to hold that power.
Organisations typically encounter the impact after an access review, breach investigation, or privilege misuse event, at which point the can assume role edge 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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Role assumption edges define delegated access paths that must be tracked in NHI graphs. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access depends on separating native identity rights from assumed roles. |
| NIST Zero Trust (SP 800-207) | JIT | Zero Trust favors short-lived, verified role elevation over standing privilege. |
| NIST SP 800-63 | AAL2 | Assumed-role actions rely on the assurance of the authenticator used to obtain them. |
| CSA MAESTRO | Agentic systems need explicit delegation boundaries to keep autonomous actions accountable. |
Map assumed-role paths to access controls and validate them during periodic entitlement reviews.
