The good regulator theorem makes that a little difficult.

I'm working on new technology where you separate the instructions and the variables, to avoid them being mixed up.

I call it `prepared prompts`.

It’s not that simple.

That would result in a brittle solution and/or cat and mouse game.

The text that goes into a prompt is vast when you consider common web and document searches are.

It’s going to be a long road to good security requiring multiple levels of defense and ongoing solutions.

Turtles all the way down; got it.

Isn't that just another guardrail that can be bypassed much the same as the guard rails are currently quite easily bypassed? It is not easy to detect a prompt. Note some of the recent prompt injection attack where the injection was a base64 encoded string hidden deep within an otherwise accurate logfile. The LLM, while seeing the Jira ticket with attached trace , as part of the analysis decided to decode the b64 and was led a stray by the resulting prompt. Of course a hypothetical LLM could try and detect such prompts but it seems they would have to be as intelligent as the target LLM anyway and thereby subject to prompt injections too.

This adds latency and the risk of false positives...

If every MCP response needs to be filtered, then that slows everything down and you end up with a very slow cycle.

Essentially a motte-and-bailey. "mitigate" is the same. Can be used when the risk is only partially eliminated but you can be lucky (depending on perspective) the reader will believe the issue is fully solved by that mitigation.