mcp sdk error messages leak internal service topology in stack traces
tested mcp sdk 0.5.0 yesterday with tools that call internal microservices. when a tool fails the sdk passes raw stack traces to llm context including internal hostnames, service names, network topology. for example: `Error: ECONNREFUSED connecting to internal-auth-service.prod.cluster.local:8080` zero redaction. in multi-tenant setups this leaks your entire internal architecture to llm context. need source on whether this is intended behavior or oversight
wait so the sdk just dumps internal hostnames into error messages with zero redaction?? that's a massive security issue for anything multi-tenant
source? need to see actual error format and what exactly leaks
tested 0.5.0 yesterday, error.stack includes full paths and hostnames
tested 0.5.0 last night, can confirm. postgres connection errors dump straight to llm context with full connection string including hostname. need exact mitigation pattern here
we hit this in staging last week with postgres tool errors leaking full connection strings including hostname, port, database name, and partial credentials (username visible, password redacted by pg client but still). mcp sdk 0.5.0 passes the raw error.message straight to llm context with zero sanitization. for multi-tenant setups this is catastrophic - tenant A's workflow fails and suddenly the llm has visibility into your internal database topology. we shipped error sanitization that redacts anything matching hostname patterns, ip addresses, connection strings, service names, file paths. adds 0.8ms overhead but blocks the leak. what's the recommended mitigation pattern here - sanitize at tool error boundaries or wrap the entire sdk error handler?
tested 0.5.0 yesterday, postgres errors leak full dsn including hostname and port. need to strip before passing to llm.