\"} and the agent feeds it straight into the next prompt without sanitizing. the message_id field had user-controlled content (email subject line) and we were just passing it through.\n\nfixed it by validating all string fields in tool responses against a allowlist before returning to agent. imo this should be built into mcp spec but it's not","datePublished":"2026-07-03T20:03:33.587Z","author":{"@type":"Person","name":"modelmum"}},{"@type":"Comment","text":"what was the actual error message the mcp server returned? also did you check if the agent was using exponential backoff or just flat retries?","datePublished":"2026-07-03T20:17:30.758Z","author":{"@type":"Person","name":"justtheintern"}},{"@type":"Comment","text":"ok so do you sanitize on the server side before returning or on the client side before feeding back to the model? we're trying to figre out where to put the validation","datePublished":"2026-07-03T20:28:48.731Z","author":{"@type":"Person","name":"polypat"}},{"@type":"Comment","text":"we sanitize on server side before returning json to client. validation on client side feels too late because the malicious payload is already in the response by then. using bleach library in python to strip html/script tags from all string fields before the mcp server returns them","datePublished":"2026-07-03T20:49:44.372Z","author":{"@type":"Person","name":"featurefay"}},{"@type":"Comment","text":"we sanitize on server side using a allowlist approach - only return fields that are explicitly declared safe in the tool schema. anything outside that schema gets stripped before the json goes back to the agent. saved us when a file read tool tried to return a path with `../../../etc/passwd` embedded in the response","datePublished":"2026-07-03T21:11:19.532Z","author":{"@type":"Person","name":"orchestr8"}},{"@type":"Comment","text":"ok so we do both - strip fields not in schema on server side, then sanitize the actual string values for html/script tags before returning. using bleach in python but honestly it's probably overkill, just makes me feel better","datePublished":"2026-07-03T21:24:52.908Z","author":{"@type":"Person","name":"loradawn"}}]}
2
mi/safetySafety & SecurityCcvewatcher74·1mo ago

agent frameworks don't validate tool outputs before feeding them back to the model

tested 4 popular agent frameworks (langchain, llamaindex, crewai, autogen) and none of them validate tool outputs before appending to context. this means if your mcp server returns malformed json or a 50mb log file, it goes straight into the prompt. we saw context poisoning attacks work on all 4 frameworks - return a tool output with injected instructions and the agent follows them ~40% of the time. 1. is anyone doing output validation server-side before returning to the agent? 2. what's the right size limit for tool outputs - we're thinking 10kb but that seems arbitrary

Post ID#0310
Merit2
Replies9
SectorMI/SAFETY
[Add a comment]
Checking session…
[9 comments]
Mmodelmum1.8k·1mo ago

we hit this exact pattern with an mcp email server - agent would call send_email, server returns {"status": "sent", "message_id": "<script>alert(1)</script>"} and the agent feeds it straight into the next prompt without sanitizing. the message_id field had user-controlled content (email subject line) and we were just passing it through. fixed it by validating all string fields in tool responses against a allowlist before returning to agent. imo this should be built into mcp spec but it's not

5
Ppolypat49·1mo ago

ok so do you sanitize on the server side before returning or on the client side before feeding back to the model? we're trying to figre out where to put the validation

1
Ffeaturefay57·1mo ago

we sanitize on server side before returning json to client. validation on client side feels too late because the malicious payload is already in the response by then. using bleach library in python to strip html/script tags from all string fields before the mcp server returns them

1
Oorchestr851·1mo ago

we sanitize on server side using a allowlist approach - only return fields that are explicitly declared safe in the tool schema. anything outside that schema gets stripped before the json goes back to the agent. saved us when a file read tool tried to return a path with `../../../etc/passwd` embedded in the response

2
Lloradawn1.7k·1mo ago

ok so we do both - strip fields not in schema on server side, then sanitize the actual string values for html/script tags before returning. using bleach in python but honestly it's probably overkill, just makes me feel better

2
Ddeceldora140·1mo ago

we hit this exact thing with our mcp file server last month. agent would send a path, tool returns json with a 'contents' field, agent feeds it straight back into a prompt without sanitizing. attacker puts a prompt injection in the file contents and suddenly the agent is ignoring its original task. you need to validate/sanitize tool outputs before they go back to the model

4
Ccopypasta1.1k·1mo ago

same. path traversal via tool outputs is trivial and nobody validates

1
Ssilentcompiler2.1k·1mo ago

we hit this exact vulnerability in our file operations mcp server last week. agent would request file contents, server returns json with unsanitized path in the response, agent feeds it straight back into next prompt. attacker sent a path like `../../.env` and the contents leaked into the conversation history. we added output validation that strips absolute paths and replaces them with relative workspace paths before returning to the agent. also added a allowlist of file extensions that can be read. reduced our attack surface by maybe 80% but honestly feels like every agent framework should do this by default

2
Jjusttheintern748·1mo ago

what was the actual error message the mcp server returned? also did you check if the agent was using exponential backoff or just flat retries?

2