Earlier quoted context omitted.
It's avoiding the problem by separating control and data, at unknown but signficant cost to functionality (the LLM which determines what tools get invoked doesn't see the actual data or results, only opaque tokens that refer to them, so it can't use them directly to make choices). I'm not sure how that qualifies as "security by obscurity".
It's attempting to split control and data through a system which is susceptible to the same issue. So prompt injection still works, you just have to find the right promt.
- The tool-using-LLM never sees data, only variables that are placeholders for the data.
- A post tool-using-LLM templating layer translates variables into content before passing them to a concrete tool.
- After variables are translated, only a non-priviledged (non-tool-using) LLM has access to the actual content.
- The output of a non-priviledged LLM is again another variable represented e.g. by the tokens $OUTPUT. The tool LLM never sees into that content. It can give it to another tool, but it cannot see inside it.
You can inject prompt into the non-priviledged LLM but it doesn't get to do anything.