One agent with a narrow job is manageable. The trouble starts when a company connects several: one reads incoming requests, another drafts replies, a third updates the CRM, a fourth checks the result. Each agent may be well controlled on its own. The risk sits in the connections, where one agent's output becomes another agent's instruction.
This article is for the manager who is about to link agents together, or already has. It does not repeat how to give a single agent its own identity or how to stop one that misbehaves. For those, see identity and least privilege, prompt injection controls, and incident response and kill switches. For the design side of coordination, see the orchestration guide.
Why several agents change the risk
With a single agent, you can ask what it can see and what it can do. With a chain, a new question appears: what can it make another agent do?
Three things make chains harder than single agents:
- Instructions travel. A support agent reads a customer email that contains a hidden instruction. It summarises the email for a billing agent. The billing agent sees a summary from a colleague, not text from a stranger, and may trust it more than it should.
- Permissions add up. Agent A can read files but not send email. Agent B can send email but not read files. If A can ask B to act, the pair can do what neither was meant to do alone.
- Errors compound. A small mistake in step one becomes the input of step two. By step four it looks like a confident fact.
OWASP's guidance on LLM applications lists excessive agency, meaning too much functionality, permission, or autonomy, as a distinct risk. Linking agents is one easy way to create it without ever granting a single large permission.
Draw the trust boundaries on paper first
Before building, draw the agents as boxes and the hand-offs as arrows. For each arrow, write down three things:
- What passes across. Free text, structured fields, files, or links? Structured fields with fixed names are easier to check than prose.
- Who is the source. Did the content come from your own system, from a customer, or from the open web? Mark it, and keep that mark attached as the content moves on.
- What the receiver may do with it. Read it as data, or treat it as an instruction?
The last point matters most. A good default is that content from another agent is data, never a new instruction. The receiving agent acts on its own assignment and uses the incoming content only as material for it. If an agent must accept instructions from another agent, say so explicitly and limit the set of allowed requests to a short list.
Delegate the task, not your authority
When agent A hands work to agent B, a common shortcut is to let B use A's credentials, or to give B the same broad access "so it works". This copies the largest permission in the chain to every agent.
A safer pattern:
- Give each agent its own identity and its own narrow permissions.
- Pass only the data the task needs. If B drafts a reply, it needs the question and the relevant order, not the whole customer record.
- Make delegation a request that can be refused. B should be able to decline a task outside its role, and that refusal should be logged.
- Limit depth. Decide how many hand-offs a task may go through, and stop it if it goes further. A task that bounces between agents with no end is both a cost problem (see cost controls and loop limits) and a sign that something is wrong.
The open protocols for agent-to-agent communication, such as the Agent2Agent (A2A) protocol, and for connecting agents to tools, such as the Model Context Protocol (MCP), standardise how agents talk. They do not decide what your agents should be allowed to ask of each other. That remains your policy. The MCP specification, for example, has a dedicated authorization section; reading it shows how much of the permission design is left to the implementer.
Shared memory is shared attack surface
Many multi-agent setups give the agents a common notebook, vector store, or ticket history, so that work is not repeated. This is useful, and it needs rules.
- Who may write. If every agent can write to shared memory, one compromised or confused agent can plant a false "fact" that all others will later read. Allow writes only from agents whose job requires them, and record who wrote each entry.
- What may be stored. Do not let customer data, credentials, or content from untrusted sources flow into memory that many agents can read. Apply the same rules as in data handling and retention.
- How entries expire. Old notes become wrong. Give entries a date and a review or deletion rule.
- Separate by sensitivity. Keep a memory for public product information apart from one for customer cases. An agent that needs only the first should not be able to query the second.
OWASP also describes weaknesses specific to vectors and embeddings, such as leakage between users or tenants in shared stores. If your shared memory is a vector store, ask your engineers how access is separated.
Check at the hand-off, not only at the end
A final review of the last output catches some problems, but by then the damage may be done: the second agent may already have sent the email. Put light checks at the arrows:
- Format check. Does the hand-off contain the expected fields and nothing extra?
- Scope check. Is the request within what the receiver is allowed to do?
- Source check. Does content from an untrusted source carry its mark?
- Human check for consequential steps. Payments, deletions, external messages, and contract changes should wait for a person. See human approval and audit trails.
These checks can be plain code, not another model. A simple rule that rejects a hand-off with a missing field is more predictable than an agent asked to "be careful".
Keep the chain visible
When something goes wrong in a chain, the first question is always which agent did what, in which order, and why. Give every task one identifier that follows it through all agents, and log each hand-off with that identifier, the sending and receiving agent, and the decision taken. This is the same principle as in observing agents without leaking data, applied across several agents instead of one.
Test the chain as a whole, too. Each agent can pass its own tests while the combination fails. Include cases where one agent returns a wrong or hostile result and check whether the next agent catches it. See evaluating reliability before production.
One owner for the whole chain
Accountability tends to disappear in multi-agent systems. The team that built the intake agent assumes the team that built the billing agent checks the data. Nobody owns the combination.
Name one person responsible for the end-to-end behaviour, with authority to pause any agent in the chain. Give them a map of the agents, their permissions, and their hand-offs, and a date for reviewing it. When an agent is added or its permissions change, the map changes first.
Start smaller than you think
You do not need a dozen agents to learn these lessons. A practical start:
- Connect two agents only, with one direction of hand-off.
- Make everything crossing the boundary structured and logged.
- Run it in shadow mode first, as described in the staged rollout guide.
- Add a third agent only after the first two have run cleanly for a few weeks.
A checklist before you connect agents
- A diagram of agents and hand-offs, with the content type, source, and allowed use on each arrow.
- Content from other agents treated as data unless an explicit, short list of instructions is allowed.
- Separate identities and narrow permissions for every agent; no shared credentials.
- A limit on hand-off depth and a log entry for every refused task.
- Rules for who writes to shared memory, what is stored, and when it expires.
- Checks at the hand-off, and human approval for consequential steps.
- One task identifier across all logs.
- A named owner of the whole chain who can pause any part.
