Graph engineering exposes the governance gap in multi-agent systems

At a glance

What this is: Graph engineering treats a multi-agent system as a designed work graph, and the key finding is that topology, identity, and tool policy have to be governed together.

Why it matters: That matters because IAM, NHI, and agentic AI teams now have to govern delegation paths, runtime identities, and approval points as one control surface instead of separate silos.

👉 Read TruFoundry's analysis of graph engineering for multi-agent systems

Context

Graph engineering is the practice of designing a multi-agent system as an explicit work graph, with nodes such as agents, functions, routers, joins, tools, and human checkpoints. The governance problem is that once runtime work becomes graph-shaped, identity and access can no longer be treated as a per-agent concern only.

The primary identity security question is how to govern model and MCP tool operations when delegation, fan-out, retries, and approval gates are all part of the same execution path. For IAM and NHI programmes, the shift is from securing individual identities to securing the paths those identities can traverse.

This article is an enterprise architecture synthesis, not a breach report. Its starting position is typical of the current market: teams are trying to make agent orchestration observable and governable before the operating model hardens.

Key questions

Q: How should security teams govern identities in a multi-agent graph?

A: Teams should govern the graph as the primary security object, then assign identity, policy, and observability to each governed node. That means mapping resolved identities, permitted transitions, and tool access for every node that can act independently or trigger downstream work. If the graph is not explicit, accountability collapses when delegation fans out.

Q: Why do AI agents complicate existing IAM and NHI governance models?

A: AI agents complicate governance because access is no longer confined to a single environment or a single identity type. An agent may need cloud runtime permissions, customer data access, and tool-level OAuth tokens at the same time, which means standing privilege and lifecycle assumptions break down fast. That is why one control model rarely covers the full path.

Q: What breaks when graph-based orchestration has no stable node identifiers?

A: Auditability breaks first, followed by cost attribution, policy correlation, and incident reconstruction. Without stable node identifiers, the system may still execute, but the organization cannot reliably explain which component did what or which transition introduced the risky action. That makes detection and remediation much weaker.

Q: Which control matters most when AI gateways mediate model and tool use?

A: The most important control is explicit scoping of which node may reach which tool, combined with approval gates on the highest-consequence transitions. That keeps gateway policy aligned with graph topology instead of assuming generic access control will be sufficient for dynamic delegation.

Technical breakdown

Graph engineering vs loop engineering in multi-agent systems

Graph engineering describes the topology of the system: which nodes exist, how they connect, and which transitions are allowed. Loop engineering describes how an individual agent executes once it is running, including reasoning, tool use, stopping conditions, and verification steps. The distinction matters because a strong loop does not fix a weak graph, and a well-designed graph cannot compensate for an uncontrolled node. In practice, the graph becomes the governance layer above agent loops, while the loop remains the execution layer inside each node.

Practical implication: govern both the node runtime and the permitted transitions between nodes, or the overall system will still drift out of policy.

Identity propagation across graph nodes and MCP tool calls

In a graph-based system, identity cannot stop at the orchestrator. Each governed node may need a resolved identity, while model requests and MCP tool invocations need stable graph, run, and node identifiers so activity can be attributed after the fact. This is what turns an agent graph into an auditable system rather than a black box of delegated actions. The core architectural issue is that the graph itself does not inherit trust automatically; every hop needs explicit policy and correlation.

Practical implication: require propagated identifiers and node-specific authorization if you want auditability, cost allocation, and tool governance to survive runtime delegation.

Why approval checkpoints matter at graph boundaries

Human checkpoints become more important when placed at structural boundaries where consequence concentrates, such as sensitive tool calls, high-impact joins, or graph branches that can fan out quickly. In a graph, a single approval gate can protect an entire delegation path if it is positioned at the right edge. That is different from sprinkling approvals throughout the system, which often adds friction without reducing meaningful risk. The architectural goal is to align control points with the topology that actually creates exposure.

Practical implication: place approval gates at high-consequence edges, not everywhere, so governance follows the graph rather than fighting it.

NHI Mgmt Group analysis

Graph engineering is becoming the missing governance layer between orchestration and identity. The article shows that multi-agent systems are no longer just prompt chains or isolated loops. Once the runtime becomes a graph of heterogeneous nodes, the identity question shifts from 'who can call the model' to 'which path can this identity traverse, and what can it trigger along the way.' Practitioners should treat the graph as the governed object, not the agent alone.

Resolved identity for every governed node is the minimum viable control. The article's model depends on stable graph, run, and node identifiers, plus explicit identities for governed callers. That aligns with NHI governance reality: attribution, cost, and policy enforcement all fail when the runtime cannot be tied back to a specific execution context. The practical conclusion is that graph observability and identity provenance have to be designed together.

Graph-scale delegation exposes a tool-governance blind spot in current IAM thinking. Traditional access models assume a relatively stable subject and a bounded set of permissions. In graph engineering, node behavior can fan out, retry, and spawn downstream work, which means the effective access path changes during execution. That makes tool policy, not just identity assignment, the real control surface for AI gateway and MCP governance.

Human checkpoints should be treated as structural controls, not universal friction. The article is strongest when it frames approval gates as edge controls that protect the highest-consequence transitions. That is the right pattern for NHI and agentic AI programmes as well: control should be concentrated where runtime consequence concentrates. Teams should map approvals to graph boundaries, not just to generic risk categories.

Named concept: graph topology governance. This is the discipline of controlling who exists in the system, how they connect, and which transitions are permitted at runtime. It matters because once graph topology becomes mutable, the security problem is no longer only access management but controlled delegation. Practitioners need governance that can follow topology changes as first-class identity events.

From our research:

• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why graph-level identity correlation matters when multiple nodes can act on behalf of the same workflow.
• For a broader lifecycle view, the Ultimate Guide to NHIs shows why visibility, rotation, and offboarding have to extend across every governed node.

What this signals

Graph topology governance will become a standard requirement for teams running multi-agent systems. As soon as agents, routers, tools, and human approvals operate in one execution graph, identity teams need to review transitions, not just entitlements. The operational question becomes whether the orchestrator can prove who acted, when, and under which node identity.

The next programme maturity step is correlation between the orchestrator and the gateway. That means comparing execution traces with policy outcomes, cost records, and tool calls so that delegated work can still be reconstructed after the fact. For teams already wrestling with service account sprawl, this is a familiar problem in a new runtime shape.

For practitioners

• Map the governed graph, not just the agents Inventory every node type in the multi-agent system, including deterministic functions, routers, joins, tools, and human checkpoints. Record which nodes are governed separately, which inherit the orchestrator identity, and which transitions are permitted between them.
• Propagate stable execution identifiers Require graph_id, run_id, and node_id to accompany model requests and MCP tool calls so gateway logs can be correlated with orchestrator traces. Without that correlation, attribution, cost analysis, and incident review break down at runtime.
• Apply node-specific tool policy Scope tools by node mandate instead of assuming the entire graph should inherit the same MCP access. Use explicit registry configuration for tool-level restrictions and review any node that can reach multiple sensitive tools.
• Place approval gates at high-consequence edges Identify the graph transitions where sensitive actions, external side effects, or downstream fan-out create the highest exposure. Put human approval checkpoints there, rather than adding approval friction to low-risk internal steps.
• Correlate gateway records with orchestrator traces Treat gateway metrics, request logs, and policy outcomes as one evidence set, then compare them with the orchestrator's execution trace. That gives you a defensible view of what the graph intended to do versus what actually ran.

Key takeaways

• Graph engineering shifts the security problem from single-agent control to topology control across multiple node types.
• Identity, policy, and observability must travel with the graph if teams want attribution and governance to survive runtime delegation.
• The highest-value controls are explicit node scoping, propagated identifiers, and approval points at the edges where consequence concentrates.

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.
• Loop Engineering: Loop engineering is the practice of designing autonomous AI workflows as closed systems with explicit triggers, sub-agents, review steps, and stop conditions. The goal is not to make the model smarter in isolation, but to make the full work loop bounded, auditable, and safe to run repeatedly.
• Graph Identity Correlation: The practice of tying model requests, tool calls, and execution traces back to graph, run, and node identifiers. For multi-agent systems, this is what makes delegated work auditable, attributable, and governable after execution has crossed multiple nodes.

What's in the full article

TruFoundry's full article covers the operational detail this post intentionally leaves for the source:

• Detailed breakdown of how graph engineering differs from prompt, context, and loop engineering in production systems
• Implementation notes on stable graph, run, and node identifiers for request correlation
• Gateway policy and metrics examples that show how model, tool, and cost records can be tied back to the orchestrator
• Documentation-linked descriptions of approval gates, budgets, and virtual account scoping

👉 The full TruFoundry article covers runtime governance, observability, and topology details for production graphs.

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 building or maturing an identity security programme, it is worth exploring.