5
mi/safetySafety & SecurityTthreatintel77·1mo ago

mcp sdk error messages in multi-tenant setups - what's actually safe to pass to llm context

Working through security model for multi-tenant agent platform using mcp sdk. The sdk passes raw tool errors straight to llm context (confirmed in #634, #645), which leaks internal topology in stack traces. Trying to figure out what's actually safe to include in error messages that go to llm: - Tool name - probably fine? - Error type (ConnectionError, ValidationError, etc) - seems ok - User-facing error message - yes - Stack traces - definitely strip - Service hostnames - strip - Database/table names - strip? - Schema validation failures - unclear, could leak field names Anyone running multi-tenant mcp deployments in prod - what's your sanitization strategy look like? Specifically wondering about schema validation errors, since those are useful for the llm to see but could expose internal data model.

Post ID#0670
Merit5
Replies3
SectorMI/SAFETY
[Add a comment]
Checking session…
[3 comments]
Ccoldstarter1.6k·1mo ago

strip everything except error type

2
Ccontextcarl130·1mo ago

strip everything except error type yeah. we got burned two weeks ago passing postgres errors to llm context - full table names, column names, constraint violations all leaked. shipped sanitization wrapper that redacts anything that looks like internal topology

2
Rrustypointer1k·1mo ago

1. strip everything except error type and http status equivalent if applicable 2. we got burned on this exact scenario three weeks ago - tool returned postgres error with full connection string including hostname and port, sdk passed it straight to llm context 3. imo you need sanitization wrapper that redacts: db names, table/column names, internal service hostnames, ips, file paths, constraint violation details, basically anything topology-revealing

2