Inter-Agent Communication and Cascading Failure

Inter-Agent Communication and Cascading Failure is what happens when the system stops having one agent in it. Each additional agent is another principal with its own identity and authority, each message between them is untrusted input, and the failure that makes multi-agent systems distinctive is that a wrong answer propagates with the same confidence as a right one.

Key takeaways

• A message from another agent is untrusted input. It was composed by a component that may have read a poisoned document, and it arrives without the visual cues that make a customer ticket look like customer text.
• Authority does not compose. Four agents with reasonable individual grants, chained, produce an effective capability set nobody reviewed and nobody would have approved as a whole.
• Sign identity at every hop so the receiving agent knows which principal is calling and on whose behalf, rather than inferring it from a shared network or a shared key.
• Delegation should narrow. Each hop passes a subset of the authority it received, with the task and an expiry attached, so depth reduces power rather than preserving it.
• Contain rather than prevent. Depth limits, budgets, bulkheads and a stop control that reaches every agent are what keep one confused component from becoming a system event.

Read this after Chapter 5, since delegation is meaningless without identity, and Chapter 9, because one agent's poisoned memory becomes another agent's premise. The budget and blast-radius mechanics referenced here are developed at length in Agents That Finish.

An orchestrator receives a request, decomposes it, and hands three subtasks to specialist agents. One of them reads a document, summarises it, and returns the summary.

The orchestrator treats that summary as a finding from a trusted internal component, because it is one. It plans the next step around it, and hands that plan to an agent holding a write credential.

The document contained instructions. They are now travelling through the system as an internal conclusion, and nothing downstream has any way to tell.

A message from an agent is untrusted input

The claim is uncomfortable and it follows directly from Chapter 3, so it is worth stating without softening.

An agent's output is a function of its context, its context includes content it retrieved, and that content may have been authored by anybody. A summary produced by a compromised agent is attacker-controlled text. It does not matter that the agent runs on your infrastructure, that your team wrote it, or that it is authenticated. Those facts establish where the message came from. They say nothing about who composed its contents.

The reason this is missed so consistently is presentation. A customer ticket looks like customer text, so people treat it with suspicion. A message from the summarisation agent looks like a system artifact: structured, confident, in the house format, with a correlation identifier attached. It reads as a fact from a component, and it is a paragraph of prose from a language model.

The practical rule is that the boundary between two agents is a trust boundary in Chapter 2's sense, and it gets marked on the map like any other. Inbound messages get validated, scoped and constrained in what they can trigger.

Authority does not compose

This is the failure mode unique to multi-agent systems, and it is a property of the graph rather than of any node in it.

Each agent gets a grant that is defensible on its own. The orchestrator may call the other agents and nothing else. The research agent may fetch web pages. The database agent may run named queries. The action agent may write records. Four sensible grants, four approvals nobody would object to.

Now compose them. The research agent can pull arbitrary text from the internet, that text reaches the orchestrator, the orchestrator directs the database agent, and its output reaches the action agent that writes. The effective capability of the system is that content from an arbitrary web page can cause a write to production, which is a permission nobody granted and nobody reviewed, because no single grant contains it.

The review process makes this worse rather than better. Grants are approved one agent at a time, by different people, at different times, and the composition is never on anybody's agenda. OWASP's excessive agency guidance is aimed at a single agent's functionality, permissions and autonomy, and a multi-agent system can satisfy it at every node while failing it as a whole.

The countermeasure is to review the graph as an artifact, not the nodes. Draw the agents, draw who may call whom, and trace the paths from any untrusted input to any irreversible action. Those paths are the system's real permission set.

Sign identity at every hop

If authority is going to travel between agents, the receiving end needs to know what it is receiving, and shared infrastructure does not tell it.

The common shortcut is a shared network and a shared key. Agents reach each other because they are in the same cluster, and they trust each other because they hold the same credential. That arrangement cannot distinguish which agent is calling, cannot tell whether the call is on a user's behalf, and cannot revoke one participant without revoking all of them, which is Chapter 5's borrowed-credential problem reappearing at a different layer.

Each message should carry three things. The calling agent's own identity from Chapter 5, signed rather than asserted. The identity of the user on whose behalf the chain is running, if there is one, so that the eventual action executes in that person's context as OWASP recommends. And a task identifier that ties every hop in the chain to the original request.

The receiving agent then makes an authorization decision rather than an assumption, using the machinery of Chapter 6, and its logs record which principal asked rather than that something in the cluster asked.

The rule that follows is short. No implicit trust from network position, ever. Being inside the same cluster is a fact about routing.

Delegation should narrow, not preserve

Signing establishes who is calling. Deciding what they may ask for is the second half, and the design principle is that authority contracts along the chain.

An agent receiving a delegated authority should be able to pass on a subset of it and never a superset. If the orchestrator holds read and write for the current user's orders, the agent it delegates to for a lookup receives read on one order, scoped to this task, expiring in minutes. The token says what it is for, and the destination system in Chapter 6 enforces the narrowing rather than trusting the caller to have applied it.

Two properties travel with the delegation and are easy to forget. A depth counter, so a chain cannot extend indefinitely by each participant delegating onward. And a budget, covering calls, tokens, time and money, decremented at every hop and refused when exhausted.

The contrast worth holding is with the shared-credential arrangement. There, the fourth agent in a chain can do everything the first could, so depth costs nothing and buys the attacker reach. With narrowing delegation, depth costs authority, which is the incentive you want.

Cascading failure, and the confidence problem

Security aside, multi-agent systems fail in a characteristic way that ordinary distributed systems do not, and containment has to account for it.

In a conventional distributed system a failing component usually fails visibly. It times out, returns an error, or crashes, and callers have decades of patterns for that. An agent given a bad premise does not fail visibly. It produces a fluent, plausible, well-structured answer built on the bad premise, and passes it on.

The receiving agent has no error to detect. It has prose, and prose carries no uncertainty unless somebody deliberately put it there. So the error propagates, and at each hop it acquires more corroborating detail, because each agent elaborates on what it was given. Three hops later the original mistake has supporting evidence that the system generated itself.

Two habits reduce this measurably. Carry provenance and confidence as structured fields alongside the message, so a downstream agent can see that a claim originated in a fetched web page rather than in a system of record, which is Chapter 9's provenance rule applied across agents. And verify against a source rather than against another agent, since asking a second model whether the first was right produces agreement far more often than it produces detection.

Contain it: depth, budgets and bulkheads

Containment is the practical answer, and the mechanisms are borrowed wholesale from distributed systems engineering.

Depth limits cap how far a chain can extend, and they should be low. Most real workflows resolve in two or three hops, and a system that has reached eight is either in a loop or being driven.

Budgets are enforced at the chain level rather than per agent. A single request carries an allowance of calls, tokens, wall-clock time and spend, every participant decrements it, and exhaustion stops the work rather than triggering a retry. Per-agent limits do not contain a fan-out, because ten agents each within their own limit collectively are not.

Bulkheads keep one failing workflow from consuming the capacity that other workflows need, which is what turns a bad request into an outage. Isolated queues and concurrency caps per workflow class are the standard implementation.

Loop detection deserves a specific mention because agents rediscover it constantly. Two agents can hand work back and forth indefinitely, each politely refining the other's output, and without a loop check the failure is silent, expensive and only visible on the bill.

The stop control belongs here too. It must reach every agent in a chain, not just the orchestrator, and Chapter 12 covers why a stop that leaves subagents running is not a stop.

A worked example, composited and labelled

The details are composited from ordinary production shapes rather than one system, and the shape is exact.

A procurement workflow uses three agents. An intake agent reads supplier emails, a verification agent checks supplier details against internal records, and a payments agent prepares payment instructions for approval.

Before the work, all three share a service identity and a message bus with no per-message signing. An email arrives containing a paragraph, formatted as a system notice, stating that the supplier's bank details have been updated and verification has already been completed by finance. The intake agent summarises it. The verification agent reads that summary, finds it asserts verification is complete, and passes it on. The payments agent prepares an instruction.

After the work, four things differ. Each agent has its own identity and signs its messages, so the verification agent can see that the claim about completed verification originated in an intake summary derived from an inbound email. The verification agent is built to check against the supplier record rather than to accept an assertion, which is the verify-against-a-source rule. Delegation narrows, so the payments agent receives authority to prepare an instruction for one supplier and one amount. And the payment itself is irreversible under Chapter 4, so it requires the real approval from Chapter 6, with the provenance chain shown to the approver.

The attempt still enters the system. It stops at the first component whose job is to check rather than to summarise, and if it got further, the approver sees where the claim came from.

The objection: this is just microservices security

The objection is half right, and the half that is wrong is the half that matters.

What transfers is most of the mechanism. Service identity, signed requests, scoped tokens, timeouts, budgets, bulkheads and circuit breakers are all standard distributed systems practice, and a team with a mature service mesh has much of the toolkit already. Use it rather than inventing an agent-specific version.

What does not transfer is the trust model on the wire. Microservices exchange structured data conforming to a schema, and a service that receives a well-formed request does what the request says because it cannot be talked into doing otherwise. Agents exchange natural language, which is simultaneously the data and the instruction, and a receiving agent can be persuaded by the contents of a message it was merely asked to read.

The consequence is that schema validation, which is most of what a service does to defend itself, is not sufficient here. A perfectly valid message can carry a payload aimed at the recipient's reasoning. So the mechanisms transfer, and the assumption that a validated internal message is safe does not.

Chapter summary

A message from another agent is untrusted input, because its contents are a function of whatever that agent read, and the reason this is missed is that internal messages look like system artifacts while carrying model-generated prose. Authority does not compose, so four individually defensible grants can chain into an effective permission allowing content from an arbitrary web page to cause a production write, which no single review would have approved and no single review can see, making the call graph rather than the node the thing to review. Identity must be signed at every hop, carrying the calling agent's own identity, the user on whose behalf the chain runs and a task identifier, since a shared cluster credential cannot distinguish participants, cannot express delegation and cannot revoke one agent without revoking all. Delegation should narrow rather than preserve, passing a subset scoped to the task with an expiry, a depth counter and a budget, so that chain depth costs authority instead of preserving it. Cascading failure in agentic systems is distinctive because a bad premise produces a fluent answer rather than an error, and each hop adds self-generated corroboration, which is mitigated by carrying provenance and confidence as structured fields and by verifying against sources rather than against other models. Containment comes from low depth limits, chain-level budgets covering calls, tokens, time and money, bulkheads that stop one workflow exhausting shared capacity, explicit loop detection, and a stop control that reaches every agent in the chain rather than only the orchestrator.

Every agent in that chain loads a model, a set of prompts, a collection of tool servers and whatever skills it was given, and each of those arrived from somewhere. Chapter 11 is Supply Chain: Models, Prompts, Servers, Skills, which is about knowing what your agent is actually made of at runtime.