You can write your code so SQL injections are not possible.

You can't do the same with prompt injections.

The link talks about more than just SQL injection. SQL injection can be fully mitigated using prepared statements. They were the solution 15 years ago when I was getting started with PHP in high school and it's still applicable today. The fact that SQL injection remains an issue speaks volumes about the general quality of software engineers.

It's trivial to protect against SQL injection. It requires only a bit of discipline to avoid concatenating user data into queries. Anyone still vulnerable at this point is simply incompetent.

It's not about if it can happen or if it happens.

It's about how easily it's mitigated completely. Use a proper db library which does escaping and it's completely eliminated.

It still happens, problems that are solved still happen when people don't take care to apply the solution. Diseases that were solved problems happen again when people stop taking the vaccines.

You can avoid SQL injection by just coding the same features with a bit of care. You loose nothing. Mistakes can always happen, but it's not even tricky to prevent SQL injection.

Right now the only way to avoid Prompt injection is to not let your agents see user input at all. A very wide range of features that we'd like to implement are unsafe and there isn't a way to prevent this reliably.

I guess we'll need to get used to control the agent's permissions very tightly, and taylor them per-conversation. The agent I speak to for customer support must only have access to my data, and not because of instructions in the system prompt, these will need to be hard limits.

sqli is easily and fully mitigated and has generally been a non-issue for any half-serious project, especially if you use any kind of SAST. Your link actually subsumes any type of injection, not just sqli. Some of them are marginally harder to fix than sqli, most aren't.

In contrast, we don't know how to solve prompt injection.