Re:A GitHub Issue Title Compromised 4k Developer Machines
by TheFlyingFish on Friday March 06, 2026 @03:44PM
(#47280820)
The linked article isn't describing a form of input sanitization, it's a complete separation between trusted and untrusted contexts. The trusted model has no access to untrusted input, and the untrusted model has no access to tools.
Simon Willison has a good explainer on CaMeL: https://simonwillison.net/2025/Apr/11/camel/
Re:A GitHub Issue Title Compromised 4k Developer Machines
by zbentley on Friday March 06, 2026 @09:22PM
(#47283803)
That’s still only as good as the ability of the trusted model to delineate instructions from data. The untrusted model will inevitably be compromised so as to pass bad data to the trusted model.
I have significant doubt that a P-LLM (as in the camel paper) operating a programming-language-like instruction set with “really good checks” is sufficient to avoid this issue. If it were, the P-LLM could be replaced with a deterministic tool call.
At a fundamental level, having two contexts as suggested by some of the research in this area isn’t enough; errors or bad LLM judgement can still leak things back and forth between them. We need something like an SQL driver’s injection prevention: when you use it correctly, code/data confusion cannot occur since the two types of information are processed separately at the protocol level.