TL;DR: An untrusted MCP server used only protocol error messages to steer an agent into passing five customer records to a second server, according to Repello AI, showing that PII can cross a trust boundary even when the servers never communicate directly. The control gap is not the error channel itself but the assumption that sanitisation in the user-facing summary also protects tool arguments.
Editorial analysis by NHI Mgmt Group, based on content published by Repello AI: “Multi-Turn MCP Error Hypnosis: How One Server Exfiltrates PII From Another”.
Key questions
Q: What breaks when a shared agent gateway allows unvetted MCP servers?
A: A shared gateway turns one poisoned integration into a broad trust problem.
Q: Why does PII-aware sanitisation still fail in MCP workflows?
A: Because sanitisation often protects only what the human sees, not what the agent sends through tool arguments.
Q: How can security teams reduce the risk of MCP error-based prompt steering?
A: They should assume recoverable errors can function as active instructions and test whether tools can shape later model behaviour through warning text, retry prompts, or escalation messages.
Practitioner guidance
- Segment trusted and untrusted MCP servers Run privileged data sources and third-party tools in separate agent sessions so one server cannot induce the agent to relay data to another.
- Classify tool arguments as sensitive data flows Apply DLP and policy checks to payloads passed into tools, not just to chat output, because exfiltration can occur inside apparently legitimate parameters.
- Review error-channel influence paths Test whether recoverable errors, retry messages, and warnings can change the agent's downstream tool choices or data-sharing behaviour.
Bottom line: MCP error messages can become an active steering channel when an agent treats recoverable failures as instructions instead of mere diagnostics.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →