Notifications
Clear all
Topic starter
20/08/2026 5:19 pm
TL;DR: Graph engineering reframes multi-agent systems as governed topologies of agents, functions, routers, and checkpoints, with runtime identity, tool policy, and observability attached to the graph rather than left to ad hoc orchestration, according to TruFoundry. The governance challenge is that existing IAM and MCP controls still assume stable, human-paced ownership boundaries, while graph-scale delegation introduces correlated identity, policy, and audit requirements that need explicit design.
NHIMG editorial — based on content published by TruFoundry: Graph Engineering for Multi-Agent Systems: Architecture, Governance, and Observability
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Apply node-specific tool policy Scope tools by node mandate instead of assuming the entire graph should inherit the same MCP access.
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
👉 Read TruFoundry's analysis of graph engineering for multi-agent systems →
Graph engineering for multi-agent systems: are controls keeping up?
Explore further
20/08/2026 6:11 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Graph engineering exposes the governance gap in multi-agent systems
