Multi-Agent Trust: How to Govern AI Agents That Talk to Each Other

How to score, authorise, and audit every handoff in a LangGraph multi-agent system, with working OpenBox code.

When one AI agent hands off a task to another, most systems never check whether the second agent can be trusted with what it just received. The graph routes the work. Nothing weighs it. That is not a gap in your orchestration code. It is a governance failure waiting to happen.

Multi-agent AI governance is the practice of scoring, authorising, and auditing each agent in a chain individually and the chain as a whole, at the boundaries where one agent calls another. This guide is for engineers building LangGraph or similar multi-agent systems, and it ends with working code. It uses OpenBox, an AI agent governance platform, to make each handoff a governed operation rather than a blind pass.

Why Single-Agent Governance Breaks in a Multi-Agent World

Single-agent governance breaks in a multi-agent system because it inspects one agent’s actions in isolation, while the risk lives in the handoffs between agents. A control that watches agent A has no say over what agent B does with what A sends it. The gap is the boundary, and single-agent tooling has no concept of a boundary.

Consider a common chain. A research agent queries a customer database and pulls records that include personal data. It hands a summary to a drafting agent. The drafting agent calls an external API to send that draft onward. Each agent, viewed alone, looks reasonable. The database read is allowed. The draft is allowed. The external call is allowed. The danger is the sequence, and no single-agent check sees a sequence that spans two agents.

OpenBox treats each agent as a governed entity and each handoff as an operation that can be evaluated before it proceeds. Every agent registered with the platform carries its own identity, its own score, and its own policies, and the record of who handed what to whom is reconstructed as one timeline. The rest of this guide walks that boundary from four angles: identity, score, verdict, and evidence. For the platform reference, see the OpenBox documentation.

The Trust Propagation Problem: What Happens When Agent A Calls Agent B

The trust propagation problem is that trust does not travel with a task. When agent A calls agent B, A’s clearance does not extend to B, and B is not automatically constrained by why A called it. Three things cross the boundary, control, data, and intent, and none of them carries a trust guarantee on its own.

It helps to separate two decisions that look like one. The routing decision is which node runs next. LangGraph, LangChain’s graph-based orchestration library, owns that: nodes are actions, edges are transitions, and a conditional edge picks the next agent. The trust decision is whether that agent should be permitted to act on what it received. A graph that correctly sends work from A to B has said nothing about whether B is safe to run it.

Identity is where propagation has to start. If agent B is anonymous to your controls, no verdict about B means anything, because there is nothing to attach it to. In OpenBox, each agent has a decentralised identifier (a DID), and newly created agents require DID signing by default, so both the caller and the callee are named and their actions are attributable. A handoff between two signed agents is a transfer between two known parties, not two anonymous functions.

Most multi-agent systems have an orchestrator: a supervisor node that decides which agent runs next. The orchestrator is an agent too. It has its own identity, its own Trust Score, and its own tier, and its node transitions are captured as governed events like any other operation. This matters because the orchestrator touches every branch of the chain. If it degrades, every downstream handoff starts from a weaker position.

Once caller and callee are named, the question becomes concrete: what is agent B allowed to do here, and who decides. That is the job of the Trust Score and the governance decision, covered next.

How Trust Scores Work Across Agent Boundaries

Across agent boundaries, OpenBox scores each agent individually rather than the chain as a whole. Every agent carries its own Trust Score from 0 to 100 and its own Trust Tier, and the acting agent’s tier, not the caller’s, governs what that agent may do at each step. A trusted caller cannot lend its standing to an untrusted callee. See Trust Scores for the full model.

The Trust Score is a weighted composite. Per the OpenBox documentation it is calculated as (Risk Profile Score x 40%) + (Behavioral x 35%) + (Alignment x 25%). Risk Profile Score reflects the agent’s inherent risk, set at creation. The Behavioral component tracks runtime policy compliance. Alignment measures goal consistency. The score is not a vibe; it is a number each agent earns and keeps.

Each component comes from a different phase of the agent’s lifecycle. The Risk Profile Score is set during Assess, the Behavioral component tracks compliance during Authorize and Monitor, and Alignment is measured during Verify. An agent’s tier at a boundary is therefore a summary of its whole governed history, not a snapshot of the current call.

That score maps to a Trust Tier, and the tier is what policies read at a boundary.

One point of confusion is worth clearing up. The Trust Tier described above runs one way: Tier 1 is the most trusted and most autonomous, Tier 4 is the most restricted. A separate, component-level Risk Tier derived from the Risk Profile Score runs the other way, where a lower risk tier means lower inherent risk. They are different constructs pointing in opposite directions. When this guide says Tier 1, it means the composite Trust Tier: highly trusted.

Because the tier belongs to the acting agent, propagation happens at the boundary by reading that agent’s tier at the moment it acts. A policy (written as an OPA/Rego rule) can gate an operation on the caller’s own tier. The pattern from the OpenBox Trust Tiers documentation looks like this:

The consequence for a chain is direct. If a Tier 1 research agent hands off to a newly registered drafting agent, that agent’s own tier governs its external call. Most new agents begin in Tier 3 Monitor, the documented starting tier for most new agents, so its external call is typically held for approval no matter how trusted the caller was. Trust is not laundered across the handoff. Each agent stands on its own record.

Scores also move during a run, and the movement is immediate. When an agent’s Trust Score crosses a tier bound, OpenBox downgrades or upgrades it at once, with no cooldown, and applies the stricter or looser controls straight away. Upgrades into Tier 1 additionally require admin approval.

Recovery is earned, not waited out. A degraded agent climbs back at roughly one point per day of clean operation, and at half that rate once it falls to the most restricted Tier 4. In a long-running chain, an agent that misbehaves early is governed more tightly for its later handoffs, which is exactly the behaviour you want at a boundary.

Assigning Governance Decisions to Inter-Agent Actions

OpenBox returns one of four governance decisions for any agent operation, including an inter-agent handoff: ALLOW, REQUIRE_APPROVAL, BLOCK, and HALT, with precedence HALT > BLOCK > REQUIRE_APPROVAL > ALLOW. The same four apply whether the actor is a human-triggered agent or one agent calling another. If any applicable rule returns HALT, the session ends regardless of the others.

The four map cleanly onto the decisions a chain forces on you.

The multi-step case is where multi-agent systems need more than per-operation checks, and it is what Behavioral Rules are for. A Behavioral Rule is a stateful authorisation rule that detects patterns across a session: sequences, frequencies, or combinations of actions. Unlike a stateless policy that judges one operation, a behavioral rule remembers what happened earlier. See Behavioral Rules for the full model.

Return to the earlier chain. The OpenBox documentation gives the sequence pattern “PII access followed by an external API call without approval” as a canonical example. In a two-agent chain, the PII access happens in the research agent and the external call happens in the drafting agent. A single-agent check misses it. A behavioral rule that watches the sequence across the session catches it, and can escalate the drafting agent’s external call to REQUIRE_APPROVAL, BLOCK, or HALT.

A Behavioral Rule is built from a trigger and one or more required prior states. The trigger is the action being checked; the prior state is what must have happened before it. If the prerequisite is not met, the configured verdict applies. Rules run in priority order and stop at the first one that fires, so ordering is a design decision, not an afterthought.

Two other pattern types matter for chains. A frequency rule catches volume, such as more than ten failed authentication attempts in a minute, which is the signature of a looping agent. A combination rule catches actions that are dangerous together, such as a database write, a file export, and an external send, even when each step is individually allowed and each happens in a different agent.

One implementation note carries into the code. Governance decisions from behavioral rules, like all authorisation-layer verdicts, surface as exceptions in your code, and you handle them in your activities. That is the same pattern the LangGraph error handling in the next section uses.

The documentation includes a worked rule that fits multi-agent reporting exactly: require a database query before any file is written, and HALT if it is missing. One agent that queries real data and a second agent that writes the report is the classic split. The rule stops the writer from producing a file built on numbers the model invented, because the prerequisite read never happened. That is a chain-level guarantee, enforced at an agent boundary.

Code: Wrapping a LangGraph Multi-Agent Graph with OpenBox

To govern a LangGraph multi-agent graph, wrap the compiled graph once with the OpenBox LangGraph SDK. A single function call, create_openbox_graph_handler, returns a handler that exposes the same invoke, ainvoke, and astream interface as the graph and evaluates every governed operation, including the handoff into the next node, before it runs. There are no graph changes. See the OpenBox LangGraph SDK reference.

Install the SDK. It requires Python 3.11 or newer.

Build the graph as you normally would. Here two agents share one graph: a researcher hands off to a writer. Then wrap the compiled graph. The node functions are untouched.

Run the handler with the same call you already use. Governance is evaluated as the graph executes. A BLOCK verdict on any governed operation raises an exception mid-stream, which means a blocked action in the writer node is stopped before it runs, not cleaned up afterwards.

Two details make this work across the boundary rather than only inside one node. First, the SDK enforces governance at three layers at once: LangGraph callback events (tool calls, LLM invocations, node transitions), monkey-patched HTTP and database hooks, and OpenTelemetry spans. The node transition from researcher to writer is itself an event the platform sees. Second, DID signing is configured in that same wrap, so every captured operation is attributed to a signed agent identity.

Streaming chains work the same way. The handler exposes astream_governed for token-by-token output with governance applied at each step, and a BLOCK verdict fires between chunks, so a streaming handoff stops at the offending boundary rather than after the fact.

If you have helper functions that are not LangGraph nodes, wrap them with the SDK’s traced decorator (from openbox_langgraph.tracing) so they appear in the session record too. The invocation interface is unchanged, so adopting governance is a one-line change to how the graph is called, not a rewrite. Full parameters, fail policies, and exclusions are in the SDK configuration guide.

What to Log When the Caller Is Not a Human

When one agent calls another, log the same evidence you would demand of a human actor: which agent acted (its DID), what it did, which data it touched, the governance verdict, and who approved anything sensitive. OpenBox captures this per operation and reconstructs the whole chain as one timeline, so a handoff is never a blank in the record.

Per agent, the LangGraph SDK captures tool start and end with inputs and outputs, chat model start and end with prompts and responses, node execution events, and HTTP and database operations. Each captured operation carries the governance verdict the platform returned for it. That is the per-agent layer of evidence.

The chain layer is the Multi-Agent Sessions view. It reconstructs a single multi-agent run as one interactive timeline: every participating agent, every handoff between them, every governance verdict, and every message exchanged. The agent graph shows one node per agent and edges for the handoffs; the event stream shows one row per agent with its activities; the detail pane shows the messages, metrics, and the governance verdict for a selected step. See Multi-Agent Sessions.

This is how you debug a multi-agent failure. Instead of grepping separate logs for two agents and guessing where the seam is, you open the run, find the handoff edge where the status turns, and read the message that crossed it. A run reports as Running, Completed, or Failed, and Failed covers a session that errored, was blocked, or was halted, so a governance stop and a code crash are both visible in the same place.

Session Replay, part of the Verify phase, plays a single agent’s session back step by step for the same reason at the per-agent level. When you need to isolate a specific blocked operation, cross-reference the agent from its own Agents page, where its per-agent event log carries the verdict and the denial reason for each step.

For evidence that has to hold up later, OpenBox hashes each session’s events into a Merkle tree and signs the result, producing tamper-evident proof that the record of who did what across the chain was not altered after the fact. Logging for a non-human caller is therefore not an afterthought bolted on at the end; it is the same governed operation, captured and signed as it happens.

The routing question and the trust question are different questions. LangGraph answers the first: which agent runs next. Multi-agent AI governance answers the second at every boundary: is this agent identified, does its own score permit this action, what verdict applies, and is the handoff on the record. Answer those four and a chain of agents stops being a chain of blind spots.

OpenBox governs each agent in your chain individually and the chain as a whole. The LangGraph SDK is MIT licensed and available on GitHub. For the wider integration set, see the OpenBox Developer Hub.

Frequently Asked Questions

Can one OpenBox Trust Score cover an entire multi-agent chain, or does each agent need its own score?

Each agent needs its own score. OpenBox assigns every agent its own Trust Score from 0 to 100 and its own Trust Tier, and the acting agent’s tier governs its actions at each step. The chain has no single combined score. Instead, every handoff and verdict is reconstructed together in a Multi-Agent Session.

What happens when one agent’s Trust Score drops mid-execution in a running chain?

A score drop can move the agent to a lower Trust Tier immediately, with no cooldown, which tightens the controls applied to its next operations. Tier changes are immediate when the score crosses a bound. A serious enough violation returns BLOCK on the offending operation, or HALT, which terminates the session.

How does OpenBox handle trust when agents call external tools, not other agents?

External tool calls are governed the same way as inter-agent actions. The SDK captures tool, HTTP, and database operations, and each is evaluated against the agent’s tier, policies, and Behavioral Rules before it proceeds. A failing check returns BLOCK or REQUIRE_APPROVAL on that specific call rather than on the whole chain.

Does adding OpenBox to a LangGraph multi-agent system require rewriting the graph?

No. You keep writing LangGraph as normal and wrap the compiled graph once with create_openbox_graph_handler. The handler exposes the same invoke, ainvoke, and astream interface, so only the invocation changes. Governance, telemetry, and agent identity are configured in that single call.