1,231 karma · joined March 29, 2015
In a REPL, the output is printed. In a LLM interface w/ MCP, the output is, for all intents and purposes, evaluated. These are pretty fundamentally different; you're not doing "random" stuff with a REPL, you're evaluating a command and _only_ printing the output. This would be like someone copying the output from their SQL query back into the prompt, which is of course a bad idea.
Nothing exists like this for an LLM.
An XSS mitigation takes a blob of input and converts it into something that we can say with certainty will never execute. With prompt injection mitigation, there is no set of deterministic rules we can apply to a blob of input to make it "not LLM instructions". To this end, it is fundamentally unsafe to feed _any_ untrusted input into an LLM that has access to privileged information.
It sounds to me like something needed to be recompiled and redeployed.
I'd be curious to hear more about this, whether from the author or from someone who does something similar. When the author says "background", does that literally mean JIRA tickets are being assigned to the agent, and it's spitting back full PRs? Is this setup practical?
This only scales so far. After some point, it's very easy to run into cases where you meant to change something everywhere but forgot/didn't know about others. Not to say everything should be so compartmentalized as to restrict change, but there is a balance to be had.
EDIT:
> [the test synchronous programs] all seem to run fine, and very basic threaded programs work, sometimes
Perhaps this is closer to removing the oil pan
I was a much different person then in terms of what I considered to be acceptable (who wasn't, at 16?), but I still find the story amusing.
Yeah, this was 2015-2016. Yes, the school printer and my home printer supported it, I was just forgetful and a bit of a smartass :)