Multi-Agent Trust: How Do You Know Which Agent Authorised That Action?
Multi-Agent Trust: How Do You Know Which Agent Authorised That Action?
Category: Thought Leadership | Reading time: 6 min
The Trust Problem in Agent Meshes
Enterprise AI is moving from single agents to agent meshes — networks of specialised agents that coordinate to complete complex tasks. An orchestrator agent routes requests to specialist agents: a document agent, a payment agent, a compliance agent, a communication agent. Each specialist calls tools, accesses systems, and produces outputs that feed back into the mesh.
This architecture is powerful and increasingly common. It also introduces a trust problem that single-agent deployments don't have:
When Agent B takes an action, who authorised it?
Agent B was invoked by Agent A. Agent A was invoked by... whom? If the chain isn't documented, you have no way to trace a consequential action in an agent mesh back to the human who initiated the workflow. And in a regulated context — financial services, healthcare, government — unattributable actions are unacceptable actions.
The Transitive Trust Problem
Consider a three-agent mesh for invoice processing:
User → Orchestrator Agent
│
├─ Document Agent (extracts invoice data)
│
├─ Compliance Agent (checks vendor status)
│
└─ Payment Agent (submits payment)
The payment happens inside the Payment Agent. The Payment Agent was invoked by the Orchestrator. The Orchestrator was invoked by the user.
Without an OBO chain: "The payment system received a payment request from the payment agent." Who authorised the payment agent? What constraints was it operating under? Which policy governed its actions? Unknown.
With an OBO chain: "The payment was submitted by the payment agent, acting on behalf of the orchestrator, acting on behalf of user Alice Clerk, under vendor payment policy v12, with manager approval from Bob Manager." Fully attributed, fully traceable.
How OBO Chains Work in Multi-Agent Contexts
Each agent in the mesh extends the OBO chain when it acts. The chain accumulates delegations:
{
"execution_id": "exec-mesh-7821",
"chain": [
{
"principal": "aclerk",
"role": "ap_clerk",
"action": "initiated_payment_workflow",
"timestamp": "T+0"
},
{
"principal": "orchestrator_agent",
"action": "invoked_document_agent",
"authorised_by": "aclerk",
"scope": "extract_invoice_data",
"timestamp": "T+0.1s"
},
{
"principal": "document_agent",
"action": "extracted_invoice_data",
"authorised_by": "orchestrator_agent → aclerk",
"timestamp": "T+0.3s"
},
{
"principal": "compliance_agent",
"action": "checked_vendor_ofac_status",
"authorised_by": "orchestrator_agent → aclerk",
"result": "cleared",
"timestamp": "T+0.5s"
},
{
"principal": "manager_bob",
"action": "approved_payment",
"approval_id": "appr-9921",
"timestamp": "T+180s"
},
{
"principal": "payment_agent",
"action": "submitted_payment",
"authorised_by": "manager_bob → orchestrator_agent → aclerk",
"payment_id": "PAY-4421",
"timestamp": "T+181s"
}
],
"chain_signature": "sha256:f3a2b1..."
}
Every action in the mesh is attributed through the full delegation chain to the originating human principal, with every intermediate agent recorded.
Scope Limitation: What Each Agent Can Do
In a multi-agent mesh, each agent should have a bounded scope — a defined set of actions it's permitted to take, independent of what the orchestrator asks it to do. This prevents two failure modes:
Scope escalation: The orchestrator asks the payment agent to also perform document management operations it wasn't designed for.
Agent compromise: If one agent in the mesh is compromised or manipulated (via prompt injection, for example), it can only do harm within its defined scope — it cannot reach outside to perform actions outside its ART token.
The Taos ART token issues at workflow initiation defines each agent's capability boundary:
{
"agent": "payment_agent",
"allowed_tools": [
"create_payment_record",
"verify_bank_account",
"submit_to_payment_processor"
],
"prohibited_tools": [
"delete_records",
"modify_vendor_status",
"access_hr_systems",
"send_external_communications"
],
"max_payment_amount": 1000.00, // Payment agent can only process auto-approve tier
"requires_prior_approval": true
}
The payment agent cannot do anything outside its allowed tools list, regardless of what the orchestrator requests. If the orchestrator (or an attacker who compromised the orchestrator) asks the payment agent to modify vendor status, the kernel denies the request and logs the attempt.
Inter-Agent Trust Verification
How does Agent B know it's being invoked by a legitimate orchestrator and not by a rogue caller? In a traditional API architecture, this is handled by authentication — Agent B requires a valid token from Agent A.
In Taos, the OBO chain extends this: Agent B's kernel validates not just that the caller has a valid token, but that the token's OBO chain is consistent with the expected workflow execution. An invocation from an orchestrator that's not part of the current execution's chain is rejected.
Valid invocation:
execution_id matches
orchestrator is in the OBO chain for this execution
requested action is in orchestrator's allowed_tools
→ proceed
Invalid invocation:
execution_id doesn't match (wrong execution context)
→ deny + log anomaly
This makes the agent mesh resistant to confused deputy attacks — where a malicious actor uses a legitimate agent as a proxy to perform unauthorised actions.
The Audit View of a Multi-Agent Workflow
After a multi-agent workflow completes, the audit trail shows the complete execution across all agents:
[T+0.00s] WORKFLOW_STARTED orchestrator initiated_by=aclerk
[T+0.10s] AGENT_INVOKED document_agent by=orchestrator
[T+0.30s] STEP_COMPLETED extract_invoice by=document_agent
[T+0.50s] AGENT_INVOKED compliance_agent by=orchestrator
[T+0.55s] STEP_COMPLETED ofac_check result=cleared
[T+0.60s] POLICY_EVALUATED payment_policy result=require_approval tier=manager
[T+0.61s] APPROVAL_REQUESTED manager_tier routed_to=manager_role
[T+180s] APPROVAL_GRANTED approved_by=bmanager
[T+181s] AGENT_INVOKED payment_agent by=orchestrator
[T+181s] STEP_COMPLETED submit_payment payment_id=PAY-4421
[T+182s] OBO_CHAIN_RECORDED chain_length=5 signature=sha256:f3a2b1
[T+182s] WORKFLOW_COMPLETED
The complete execution trace — across four agents, one human approval, and one policy evaluation — is a single audit record. When the auditor asks "show me everything that happened to invoice INV-8821", this is the answer.
The Bottom Line
Multi-agent meshes make AI more powerful and more complex — and complexity without accountability is a governance failure waiting to happen. The OBO chain extends accountability from single-agent workflows to multi-agent architectures: every agent's actions are attributed, every delegation is recorded, and every scope boundary is enforced.
You know which agent authorised that action. And you know who authorised the agent.
Tags: multi-agent, OBO chain, agent mesh, AI governance, agent trust, delegation, enterprise AI architecture