Graph Engineering for AI Agents: Govern the Connections

Enterprises do not govern consequential work by trying to inspect every thought inside every employee, service, or vendor. They govern the interfaces around that work: which systems can be reached, which actions need a second approver, which credentials may be used, how much can be spent, what information may cross a boundary, and what record survives afterward. AI agents need the same institutional instinct — with one important addition. Models still need evaluation. Testing and monitoring tell you how a component behaves under defined conditions; runtime controls determine what that component is allowed to do when connected to production systems.

That distinction is the most useful way to think about graph engineering. The term is still emerging, but the engineering problem is already concrete: an agent estate is a graph of models, tools, services, data sources, sandboxes, humans, and other agents. Every consequential edge carries authority. The enterprise task is not to choose between evaluating the node and governing the graph. It is to do both — and to know which layer is responsible for which control.

1. Evaluate the Node; Govern the Edges

It is tempting to frame agent governance as a reaction to model opacity: because the model is hard to inspect internally, govern only the interfaces. That goes too far. NIST's AI Risk Management Framework calls for evaluation under deployment-like conditions before use and monitoring of AI-system behavior in production; OWASP's agent-security guidance combines adversarial testing with least privilege, authorization, approvals, logging, and monitoring. The mature posture is therefore complementary: evaluation estimates behavior; edge controls bound authority.

The institutional analogy becomes useful once it is scoped that way. A finance team does not rely on an employee's judgment alone; it also limits account access and requires counter-signatures. A production agent should not rely on prompt instructions alone; its runtime and gateways should make sensitive boundaries explicit and enforceable. The analogy is not literal — people and models are not the same kind of actor — but the control objectives map surprisingly well.

Discovery is not a security boundary

This distinction matters especially for tool discovery. TrueForge documents deferred tool loading and other context-engineering mechanisms that keep the active context smaller. That can improve selection quality and reduce unnecessary exposure to tool schemas. It does not by itself authorize the call. Estate-level authorization belongs in an access-control layer that resolves the caller and applies policy. TrueFoundry's AI Gateway access controls govern model access for users, teams, and applications; the MCP Gateway authentication and security model separately resolves inbound identity, tool/server permissions, and downstream credentials.

2. Designed Graphs and Executed Graphs Are Different Objects

An architecture diagram is a declaration of intent. Production evidence is a record of what the instrumented system actually observed. The two diverge for ordinary reasons: a prototype tool remains attached, a fallback route activates, a delegated task fans out, an OAuth grant changes, or an agent takes a path that the diagram author did not expect. That gap is where graph governance becomes operational rather than architectural.

But “the actual graph is in the traces” is also too simple. No single trace source is automatically complete. A useful reconstruction combines the evidence each layer owns:

• Orchestrator: graph topology, node state, routing, retries, joins, and delegation decisions.
• Harness: model/tool loop steps, sandbox use, approval checkpoints, session state, and events visible to the runtime.
• Gateway: authenticated model/MCP calls, access-policy outcomes, budgets/rate limits, latency, cost, and gateway-visible request traces.
• Downstream systems: authoritative records of business side effects — the database mutation, ticket update, payment, deployment, or permission change that actually happened.

The right audit question is therefore not “does the trace match the diagram?” but “can we correlate the intended topology with enough runtime and system-of-record evidence to explain a consequential action?” That is a much higher bar — and a more useful one.

3. TrueForge: Keep the Execution Loop Inspectable

At the harness layer, the governance question is whether operating decisions around the model are visible and configurable. TrueForge's public repository describes the runtime plainly: it runs the agent execution loop across model calls, MCP tools, skills, sandboxing, approvals, context management, and session state. The same repo documents sandbox-as-a-tool with secrets retained in the harness, human checkpoints, subagents, deferred tool loading, large-result offloading, compaction, and both local and hosted modes. The repository explicitly positions local mode as a single-machine evaluation path, not a production or internet-facing setup; shared or production use belongs in hosted mode. It is released under the MIT license.

That openness is useful for a governance reason, not just a licensing reason. Source availability makes implementation-level inspection and modification possible. It does not prove that a deployed instance is secure, correctly configured, or equivalent to a particular commit; those still require software-supply-chain and operational controls. But it gives platform teams something closed runtimes cannot: the ability to inspect the execution machinery they are being asked to trust and, when necessary, run or modify it themselves. TrueFoundry's launch post, Introducing TrueForge, makes that positioning explicit, and Why Agent Harnesses Should Be Open states the commercial trade-off directly: keep the harness open; add centralized governance when the organization actually needs it.

The strongest way to promote TrueForge is not to claim it owns the whole graph. It does not. An arbitrary multi-agent orchestrator may own topology above the harness, and connected systems retain their own authorization and audit semantics. TrueForge's role is narrower and more credible: make the execution loop inspectable, portable, and governable at the runtime boundary.

4. TrueFoundry: Add the Policy Plane When the Estate Becomes a Fleet

One harness can manage its own execution. An estate of agents creates a second problem: credentials, access policy, spend controls, and evidence begin to fragment across teams. That is where TrueFoundry's gateways become the complementary layer.

The AI Gateway provides a unified model interface with centralized access control, rate limiting, budget limiting, and observability. Its budget rules can scope spend by user, team, model, virtual account, or metadata. The Metrics Dashboard aggregates LLM and MCP activity, cost, errors, routing, guardrails, and other operational signals. The MCP Gateway separates inbound authentication, tool/server access control, and outbound authentication so agents do not each need to own the full credential problem.

That produces a clean architecture story:

The product message is therefore not “TrueFoundry governs every edge in every graph.” That would be both technically inaccurate and strategically weaker. The more defensible claim is: TrueForge gives you an open harness for the agent execution loop; TrueFoundry's gateways can centralize policy and evidence for model and MCP traffic that you deliberately route through them. The orchestrator and downstream systems remain part of the control story, which is exactly how serious infrastructure should be described.

5. The Leadership Test

Those questions are deliberately more operational than “which model did we use?” Model choice still matters — for capability, safety, latency, cost, and evaluation results. But once agents can act, the governing surface expands. A well-run estate should be able to connect pre-deployment evaluation with runtime authorization and post-hoc evidence: what the model was expected to do, what it was permitted to do, what it actually did through instrumented boundaries, and what the system of record says happened.

That is the durable case for graph engineering as a governance posture. The novelty is not that enterprises suddenly discovered graphs. The novelty is that AI agents make familiar institutional controls programmable at software edges — and make actions at those edges fast, repeatable, and partially autonomous enough that informal governance stops scaling.

Scope, Method, and Disclosures

TrueFoundry publishes this essay, maintains TrueForge, and sells the AI Gateway and MCP Gateway discussed here. The product mapping is therefore commercially interested and is stated as such. Product claims in this revision are limited to behavior documented in live TrueFoundry pages or the current public TrueForge repository. The institutional analogy is editorial framing, not a claim that human organizations and AI systems are equivalent. “Graph engineering” remains an emerging term; the linked TrueFoundry enterprise guide discusses its provenance and current product boundary. This essay does not claim that edge controls replace model/system evaluation, that traces are complete by default, or that TrueFoundry governs traffic outside the surfaces through which it flows.

References

• TrueFoundry — Graph Engineering for Multi-Agent Systems: Architecture, Governance, and Observability.
• TrueForge public repository — current runtime scope and MIT license.
• TrueFoundry — Introducing TrueForge: the open-source agent harness we run in production.
• TrueFoundry — Why Agent Harnesses Should Be Open.
• TrueFoundry — The Loop Is the New Middleware.
• TrueFoundry AI Gateway — Introduction; Access Control; Budget Limiting; Metrics Dashboard.
• TrueFoundry MCP Gateway — Authentication and Security.
• NIST AI RMF Core — Measure.
• OWASP AI Agent Security Cheat Sheet.

‍