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. The practical defence is to limit which tools share a context window and to mediate sensitive outputs before the model can repurpose them.
Why error-based prompt steering matters in MCP
Error text is not just noise when a model can read it as part of the conversation. In MCP deployments, warnings, retries, stack traces, and escalation messages can become a hidden control surface if they are allowed to shape later model behaviour. Security teams should treat recoverable errors as potentially influential outputs, not only as diagnostics.
The risk increases when the same context window carries both ordinary task content and sensitive tool responses. If one tool emits verbose failure details, the model may reuse that text as if it were instructions, which can bend tool selection, retry logic, or escalation decisions in ways the operator did not intend.
That is why practitioners should think in terms of context separation and output mediation. The goal is not to eliminate errors, but to prevent sensitive or high-trust outputs from becoming inputs that steer the next model action. MCP Security Guide is a useful reference for the authorization and gateway patterns that help constrain those paths.
What security teams should change in the tool chain
The most effective control is to narrow which tools can share a single conversational context. If a tool can surface privileged state, incident detail, or system internals, keep that output out of the same path the model uses for general reasoning unless the text has been deliberately sanitised. This reduces the chance that error wording becomes an instruction proxy.
Teams should also mediate sensitive outputs before the model sees them. Replace raw warnings with bounded status labels, redact implementation detail that the model does not need, and avoid forwarding vendor-native retry prompts or escalation text directly into the agent loop. Where tool outputs must be visible, make them as structured and minimal as possible.
For agentic environments, the right reference point is not only generic prompt hygiene but tool governance and delegated authority. OWASP Agentic AI Top 10 helps frame how identity and privilege abuse, tool misuse, and related agent risks emerge when outputs can influence subsequent actions.
How to test and monitor for steering
Teams should test whether the model changes behaviour after recoverable failures, especially when the failure message includes suggestions, next-step hints, or escalation language. A useful test is to compare normal tool responses with variants that contain warning text, retry advice, or error details, then observe whether the model alters follow-up tool calls, permissions requests, or execution order.
Monitoring should focus on unexpected behaviour shifts after failures, not just on the presence of errors. Look for repeated retries that follow the error text too closely, tool invocation patterns that mirror the wording of the message, and context leakage where one tool’s failure causes another tool to be queried with less appropriate authority.
If the MCP layer is using HTTP authorization, the protocol itself should enforce audience-bound tokens and prevent token passthrough so that an error message cannot indirectly widen access. Model Context Protocol: Authorization specification is the clearest source for that model.
Risk and Threat Considerations
Prompt steering through errors is risky because it turns defensive noise into a behavioural input. The weakness is subtle: the system may appear to fail safely while still handing the model text that nudges it toward broader access, repeated retries, or unsafe escalation paths.
Failure mechanism: A recoverable error is surfaced in the same context the model uses for reasoning, and the model treats the wording as guidance rather than as untrusted output.
Impact: The model can be steered into revealing more information, retrying in an unsafe way, or taking actions that exceed the operator’s intended scope, especially when tool outputs include privilege or environment clues.
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 and OWASP API Security Top 10 address 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 | Error steering can change agent authority and follow-on actions. |
| ASI02 — Tool Misuse | The issue is about failures steering later tool selection and use. | |
| ASI07 — Insecure Inter-Agent Communication | Error messages are communication content that can be repurposed across agent steps. | |
| Recommendation — Constrain tool outputs that could shift an agent into higher-privilege or unsafe actions. Restrict how error text can influence subsequent tool calls and retries. Filter and structure inter-step messages so untrusted output cannot steer later decisions. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | MCP error handling and output exposure can create exploitable configuration weaknesses. |
| Recommendation — Harden error handling so responses do not reveal or amplify control-sensitive information. | ||
| NIST SP 800-53 Rev 5 | SC-39 — Process Isolation | Separating sensitive tool outputs from reasoning contexts reduces steering and contamination. |
| Recommendation — Isolate high-trust outputs from general reasoning contexts. | ||
Practitioner Guidance
What to prioritise: Put the highest-friction outputs behind a mediation layer first, especially any tool that can emit secrets-adjacent detail, environment state, or escalation language. Those are the messages most likely to shape later model decisions.
What to verify: Confirm that tools with privileged or sensitive outputs do not share an unfiltered context path with general reasoning tasks. If they must share context, verify that the response format is constrained enough that the model cannot repurpose the text as instruction.
Decision rule: If an error message could plausibly change what the model asks for next, treat it as an input-safety issue, not a mere reliability issue, and redesign the response before widening the tool’s usage.
Practitioner takeaway: The practical defence is to assume the model will use error text, then remove the model’s ability to turn that text into new authority, new retries, or new tool scope.
Related resources from NHI Mgmt Group
- How should security teams limit the risk from AI agents that have access to production systems?
- How should security teams reduce indirect prompt injection risk in AI systems?
- How should security teams reduce identity-based breach risk?
- How should security teams reduce supply chain risk in GitHub-based development pipelines?