[dead]
ANSI escape injection in MCP servers: Hidden from humans, visible to AI
11–20 of 46 posts
Re: ANSI escape injection in MCP servers: Hidden from humans, visible to AI
#12Every year is apparently a good year for developers to figure out how terminals have worked for decades? Just… don’t trust inputs you don’t fully control, there’s nothing else to it.
> 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 runnin…
How about the human in the loop, or have we abandoned that long ago?
Re: ANSI escape injection in MCP servers: Hidden from humans, visible to AI
#13Earlier quoted context omitted.
> 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 runnin…
How about the human in the loop, or have we abandoned that long ago?
i feel like that's the point with LLMs or i'm misreading your comment.
Re: ANSI escape injection in MCP servers: Hidden from humans, visible to AI
#14Every year is apparently a good year for developers to figure out how terminals have worked for decades? Just… don’t trust inputs you don’t fully control, there’s nothing else to it.
Ai devs rediscovering that basic software engineering principles exist for a reason speedrun any%
Re: ANSI escape injection in MCP servers: Hidden from humans, visible to AI
#15Earlier quoted context omitted.
> 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 runnin…
How about the human in the loop, or have we abandoned that long ago?
> have we abandoned that long ago?
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.
Re: ANSI escape injection in MCP servers: Hidden from humans, visible to AI
#16Earlier quoted context omitted.
> 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 runnin…
How about the human in the loop, or have we abandoned that long ago?
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...
Re: ANSI escape injection in MCP servers: Hidden from humans, visible to AI
#17Earlier quoted context omitted.
How about the human in the loop, or have we abandoned that long ago?
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...
A human should defintely be doing that.
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.
Re: ANSI escape injection in MCP servers: Hidden from humans, visible to AI
#18Earlier quoted context omitted.
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...
A human should defintely be doing that. 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.
Why! Do you use your eyeballs to spot SQL injection? Or do you maybe use a tool? A linter perhaps?
Re: ANSI escape injection in MCP servers: Hidden from humans, visible to AI
#19Every year is apparently a good year for developers to figure out how terminals have worked for decades? Just… don’t trust inputs you don’t fully control, there’s nothing else to it.
> 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 runnin…
> By design there is no separation between control & data channels in LLMs.
No? MCP integrations are certainly different channels than the prompt stream input by the user. They're usually interface layers that connect to traditional REST APIs and/or CLI tools, and are exposed to the LLM by the agent software, all of which is deterministic code.
Shouldn't it be relatively simple to strip ANSI escape sequences from data originating from MCP connections? Or alert users to their presence, or have granular approval rules that trigger when ANSI sequences are detected?
Re: ANSI escape injection in MCP servers: Hidden from humans, visible to AI
#20[flagged]