Graph engineering exposes the governance gap in multi-agent systems

At a glance

What this is: This is an analysis of graph engineering for multi-agent systems, with the key finding that governance breaks when identity, policy, and observability are attached to ad hoc orchestration instead of the graph itself.

Why it matters: IAM, PAM, and NHI teams need to understand this because multi-agent systems are beginning to distribute authority, tool access, and audit responsibility across graph structures rather than single bounded workflows.

Context

Graph engineering is the practice of treating a multi-agent system as an explicit graph of heterogeneous nodes, with permitted transitions, ownership, and runtime flow designed rather than inferred after the fact. In the article’s framing, the primary governance gap is that current identity and access models still expect stable operators and clearly bounded ownership, while graph-based delegation can shift authority across agents, routers, functions, and checkpoints inside the same runtime.

For identity programmes, the significance is not that multi-agent systems are new, but that their control surface is becoming graph-shaped. That changes how teams reason about policy enforcement, audit correlation, and human checkpoints because the thing being governed is no longer a single agent loop or a single tool call, but a mutable work graph with distributed responsibility.

Key questions

Q: What breaks when graph topology is not governed in a multi-agent system?

A: When topology is left implicit, delegation becomes an emergent side effect rather than an approved control. That breaks accountability, because teams can no longer say which node was allowed to do what, or which edge moved work into a higher-risk path. The result is a system that may function technically while remaining impossible to govern with confidence.

Q: Why are browser extensions a problem for IAM and NHI teams?

A: Because extensions can operate inside authenticated sessions and reach cookies, tokens, and page data that IAM may not directly see. That creates a blind spot where a user remains properly authenticated while the extension acts as a hidden access path. NHI teams should treat this as session abuse risk, not only endpoint risk.

Q: How do security teams know if agent observability is actually working?

A: Observability is working only when teams can tie together token activity, tool calls, and latency for a specific agent session. If those signals are disconnected, the logs may show traffic but not governance. The test is whether investigators can reconstruct the path of a meaningful agent action from start to finish.

Q: When should teams add human approval to agentic workflows?

A: Add human approval when an agent can access secrets, modify production code, touch multiple repositories, or execute commands that are hard to roll back. Human review is most useful at the point where the agent crosses from analysis into action. That is where blast radius matters most.

Technical breakdown

Graph topology and delegated authority

A graph-engineered multi-agent system separates topology from execution. Topology defines which nodes exist, what each node may do, and which transitions are allowed; execution is the loop inside each agentic node. That distinction matters because the orchestrator can route work, enforce edges, and preserve runtime state even when individual nodes change model, tools, or task order. In practice, the graph becomes the governance unit, while the node becomes the execution unit. This is also why deterministic functions, routers, joins, and human checkpoints cannot be treated as if they were all agents. They may participate in delegation, but they do not all carry the same identity or accountability requirements.

Practical implication: Treat the graph as the policy boundary and assign identity and permissions by node type, not by the presence of AI alone.

Identity propagation across graph runs

Multi-agent graphs need correlated identity because auditability disappears when the system can no longer explain who acted, on which run, under which node, and through which tool path. The article’s architecture discussion points to resolved identities, virtual accounts, and propagated graph, run, and node identifiers as the way to keep model calls and MCP tool invocations attributable. Without that propagation, the graph may be operationally functional but governance blind. The core technical issue is not simply authentication at the gateway. It is the preservation of identity context across delegation chains so that policy, cost, and evidence can be joined after the fact.

Practical implication: Propagate stable graph, run, and node identifiers through every governed call so audit trails remain attributable.

Observability and control at the gateway boundary

The article treats the gateway as the control plane for model requests and MCP tool invocations, with policy, guardrails, budgets, rate limits, and telemetry all applied at that boundary. This is important because graph-scale systems create more than one kind of risk. They create correlation risk when traces fragment, policy risk when tool reach expands beyond mandate, and operational risk when fan-out or retries multiply hidden cost and exposure. The runtime therefore needs both decision-time control and post-execution evidence. Observability is not just tracing. It is the ability to reconcile intended graph structure with the work that actually ran.

Practical implication: Instrument gateway enforcement and runtime traces together so delegated work can be checked against authorised graph structure.

Threat narrative

Attacker objective: The practical objective is to exploit delegation complexity so that authority expands faster than oversight and accountability can track it.

1. Entry occurs through legitimate graph construction, where a node is given model access, tool access, or delegated work as part of system design rather than through exploitation.
2. Escalation happens when runtime fan-out, retries, or dynamically spawned subtasks broaden the effective authority of the graph beyond the original node-level intent.
3. Impact is the loss of attribution and governance clarity, because policy, cost, and tool use can no longer be reliably tied back to the run, node, or responsible owner.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Graph engineering is really a governance model, not just an orchestration pattern. The article is useful because it makes the topology itself visible: nodes, edges, checkpoints, and transitions are all policy-bearing objects. That matters for identity teams because delegation now happens across a mutable work graph instead of a single workflow. Practitioners should therefore stop treating orchestration as a plumbing concern and start treating graph shape as a control decision.

Identity must travel with the graph if auditability is to survive delegation. The article’s emphasis on resolved identities, graph_id, run_id, and node_id reflects a basic control truth: without correlated identity context, a distributed system can execute correctly and still be ungovernable. That is especially relevant for NHI and agentic AI programmes, where the control problem is less about login and more about traceable authority. Practitioners should design for identity continuity across every hop.

Human checkpoints become more valuable, not less, when graphs get denser. The more a system fans out across agents, routers, tools, and joins, the more important it becomes to place approval at the edges where consequence concentrates. This is not a call for manual bottlenecks everywhere. It is an argument that governance should be selective and structural, with human review reserved for edges that materially change risk. Practitioners should map those edges explicitly.

Work graphs create an identity blast radius that classic IAM did not model. A permission granted to one node can be multiplied by retries, dynamic subtasks, or downstream delegation, creating a wider exposure surface than provisioning records suggest. That is the specific governance gap graph engineering exposes. Practitioners should re-evaluate whether access reviews, tool scoping, and accountability mappings still reflect runtime behaviour rather than just design-time intent.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Graph engineering turns delegation into a policy problem. Once work is routed through agents, routers, joins, and human checkpoints, the old assumption that authority lives in a single account or workflow stops holding. Programme owners should expect more demand for node-level attribution, edge-level approval, and runtime evidence that matches the designed topology.

Identity blast radius is the right phrase for this pattern. The article shows that one node’s authority can expand through fan-out, retries, and dynamically spawned subtasks, which means access reviews need to account for behaviour at runtime, not just roles at provisioning time. Teams that only review static entitlements will miss the practical exposure created by the graph.

Governance will increasingly follow runtime identifiers. Stable graph, run, and node identifiers are becoming the bridge between orchestrator intent and gateway evidence, and that bridge is what makes AI gateway telemetry useful for security and audit. Teams that cannot propagate those identifiers will struggle to prove what happened, even when the system was operating as designed.

For practitioners

• Define the graph as the governance boundary Inventory which nodes are agents, deterministic functions, routers, joins, tools, and human checkpoints, then assign policy by node class and edge permission.
• Propagate stable runtime identifiers Carry graph_id, run_id, and node_id through model calls and MCP tool invocations so every action can be correlated back to the orchestrator trace.
• Separate gateway policy from orchestrator intent Use gateway controls for model and tool traffic, but keep the orchestrator as the source of truth for topology, ownership, and execution state.
• Place human approvals at high-consequence edges Identify transitions where tool use, data access, or delegation materially changes risk, and require approval only at those structural checkpoints.
• Review audit models for graph-shaped delegation Test whether current IAM and NHI reviews still explain fan-out, retries, and dynamic subtasks, or whether they only describe the original request.

Key takeaways

• Graph engineering exposes a governance gap because multi-agent systems now distribute authority across a mutable work graph, not a single loop or account.
• The practical control problem is attribution: identity, policy, and observability have to move with the graph if teams want to explain runtime delegation.
• Security teams should review topology, runtime identifiers, and checkpoint placement together because graph shape now determines the real blast radius.

Key terms

• Graph Engineering: The design and governance of a multi-agent system as an explicit topology of nodes and edges. In practice, it means deciding which entities exist, what each owns, and what transitions are permitted so runtime work is controlled as a graph rather than an accidental chain of calls.
• Work Graph: 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.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.