The set of agent-to-agent handoffs that shows which system passed payloads, instructions, or context to another system. It matters because each edge can change jurisdiction, processor identity, and accountability even when the source authentication looks valid.
Expanded Definition
A delegation graph is the record of how authority, context, or workload moves between systems, especially when one NIST Cybersecurity Framework 2.0 control boundary gives way to another through an automated handoff. In agentic AI and NHI-heavy environments, that handoff may involve prompts, tokens, secrets, tool permissions, session context, or downstream instructions rather than a simple user login. The graph matters because the visible sender is not always the effective decision-maker once an agent relays work onward.
Definitions vary across vendors, but the core security idea is consistent: every edge in the graph represents a delegation event that can alter accountability, data handling, and blast radius. A clean graph should show who initiated the transfer, what was transferred, which identity was active, and what authority the receiving system inherited. For NHI Management Group, the important distinction is between ordinary message routing and actual delegated power, since only the latter creates security and governance implications. This is closely related to OWASP guidance for agentic systems, where tool use and instruction passing can expand risk if boundaries are not explicit.
The most common misapplication is treating any downstream API call as a delegation edge, which occurs when engineers fail to distinguish transport from transferred authority.
Examples and Use Cases
Implementing delegation graph tracking rigorously often introduces observability and policy overhead, requiring organisations to weigh traceability against added system complexity.
- An AI assistant forwards a customer request to a billing agent, and the graph records the original prompt, the receiving agent, and the scope of action inherited.
- A privileged automation service hands a short-lived secret to another workflow, creating a visible chain of custody for the credential.
- An orchestrator assigns a subtasks queue to a specialist agent, but only one branch is permitted to invoke external tools, so the graph captures that constraint.
- A human operator approves a software action and an agent re-delegates part of the task to a downstream service, making the operator’s role indirect but still relevant.
- A cross-domain workflow passes context from one jurisdiction to another, and the graph reveals where control obligations may shift even though authentication succeeded.
These use cases align with the way NIST describes governance, traceability, and control mapping in the NIST Cybersecurity Framework 2.0, even though the framework does not name delegation graphs directly. In practice, teams use the graph to answer who delegated what, to whom, under which policy, and for how long.
Why It Matters for Security Teams
Security teams need delegation graphs because modern attack paths often exploit hidden trust transfer rather than direct compromise. If an agent inherits access from another agent, or a workflow silently passes secrets and instructions across a boundary, the original approval may no longer reflect the effective risk. That is why the term sits at the intersection of identity governance, AI security, and NHI oversight. It helps teams see where OWASP style prompt and tool abuse can become an operational access problem, and where authorization records fail to explain actual execution authority.
For defenders, the practical value is in answering audit and incident questions quickly: which system had authority at the moment of action, and which upstream delegation created that authority. Without that lineage, policy enforcement becomes guesswork, especially when secrets, API keys, or task context are reused across autonomous components. Delegation graphs also support least privilege and separation of duties by showing where inherited authority outlives its purpose.
Organisations typically encounter the need for a delegation graph only after an investigation shows that a valid source identity was not the system that actually caused the harmful action, at which point the graph becomes operationally unavoidable to reconstruct accountability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | CSF 2.0 emphasizes governance and oversight of security-relevant workflows. |
| OWASP Agentic AI Top 10 | OWASP Agentic guidance addresses tool use, delegation, and authority boundaries in AI systems. | |
| OWASP Non-Human Identity Top 10 | NHI security depends on tracing how machine identities pass secrets and permissions between systems. | |
| NIST AI RMF | AI RMF governance and map functions support accountability for AI system behavior and delegation. | |
| NIST SP 800-63 | AAL2 | Digital identity assurance informs whether delegated actions remain tied to strong authentication. |
Verify that delegated actions preserve required assurance before trust is extended to another system.
