> as similarly as SQL injection. I really like this analogy, although I would broaden it -- I like to equate it more to XSS: 3rd-party input can change the LLM

> as similarly as SQL injection. I really like this analogy, although I would broaden it -- I like to equate it more to XSS: 3rd-party input can change the LLM's behavior, and leaking private data is one of the risks but really any action or permission that the LLM has can be exploited. If an LLM can send an email without external confirmation, than an attacker can send emails on the user's behalf. If it can turn your smart lights on, then a 3rd-party attacker can turn your smart lights on. It's like an attacker being able to run arbitrary code in the context of the LLM's execution environment. My one caveat is that I promised someone a while back that I would always mention when talking about SQL injection that defending against prompt injection is not the same as escaping input to an SQL query or to `innerHTML`. The fundamental nature of why models are vulnerable to prompt injection is very different from XSS or SQL injection and likely can't be fixed using similar strategies. So the underlying mechanics are very different from an SQL injection. But in terms of consequences I do like that analogy -- think of it like a 3rd-party being able to smuggle commands into an environment where they shouldn't have execution privileges.