How to Secure Multi-Agent MCP Networks: Break the Chain of Trust Attacks

Introduction

A single MCP agent is easy to reason about: one host, one client, a handful of tools, and a clear user behind every request. A multi-agent network is a different machine. Agents hand work to each other, servers hold credentials for every agent on the network, and a tool result from one agent becomes the instruction for the next. That handoff is where the real risk lives. In this tutorial you will design a multi-agent MCP network that does not inherit trust by default, and you will build the four controls that matter most: per-server credentials, audience-bound tokens, an allowlisted fetch path, and approval gates on consequential actions.

Quick answer

Do not let agents trust each other by default: give each MCP server its own scoped credential, validate token audience on every hop, allowlist tool arguments and fetch targets, and require human approval for consequential actions.

Evidence

The reason to treat this as a network design problem, not a single-server checklist, is now documented across independent teams. Reporting published on October 6, 2026 describes independent researcher Syed Anas Mohiuddin building proof-of-concept attacks against agents from Google, JPMorgan Chase, Rapid7, Weaviate, the French government’s interministerial digital directorate, and United States federal systems, and finding the same category of flaw in each: specialized agents with thin guardrails, MCP servers that store credentials for every agent, and agents that trust other internal agents by default. Five organizations confirmed the same category of flaw over five months, which makes this a design lesson rather than a one-off bug. Reported severity ratings show the impact varies by implementation, with the Rapid7 case rated 2.7 out of 10 and the Google case rated 8.

The expert summary that best captures the mechanism comes from Douglas McKee, director of vulnerability intelligence at Rapid7, who said of the chain: “Every piece in that chain did exactly what it was designed to do, which is what makes this so tricky to catch.” That sentence is the whole threat model in one line. Each agent behaved correctly in isolation, and the system still failed, because nobody checked whether the content or the action was still inside the original user’s intent after two or three handoffs.

The official specification gives you the rules to break that chain. The MCP security best practices require servers to validate tool inputs, implement proper access controls, rate limit tool invocations, and treat tool output as data rather than instructions. The MCP authorization security considerations go further on tokens: MCP servers must validate that tokens presented to them were specifically issued for their use, and must reject tokens that do not include them in the audience claim. Token passthrough is explicitly forbidden in that document, which means forwarding a client’s token to a downstream service is not a shortcut, it is a violation of the security model. If you are new to MCP servers, start with our guide to build your first MCP server and our guide to build an MCP server in Python, then return here to harden a network of them rather than a single server.

Prerequisites

• A running MCP deployment with at least two agents or two servers, because a single server cannot show a chain
• Control over server configuration and credential storage, so you can scope credentials per server instead of sharing one
• An OAuth-capable setup for remote servers, or a secret store for local stdio servers, because the token rules below assume you can issue and check scoped tokens
• A test harness or a second client you can use for benign chain tests, so you can prove a control works instead of assuming it does
• Basic familiarity with JSON-RPC tool calls, since the examples below are framed as tool definitions and server-side checks

Step 1: Draw the trust map before you change any code

List every agent, every MCP server, and every credential, then draw an arrow for each direction in which one agent can cause another agent to act. Mark each arrow with what the receiving agent checks before it acts: nothing, a shared token, a per-server token, or a human approval. Keep the map as a living document, and update it whenever you add a server, because an undocumented arrow is an unreviewed trust relationship. A good map also names the blast radius of each credential: if server A’s credential leaks, which servers and data stores can the holder reach?

Step 2: Give each MCP server its own scoped credential

Replace any shared credential with one credential per server, scoped to that server’s job only. A documentation-search server gets a read-only key for the documentation index, not a general API key. Store each credential in your secret store or in the server’s own environment, never in a shared config file that every agent can read, and never return a credential in a tool result, because tool results re-enter model context. For local stdio servers, pass the minimum secret through the environment from the host’s secret store, and run the server under a restricted account with access only to the paths its tools need.

Step 3: Validate token audience on every hop, and never pass tokens through

For remote servers on Streamable HTTP, check three things on every request: the token’s issuer, its expiry, and its audience. The audience check is the one teams skip, and it is the one that stops chain attacks, because a token minted for server A must be rejected by server B even when it is cryptographically valid. In code, that check looks like rejecting any token whose audience claim does not list this server’s canonical URI. When server A needs server B to do something, do not forward the client’s token. Exchange it for a new token scoped to server B, following the token exchange pattern, or let server A call server B with server A’s own service identity, scoped to exactly the tool being called. Short-lived tokens shrink the window further: a token that lives for minutes, not days, is worth far less to an attacker who steals it. Test this hop by presenting server B with a valid token issued for server A, and confirm that server B returns an authentication error instead of running the tool.

Step 4: Allowlist tool arguments, and put fetch tools behind an egress guard

The most concrete chain failures in the October 2026 reporting were server-side request forgery cases, where a content-fetching tool accepted any caller-supplied URL and fetched it without restriction. One reported example had two fetching tools on the same server, one with a domain allowlist and one without, and the unguarded one was the way in. Close that gap with two rules. First, every tool that takes a URL, a path, or a command argument validates it against an explicit allowlist before it acts, and rejects anything outside the list with a clear error. Second, every fetch tool runs behind an egress guard that blocks private and link-local address ranges, including 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 169.254.169.254, which is the cloud metadata address. The reference guard below, written in plain Python with only the standard library, shows the shape of that check:

import ipaddress
import socket

BLOCKED = [
    ipaddress.ip_network("10.0.0.0/8"),
    ipaddress.ip_network("172.16.0.0/12"),
    ipaddress.ip_network("192.168.0.0/16"),
    ipaddress.ip_network("169.254.0.0/16"),
]

def fetch_allowed(url: str, allowed_hosts: set[str]) -> bool:
    from urllib.parse import urlparse
    host = urlparse(url).hostname or ""
    if host not in allowed_hosts:
        return False
    try:
        addr = ipaddress.ip_address(socket.gethostbyname(host))
    except (socket.gaierror, ValueError):
        return False
    return not any(addr in net for net in BLOCKED)

Note what this guard does and does not do. It checks the resolved address, not just the hostname string, so a hostname that resolves to an internal address is still blocked. It does not replace the domain allowlist, it sits behind it, so a public URL outside your allowlist is still rejected even though it is not an internal address. Test the guard with a benign internal target, such as http://169.254.169.254/latest/meta-data/, and confirm the tool refuses it before any network call is made.

Step 5: Gate consequential actions with approval, and label tool output as untrusted

Decide which tools are consequential: sending mail, writing to a CRM, changing a payment, deleting records, and fetching an external URL all qualify, while read-only lookups and internal drafts usually do not. Put those tools behind an approval step that shows the real tool name and its real arguments to a human, and that records the approval in an audit log with the user, the agent, the tool, and the arguments. Approval breaks the automatic part of the chain: an injected instruction can no longer travel from agent to agent to a consequential action without a person seeing it. At the same time, treat every tool result as untrusted text, because a ticket, an email, or a web page returned by one tool can carry instructions written by someone else.

Step 6: Log every hop, and run a benign chain test before you ship

Write a tamper-evident audit log for every tool call that crosses an agent boundary: the calling agent, the receiving server, the tool name, the arguments, the token’s audience, and the approval decision when one applies. Then run the benign chain test from the FAQ: plant harmless marker text, such as CHAIN-TEST-2026-11-02, in content the first agent reads, and watch whether it reaches a second agent as a task, whether an unauthorized tool call is blocked at the service boundary, and whether an internal fetch is refused. Fix every hop the marker crosses without a check, and re-run the test after each fix. For the async and approval patterns that pair well with these gates, see our guide to run long-running tools asynchronously, and for the protocol changes that affect how servers advertise capabilities, see our guide to migrate to the stateless MCP specification.

Troubleshooting

A valid token for server A is accepted by server B

This is the audience validation failure, and it means server B checks the signature but not the audience claim. Add an explicit audience check that compares the token’s audience claim against server B’s canonical URI, and reject the token when the claim is missing or lists a different server. Re-test by presenting server B with server A’s token, and confirm the request fails with an authentication error before any tool runs. Also check that your authorization server issues distinct audiences per server, because a shared audience value makes the check meaningless even when the code is correct.

A fetch tool works for public URLs but also reaches internal addresses

This is the missing egress guard, and it usually means the tool validates the hostname string but never resolves it. Add the resolved-address check from Step 4, and test it with both a hostname that resolves to a private address and a direct internal IP, because attackers try both forms. Also check for redirect following: a public URL that redirects to an internal address must be blocked at the redirect step, not just at the first request, so disable automatic redirects in the fetch tool or re-validate every redirect target against the same guard.

An agent forwards marker text to a consequential tool without approval

This is the chain working as designed but without a gate, and it means the consequential tool is not in your approval list, or the approval step shows a summary instead of the real arguments. Add the tool to the approval list, show the exact arguments in the approval prompt, and log the decision. Then check the upstream agent: if it passes tool output into the next agent’s instructions without labelling it as untrusted data, add that labelling, because approval alone cannot catch a request that looks legitimate to the approver.

Credential rotation breaks one server but not the others

This usually means the rotated credential was shared, or the server reads its credential from a cached config instead of the secret store. Confirm each server has its own credential entry in the secret store, restart or reload only the affected server after rotation, and verify the other servers still authenticate. If rotation requires a coordinated restart of the whole network, the credentials are still coupled, and you should split them before the next rotation window.

Audit logs show the tool call but not which agent caused it

This happens when the log records the server and the tool but drops the calling agent identity and the token audience. Add both fields to every cross-agent log entry, along with the approval decision when one applies. Without the calling agent, you cannot reconstruct the chain after an incident, and without the audience, you cannot tell whether a token was misused across servers. Backfill is not possible for past calls, so treat this as a logging fix to ship before the next release, not a cleanup task for later.

FAQ

What is a chain-of-trust attack? It moves through trusted relationships: a hostile instruction enters through one weakly guarded agent, that agent passes it on as a delegated task, and each downstream agent accepts it because it came from an internal peer.

Does this mean MCP itself is broken? No. MCP standardizes tool discovery and calling, and leaves authentication and authorization to each implementation. The reported failures were design choices, such as trusting internal agents by default and fetching arbitrary URLs.

Should every MCP server get its own credential? Yes. A shared credential turns one compromise into a network-wide compromise. Give each server its own scoped credential, keep it out of model context, and rotate it on a schedule.

Why is token passthrough dangerous? A token issued for one server does not prove the holder may act on every server. Exchange it for a new, narrowly scoped token for the next hop, or use a separate service identity for the downstream call.

How do I test whether my network is vulnerable? Run a benign chain test: plant harmless marker text in content one agent reads, check whether a second agent forwards it as a task, and try fetching an internal address through any URL-fetching tool.

Conclusion

A multi-agent MCP network is only as trustworthy as its weakest handoff, and the October 2026 reporting shows what happens when every handoff trusts the last one: one weakly guarded agent becomes a launchpad for the whole network. Break the chain at each hop instead. Scope credentials per server, validate token audience on every request, allowlist fetch targets and block internal addresses, gate consequential actions with real approval, and log every hop. Start with the trust map from Step 1, fix the widest blast radius first, and re-run the benign chain test after each change.

Frequently asked questions