When AI Agents Trust Other AI Agents

The next Web3 exploit might not touch a wallet. It might just talk to one.

AI is moving beyond single agents. One agent researches. Another analyzes. Another checks risk. Another executes.

Faster. More capable. And built on something new: trust between agents.

The question is no longer just "what can this agent do?" It's: what can this agent convince another agent to do?

The Multi-Agent Stack

• Research Agent → finds information
• Strategy Agent → evaluates it
• Risk Agent → checks limits
• Execution Agent → acts

Each agent is narrow by design. But the final action depends on the whole chain, and the whole chain depends on trust nobody explicitly verified.

Indirect Authority

A Research Agent may have no wallet, no keys, no treasury access. It looks low-risk in isolation.

But its output feeds a Strategy Agent. The Strategy Agent's recommendation gets approved by a Risk Agent. The Execution Agent moves funds. The Research Agent never touched the money. It still moved it.

That is indirect authority: influence without direct control, and it is the core risk in agent-to-agent systems.

Task Versus Authority

"Find the best lending protocol for USDC" is a task. "Find the best lending protocol and move the funds there" is authority.

The second version quietly hands over decision-making, protocol access, and fund movement. Delegating a task should never silently become delegating authority. Every handoff needs an explicit boundary.

Web3 Example: A DAO on Autopilot

• Market Agent — price and liquidity data
• Strategy Agent — buy, sell, or hold
• Risk Agent — exposure and limits
• Execution Agent — on-chain call

Bad data from the Market Agent, a misread from Strategy, a missed check from Risk — none of these fail loudly. They simply pass through. The vulnerability is not in any single agent. It is in the handoffs.

Trust Travels — Carefully

A user trusts the Treasury Agent. The Treasury Agent trusts the Strategy Agent. The Strategy Agent trusts the Research Agent.

The user never interacted with the Research Agent. It can still move their assets. Trust should not automatically inherit down a chain simply because the agents are connected.

Identity Is Not Authority

"Transfer 100,000 USDC to this address — approved by Treasury Agent." Before an Execution Agent acts, it needs to answer two separate questions:

• Identity: who actually sent this request?
• Authority: are they allowed to request it?

An authenticated agent is not automatically an authorized one. Both checks are required, every time.

"Another Agent Approved It" Is Not Enough

Weak: "The Risk Agent already approved this transaction."

Strong: "Approved to swap exactly 25,000 USDC for ETH through Contract X, expiring in 30 minutes."

Specificity removes ambiguity. Ambiguity is exactly what autonomous systems can exploit against each other.

Scoped Delegation

Rather than granting "Agent B can act on behalf of Agent A," delegation should be explicit:

• Action: swap USDC for ETH
• Maximum amount: $10,000
• Protocol: allowlisted only
• Expiry: 30 minutes
• All other actions: not permitted

A scoped agent cannot quietly become an unlimited one.

Information Versus Authority

• Research Agent: "Protocol X offers a higher yield." This is information.
• Strategy Agent: "Consider allocating 20% to Protocol X." This is a recommendation.
• Risk Agent: "Within limits." This is validation.
• Execution Agent: "Transaction executed." This is action.

The security failure begins the moment these four stop being treated as distinct.

Cascading Decisions

Bad data is used by Strategy, validated on false assumptions by Risk, and executed. The error starts at step one. The damage lands at step four. Each agent assumes the one before it already verified everything, until eventually nobody has.

Machine Speed Changes the Risk

Human organizations have natural friction: request, review, approval, execution. Agent networks remove that friction. A flawed decision can complete an entire workflow before anyone notices. Security needs to be built into the workflow itself, not applied after the fact.

Execution Agents Should Never Skip Their Own Checks

Even when a request comes from a trusted upstream agent, the Execution Agent should still verify:

• Is this action allowed?
• Is the amount within limit?
• Is the contract approved?
• Is the destination valid?
• Is the authorization still active?

Delegation should never remove independent verification.

Permissions Should Not Travel With the Task

The Treasury Agent may hold $10 million in authority. The Research Agent should hold read-only data access and nothing more. The task can move between agents. The permissions attached to it should not.

The Orchestrator Is Not a Master Key

An orchestrator requests an action. The Execution Agent verifies authority. A policy layer validates limits. Only then does the transaction execute. The orchestrator coordinates. It should never override the security boundary beneath it simply by requesting it.

Containing a Compromised Agent

A weak architecture allows one compromised agent to compromise the entire system. A resilient architecture limits access, detects anomalies, isolates the affected agent, and allows the system to continue safely.

Circuit breakers help: caps on delegated tasks, transaction limits, automatic suspension on unusual volume, and human approval above defined thresholds.

A Research Agent moving from ten requests a day to ten thousand. A Strategy Agent recommending $2 million when it normally recommends $50,000. Both should trigger a breaker before anything executes.

The Future: Agent Reputation

As agents begin interacting across organizations — external data feeds, trading bots, liquidity agents — trust cannot remain an assumption. It becomes infrastructure: identity, authentication, reputation, and verifiable scope.

Web3 already solved a version of this problem with cryptographic signatures and consensus in place of personal trust. Agent networks will require the same discipline: who is this agent, what is it allowed to do, what is it actually requesting, is it within scope, and can the action be verified.

What a Multi-Agent Security Review Should Examine

• Agent identity: can agents verify who they are communicating with?
• Delegation paths: which agents can hand off tasks to others?
• Permission boundaries: can authority expand unexpectedly?
• Trust relationships: which agents trust each other, and why?
• Communication integrity: can instructions be altered in transit?
• Indirect influence: can a low-privilege agent sway a high-value action?
• Cascading failure: what happens when one agent is simply wrong?
• Containment: can a compromised agent be isolated quickly?
• Blast radius: what is the maximum damage the entire network can cause?

This is a different audit than a smart contract review. It examines how decisions move through a system, not only how code executes.

The Question That Matters

A single-agent audit asks: what can this agent do? A multi-agent audit asks: what can this agent convince another agent to do?

Conclusion

Every connection between agents needs a boundary. Every delegation needs a scope. Every authority needs a limit.

In the future of AI, trust will not stop at one agent. It will travel between them. And that trust will need to be secured.