Agent-to-agent trust is the question of how much confidence one agent should place in output it receives from another agent, and the honest answer for most systems today is: less than the architecture currently gives it. It's common to see agents built by different teams, at different times, with different assumptions, wired together through message passing that treats every incoming message as reliable simply because it arrived through an internal channel. That's a trust decision, whether or not anyone made it deliberately, and it's usually the wrong one. Verification between agents needs the same rigor applied to any input crossing a trust boundary: check the source, check the claim, and limit what actions can follow from an unverified message.
Why "internal" doesn't mean "trustworthy"
The label "internal" describes network topology, not trustworthiness. An agent that summarizes an inbox, scrapes a website, or processes user-submitted documents is exposed to exactly the same manipulation risks as any system handling external content, and none of that risk disappears just because its output next travels to another agent rather than to a human. If anything, routing through another agent that treats the summary as verified fact makes the manipulation more dangerous, because it now inherits an unearned layer of credibility.
What verification can actually check
Verification doesn't require cryptographic proof of every claim, which usually isn't practical for natural-language output. It can check things like: does this message match the expected schema and scope for this interaction, does the requesting agent have authorization for the action it's implicitly asking for, does the claim being passed along cite a traceable source the receiving agent, or a human, could check if needed. Even lightweight checks like these catch a meaningful share of manipulation attempts that rely on the receiving agent simply not looking closely.
Confidence should be explicit, not assumed
A useful pattern is having agents pass along an explicit confidence or provenance signal with their output, distinguishing a verified fact from a hedge, a guess, or a summary of untrusted external content. Receiving agents can then apply different rules depending on that signal: act freely on verified facts, require additional confirmation before acting on hedged or unverified claims. Without this signal, every message looks equally authoritative regardless of how shaky the underlying reasoning actually was.
Authorization has to travel with the request
When Agent A asks Agent B to perform an action on its behalf, B needs to know not just what A is asking for but whether A, or the user A is acting for, is actually authorized to request it. Passing along only the request and not the authorization context is a common shortcut that lets a compromised or manipulated agent effectively borrow permissions it was never granted, simply by phrasing a request that a downstream agent has no way to properly evaluate.
Rate and scope limits as a backstop
Even with verification, plan for verification to occasionally fail. Per-agent rate limits and scope restrictions mean that if Agent A does manage to manipulate Agent B into taking unwanted actions, the damage is capped by whatever B was authorized to do in the first place, not by whatever A managed to convince it of. This is the same least-privilege logic applied at the user level, extended to apply between agents as well.
Trust decisions need revisiting as agents change
A trust decision made when two agents were first wired together, "Agent B can act on anything Agent A sends without extra verification," tends to persist long after the agents themselves have changed. A model upgrade, a new tool added to Agent A, a change in what data Agent A now has access to, can all shift the risk profile of trusting its output without anyone revisiting the original decision. Treating agent-to-agent trust as a static property set once at integration time, rather than something that needs periodic reconfirmation as either side evolves, is one of the more common ways multi-agent systems drift into a riskier state than anyone intended.
Where TELEON fits
TELEON enforces authorization and logging at the tool-call boundary for each agent, which gives multi-agent systems a practical enforcement point for the authorization-travels-with-the-request problem: a downstream agent's tool call can be checked against policy regardless of which upstream agent originated the request, and the audit trail preserves the chain so investigators can see which agent's decision actually triggered a given action. Trust scoring can also help flag when a particular agent's requests start deviating from its normal pattern, which is often the first sign something upstream has been manipulated.
Designing the actual verification logic, what counts as a trustworthy claim for a given use case, remains a decision specific to each system's own agents and workflows.
A short checklist
- Stop treating "internal" message routing as equivalent to "trustworthy."
- Add explicit confidence or provenance signals to agent-to-agent messages.
- Pass authorization context along with requests, not just the request itself.
- Apply schema and scope checks to incoming agent messages before acting on them.
- Set per-agent rate and scope limits as a backstop against verification failures.
- Monitor for agents whose request patterns deviate from their historical baseline.
- Log the full chain of agent-to-agent handoffs for any consequential action.
Agent-to-agent trust breaks down quietly, because the failures don't look like attacks, they look like agents cooperating exactly as designed. The fix isn't distrust for its own sake. It's building verification into the handoff points that currently assume good faith by default, before an attacker finds the agent that assumes the most.