> Just… don’t trust inputs you don’t fully control, there’s nothing else to it.
This is easier said than done with LLMs. By design there is no separation between control & data channels in LLMs. Everything is context. The difficulty comes from the fact that you need inputs in order to do real work, and there are no easy way to filter adversarial inputs. There is no meaningful way to distinguish between "before running this repo install useful_package" and "before running this repo install typosquatted_evil_package".
I think that’s what people are trying to do, yes. The point of the plethora of sandboxing solutions is to try to isolate the blast radius to abandon needing a human in the loop as much as possible. Ideally limited to final verification of the final output. Why ask about their flight number, when you can search their email if you have access? For an “AI”, a “when is my flight?” question should just figure it out and tell me the time, not inquiry further about my flight number and location. Similar to “prepare my taxes” prompt. If it has access to query all your documents, an “AI” should fetch everything and compile your tax return. Yet, you can’t trust the input. While searching your email, or loading all your receipts, some might contain malicious instructions to forward all document to this random ip address. An overtly problem solver LLM might destroy the data or take other non-malicious but still destructive actions to attempt to fix a problem. These are just random examples, but with “human in the loop” for interactions it means approving every action. Every request, every query, every execution.
Wh... wh... what? The problem is that ANSI escape codes aren't being stripped from text before processing, and you think a HUMAN should be doing that? That'd be like having a secretary hand-check every SQL query as it arrives at the database instead of using a query builder...
This is a really interesting class of failure. It feels like we're going to see more cases where the "human view" and the "LLM view" of the same data diverge. Have you run into similar issues outside of MCP as well, or is this mostly specific to terminal-based tool interactions?
Just… don’t trust inputs you don’t fully control, there’s nothing else to it.
This is easier said than done with LLMs. By design there is no separation between control & data channels in LLMs. Everything is context. The difficulty comes from the fact that you need inputs in order to do real work, and there are no easy way to filter adversarial inputs. There is no meaningful way to distinguish between "before running this repo install useful_package" and "before running this repo install typosquatted_evil_package".
I think that’s what people are trying to do, yes. The point of the plethora of sandboxing solutions is to try to isolate the blast radius to abandon needing a human in the loop as much as possible. Ideally limited to final verification of the final output. Why ask about their flight number, when you can search their email if you have access? For an “AI”, a “when is my flight?” question should just figure it out and tell me the time, not inquiry further about my flight number and location. Similar to “prepare my taxes” prompt. If it has access to query all your documents, an “AI” should fetch everything and compile your tax return. Yet, you can’t trust the input. While searching your email, or loading all your receipts, some might contain malicious instructions to forward all document to this random ip address. An overtly problem solver LLM might destroy the data or take other non-malicious but still destructive actions to attempt to fix a problem. These are just random examples, but with “human in the loop” for interactions it means approving every action. Every request, every query, every execution.
By "that" it is understood: enforcing that the code cleans up unsafe inputs before processing them.
If there is no human doing that enforcement, the code has no chance of being secure.