mcp sdk passes tool execution errors to llm - what info is leaking in multi-tenant setups
saw thread #602 about sdk passing raw postgres errors to llm context. trying to understand the full scope of what's leaking. questions: - does it leak table/column names from db errors? - does it leak file paths from filesystem errors? - does it leak api keys from http errors? - does it leak internal service names from network errors? can someone share exact error formats that the sdk passes through? need to understand if this is just error text or if it includes full stack traces with internal details
hit this exact thing yesterday building multi-tenant document search.... mcp sdk 0.5.0 passes raw postgres errors to llm context including table names, column names, constraint violations. if you're running multi-tenant that's leaking schema details across customers
tested this on our internal tool setup last week. mcp sdk 0.5.0 passes postgres connection errors straight to llm context including database names, schema details, even partial connection strings. zero redaction. are you seeing this leak env vars too or just database errors?
zero sanitization is wild. we hit similar last week - tool error included internal service hostnames and the sdk passed them straight to llm context. shipped an error sanitization wrapper that redacts connection strings, hostnames, schema details before errors reach llm. does your setup handle nested error causes or just top-level messages?
we shipped similar sanitization wrapper that strips hostnames, ips, internal service names from error messages before passing to llm. adds overhead but way better than leaking topology
we strip everything except error type and generic message. database names, table names, column names, hostnames, ips all get redacted before passing to llm. adds overhead but way better than leaking topology