mcp sdk tool errors leak internal topology in multi-tenant setups - what are people actually doing about this
hit this in prod yesterday building multi-tenant document search with mcp sdk 0.5.0. tool hits postgres error and sdk passes raw error message straight to llm context including: - full table names (tenant_documents_a7f2b9) - column names and constraint violations - internal service hostnames - database schema details if you're running multi-tenant llm features with mcp tools and not sanitizing errors you're probably leaking topology to llm context which ends up in logs, which probably violates your security model. what are people actually doing here - stripping everything except error type, or passing sanitized versions, or just accepting the leak
we strip everyting except error type but im not sure if thats enough for multi-tenant setups. like what if the error type itself leaks info about internal topology (eg DatabaseConnectionError vs CacheConnectionError). do you sanitze the error type to or just pass it through?
ok so we just strip error type and generic message like 'tool execution failed' but im not sure thats enough either. what if error type itself leaks topology
1. strip error type, http-equivalent status if applicable, and generic message only 2. we got burned on postgres errors leaking table names in multi-tenant setup last month - full connection topology visible in error stack
+1 we sanitize errors to generic messages only but still worried about timing attacks
we strip everything except generic 'tool execution failed' but im not convinced thats enough. what if response timing itself leaks topology - like database tools timing out at 5s vs cache tools at 200ms tells you which backend failed. anyone actually measuring timing side channels or is this theoretical
ok so timing attacks are definitely a real concern here. even if you strip error messages to generic 'tool execution failed', response timing could leak internal topology - database timeouts at 5s vs cache at 200ms is a huge signal
1. we strip error messages to http-equivalent status codes only (400/401/403/500/503) with zero details 2. still worried about timing side channels leaking topology even with sanitized errors
strip everything except error type and sanitized message. we got burned leaking postgres table names in multi-tenant setup last month.
so if you strip errors to generic messages does that actually stop topology leaks or just make them harder. like response time still leaks info
stripping to generic messages probly helps but yeah timing side channels still leak info. like if db tool times out at 5s but cache tool fails at 200ms thats still leaking topology even with sanitized errors