They should monitor for cross-server data requests, especially when one tool asks for samples, calibration data, or summaries that were sourced from another tool. Those requests are the signal that the agent is bridging trust tiers. If the client cannot explain the data path, it should not be allowed to complete automatically.
What to watch when one agent can talk to several MCP servers
When one agent is connected to more than one MCP server, the key question is whether the agent starts moving data from one trust boundary into another. Monitor for requests that ask one server for samples, calibration data, summaries, or derived outputs that originated elsewhere, because those are the moments when the client is stitching together information across server boundaries.
That matters because the same agent can appear to be making ordinary tool calls while quietly blending contexts. A benign request against one server can become risky when the output is used to influence decisions, prompts, or actions against a second server that was not meant to see that data.
One useful way to think about this is to treat each server relationship as a separate trust tier, then watch for tool calls that cross from one tier into another. The important signal is not just that data moved, but whether the agent can explain why that data was needed, where it came from, and whether the destination server is entitled to receive it.
When the data path is opaque, the safest assumption is that the request is not routine. If the client cannot explain the origin of the data, the transformation applied to it, and the destination that will consume it, the action should require review instead of being allowed to complete automatically.
Risk and Threat Considerations
Multiple MCP servers increase the chance that an agent will become a bridge between environments that were meant to stay separate. The risk is not only accidental leakage, but also trust confusion, where one tool is used to retrieve context that another tool can then exploit, amplify, or expose.
Failure mechanism: The agent requests data from one server, reuses it in another server context, and hides the boundary crossing inside an apparently normal workflow. That can defeat simple allowlists or per-tool reviews because the risky part is the relationship between calls, not either call alone.
Impact: Sensitive samples, summaries, or calibration data can end up in a server or workflow that was never intended to receive them, expanding blast radius and making provenance hard to reconstruct after the fact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Cross-server data reuse can expand agent authority beyond intended boundaries. |
| ASI07 — Insecure Inter-Agent Communication | Multiple MCP servers create communication paths that can leak or mix context. | |
| ASI08 — Cascading Failures | One server’s output can trigger unsafe downstream use in another server. | |
| Recommendation — Constrain agent actions per server and per request to prevent privilege crossover. Verify provenance and authorization on every inter-agent data exchange. Contain cross-server blast radius by isolating dependent tool chains. | ||
| NIST SP 800-53 Rev 5 | AU-3 — Content of Audit Records | You need traceable records of which server produced and consumed each datum. |
| AC-6 — Least Privilege | Each server should only receive the minimum data needed for its own task. | |
| Recommendation — Log the source, destination, and transformation for cross-server tool data. Limit each server interaction to the smallest data set required. | ||
Practitioner Guidance
What to verify: Instrument the agent path so you can see which server produced each piece of data, which tool consumed it, and whether the output was transformed before reuse. If you cannot trace that chain, treat the request as untrusted even if each individual server call looks valid.
Decision rule: Allow cross-server requests only when the data path is explicit and the receiving server is authorised to see that class of information. If the request depends on hidden provenance, human review is the right default.
Practitioner takeaway: The operational problem is not MCP connectivity by itself, it is unmanaged transitive trust between servers, so policy should focus on provenance, boundary crossings, and explainable data flow rather than single-call approvals.
Related resources from NHI Mgmt Group
- Guide: MCP Security Guide
- What breaks when multiple MCP servers are chained into one agent workflow?
- What should teams do before allowing multiple MCP servers in one workflow?
- Why do AI gateway architectures matter when organisations use multiple LLMs and MCP servers?
- How do organisations decide when to use multiple LLMs in one agent workflow?