Multi-Agent Systems and On-Chain Capital: A Developer’s Infrastructure Guide

The Trust Escalation Problem in Multi-Agent On-Chain Systems

You’re designing a multi-agent DeFi system. One orchestrator agent coordinates three sub-agents: an execution agent, a risk assessment agent, and a rebalancing agent. Each sub-agent has on-chain execution capability — they can submit signed transactions directly.

The orchestrator decides to execute a large position exit. It sends an instruction to the execution agent: “Transfer 500,000 USDC to the bridge contract.” The execution agent receives the instruction and signs the transaction.

The question: what authorized the execution agent to do that?

If the answer is “the orchestrator said so” — you have a trust escalation problem. An orchestrator that can instruct sub-agents to sign arbitrary transactions means the sub-agents’ individual policies are meaningless. A compromised orchestrator, an injected instruction, or a logic error in orchestration can drain every sub-agent wallet in the system.

In web2 microservice architectures, positional trust — authority delegated through the service hierarchy — is a standard pattern. In on-chain systems with real capital, it is a serious security risk.

Why Positional Trust Fails in On-Chain Multi-Agent Systems

DeAgenticAI enables AI agents to execute on-chain transactions with cryptographic policy enforcement at the signing layer.

Multi-agent systems with on-chain capital require independent cryptographic policy enforcement at each agent’s signing layer to prevent cascading authorization failures.

Positional trust is the pattern where authority flows from position in the hierarchy. In traditional distributed systems, this works because the cost of a misconfigured permission is usually a service outage, not an irreversible transfer of capital.

In on-chain multi-agent systems, the cost is different:

An orchestrator that can delegate signing authority can drain sub-agent wallets. If the orchestrator becomes compromised — via prompt injection in its context window, a bug in routing logic, or a malformed message from an upstream agent — every sub-agent that accepts its instructions is at risk.

Trust escalation attacks work because sub-agents trust positional authority. “The orchestrator authorized this” is sufficient reason to sign. But the orchestrator’s authorization is an application-layer assertion — there is no cryptographic binding between the orchestrator’s claim and the sub-agent’s signing key.

The consequence: in a standard multi-agent architecture with wallet access, the security of every sub-agent is bounded by the security of the orchestration layer above it. A single compromise in the orchestrator propagates to all sub-agents.

The alternative is non-delegable cryptographic trust: each agent has policy constraints embedded in its own signing layer that the orchestrator cannot override, regardless of what message it sends.

Independent Policy Enforcement at Each Agent Layer

The Agentic Control Plane’s multi-agent architecture is built on one principle: each agent is an independent trust principal, not a node in a permission delegation graph.

Every agent — orchestrator, execution sub-agents, risk agent, rebalancing agent — gets its own Policy DSL (/glossary/policy-dsl/) constraints at its own signing layer. The orchestrator cannot override a sub-agent’s policy by sending a message, regardless of how authoritative that message appears.

Three structural implications:

Trust cannot cascade upward. A compromised sub-agent cannot affect its sibling agents’ policies. Each agent’s signing layer enforces its own constraints independently.

Trust cannot cascade downward. A compromised orchestrator cannot instruct a sub-agent to sign a transaction that violates the sub-agent’s policy.

Cross-agent authorization is cryptographic co-signature. When the orchestrator and a sub-agent need to jointly authorize a transaction, the policy expresses this as a co-signature requirement encoded in the MPC threshold parameters. The transaction requires key shares from both agents’ signing layers. This is not a message exchange. It is a cryptographic threshold condition.

The orchestrator coordinates. It does not assume sub-agent authority.

How DeAgenticAI Implements Multi-Agent Infrastructure

Each agent is deployed with its own ACP instance:

Intent Sanitization (/glossary/intent-sanitization/) at each agent node. When a sub-agent receives an instruction from the orchestrator, that instruction passes through the sub-agent’s own intent sanitization layer. Instructions exhibiting adversarial patterns — value escalation, address substitution, instruction reframing — are caught before policy evaluation. The sub-agent does not blindly trust the orchestrator’s message.

Policy DSL constraints at each agent node. The execution agent’s policy defines what it can sign: which asset classes, protocols, value thresholds. These apply regardless of orchestrator instructions. The risk agent’s policy defines what it can attest. The rebalancing agent’s policy defines its rebalancing bounds.

Intent-Evaluated MPC (/glossary/intent-evaluated-mpc/) at each agent node. Each agent’s signing is distributed across threshold nodes that independently evaluate policy compliance. No single node holds any agent’s complete key.

For co-signature scenarios, the MPC threshold parameters require key shares from multiple agents’ signing layers. The transaction cannot complete unless all required agents contribute — and each must independently satisfy its own policy constraints.

Integration pattern: each agent maintains its own ACP endpoint. No agent can sign on behalf of another.

Infrastructure Design Principles for On-Chain Multi-Agent Systems

Each agent is a separate trust principal. Do not model sub-agents as sub-permissions of the orchestrator. Each agent has its own identity, policy, and signing layer. The orchestration hierarchy determines coordination flow, not signing authority.

Trust boundaries are cryptographic, not role-based. RBAC relies on the correctness of the access control implementation. Cryptographic trust boundaries enforce limits at the signing layer where they cannot be bypassed by application code.

Audit trail traces to the signing agent. Every transaction is signed by a specific agent with a specific policy in effect. The audit trail records which agent signed, what policy applied, and whether co-signatures were required. Agent-level accountability, not orchestration-level logging.

ACP instances are stateless per agent. Each ACP instance is deployed independently. There is no shared state between instances. A failure in one agent’s ACP does not affect other agents.

Failure isolation by design. A compromised sub-agent’s signing layer enforces its own constraints even if the sub-agent’s application layer is compromised. A sub-agent compromise is bounded to that agent’s policy scope.

Further Reading

• Autonomous AI Agents & On-Chain Capital (/learn/pillars/autonomous-ai-agents-web3/)
• How AI Agents Execute On-Chain Transactions: The Signing Layer Explained — add post-publication
• AI Agent Wallet Security: Why Software Guardrails Fail Under Prompt Injection — add post-publication
• Building Autonomous Trading Agents with Cryptographic Policy Enforcement — add post-publication