The runtime path that work follows across agents, deterministic functions, routers, tools, and human checkpoints. It is the operational reality of delegation, and in governed environments it must be treated as evidence-bearing infrastructure, not just an implementation detail.
What a Work Graph Represents
A work graph is the live execution map of how a task moves through an operating environment, showing which agent, function, router, tool, or human checkpoint handled each step and in what order.
Unlike a static workflow diagram, it captures what actually happened at runtime. That makes it useful for understanding delegation, control handoffs, approval points, and where work changed direction or was paused.
Why Work Graphs Matter
Work graphs turn execution into something you can inspect and reason about after the fact. For governed systems, that is important because delegation is not just a design choice, it is an operational event that may need to be explained, reviewed, or audited.
They also help distinguish intended orchestration from emergent behaviour. If a task was rerouted, retried, escalated, or delegated to a human, the work graph shows the real path rather than the idealised one.
What A Work Graph Contains
A useful work graph usually records nodes for actors and services, edges for handoffs, and checkpoints for policy or human review. In practice, it may also include timestamps, decision reasons, tool invocations, and the outcome of each branch.
The value comes from preserving sequence and causality. If an agent called a tool, a router sent the task elsewhere, and a person approved the result, the graph should make that chain visible without requiring reconstruction from scattered logs.
How Work Graphs Support Governance And Review
Work graphs are most valuable when the organisation needs evidence, not just automation. They help teams trace ownership, validate that a task stayed within approved boundaries, and understand whether a delegated action followed the expected path.
They also make it easier to compare policy with reality. A system may be designed for one approval chain, but the work graph can reveal shortcuts, silent reroutes, or repeated detours that weaken control even when the final output appears correct.
Risk and Threat Considerations
Work graphs can expose governance gaps when the recorded path diverges from the approved one, especially if delegation is implicit, approvals are bypassed, or tool use is not fully visible. They can also become a source of sensitive operational intelligence if the graph is over-shared.
Failure mechanism: The system records incomplete, altered, or misleading execution paths, so reviewers cannot reliably tell who or what actually performed a step, where authority changed hands, or whether a checkpoint was honoured.
Impact: Control assurance degrades, investigations become harder, and an attacker or insider may be able to conceal misuse of delegated access, hidden routing, or unauthorised task execution.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Work graphs depend on recorded execution events and handoffs. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Work graphs are only useful when teams review the captured execution trail. | |
| AC-6 — Least Privilege | Work graphs reflect delegation paths that should be constrained by minimal authority. | |
| Recommendation — Log delegation, tool use, and approval transitions needed to reconstruct the work graph. Review work-graph records for bypassed checkpoints, anomalous routing, and missing handoffs. Restrict each actor or tool to the minimum authority required for its step in the graph. | ||
| NIST CSF 2.0 | DE.CM-09 — Monitoring for Unauthorized Activity | A work graph helps detect deviations from approved execution paths. |
| Recommendation — Monitor runtime paths for unauthorized rerouting, tool misuse, and unexpected human intervention. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | Work graphs rely on logs that preserve operational evidence of how work moved. |
| Recommendation — Retain logging that captures task routing, approvals, and tool execution evidence. | ||
Practitioner Guidance
What to watch for: Treat the work graph as governed telemetry, not decorative metadata. The key question is whether it is sufficiently complete and trustworthy to support review of delegation, approval, and escalation decisions.
Governance implication: Define which handoffs, tool calls, and human interventions must be captured, who can view the graph, and how long it must be retained. A work graph that exists but cannot be trusted, queried, or audited is only partial evidence.
Related resources from NHI Mgmt Group
- What breaks when a single agent loop is asked to do graph-level work?
- How should security teams use asset graph views to prioritize remediation work on exposed devices and paths to the internet?
- How can organisations decide whether graph-based data intelligence is worth using for governance work?
- What are the signs that Graph Explorer is being used beyond normal admin work?