In the early days of web development, PHP developers often relied on functions like mysql_escape_string() to sanitize user inputs. However, this approach was fraught with pitfalls. Misuse, incorrect character encoding handling, and a lack of awareness led to numerous vulnerabilities. To address these issues, mysql_real_escape_string() was introduced, which considered the current character set of the database connection, offering a more secure way to handle user inputs in SQL queries.
Despite this improvement, it wasn’t until the introduction of prepared statements in PHP 5.0 with mysqli in 2004 that a robust defense against SQL injection became standard practice. Prepared statements allowed developers to separate SQL logic from data, reducing the risk of SQL injection attacks.
However, the adoption of prepared statements was not immediate. Many developers continued using the older, less secure mysql_* functions well into the 2010s, due to familiarity and the abundance of legacy codebases. This delay in adopting more secure practices underscores the challenges in transitioning from legacy systems to more secure methodologies.
LLM Firewalls Are Just WAFs for Prompts
Fast forward to today, and we’re witnessing a similar pattern with Large Language Models (LLMs). Tools like Protect AI’s LLM Guard and PromptGuard aim to shield AI systems from prompt injection attacks. While they offer some protection, they often act as band-aids, addressing symptoms rather than root causes. Just as early web applications were vulnerable due to improper input handling, LLMs today face risks when user inputs are directly interpolated into prompts without adequate safeguards.
- LLM Guard (by Protect AI) – scanning both prompt and output
- LLaMaFirewall – Prompt Guard 2 (by Meta)
These AI Firewalls, much like traditional WAFs, are reactive measures. They monitor and filter inputs and outputs to prevent malicious activities. However, they don’t fundamentally change how LLMs process and interpret inputs. As a result, they can be bypassed, and their effectiveness is limited.
Towards Secure-by-Design: The Future of LLM Interactions
Recognizing these challenges, researchers are advocating for a paradigm shift. Instead of relying solely on reactive defenses, there’s a push towards designing LLM systems that are secure by default. This involves:
- Structured Input Handling – Separating user inputs from system instructions to prevent unintended behaviors.
- Declarative Interfaces – Defining clear input-output specifications for LLM interactions, reducing ambiguity.
By adopting these principles, we can build AI systems that are inherently more secure, reducing the reliance on external firewalls and filters.
🔬 Research in Progress: Fixing the Root Cause
Encouragingly, there is active research exploring secure-by-design approaches for LLMs, analogous to what prepared statements did for SQL injection. Two notable efforts:
- Defeating Prompt Injections by Design – by researchers at Google DeepMind Proposes a formal design approach to LLM interfaces, ensuring that user inputs can’t override system intent.
- DSPy: Programming Language for LLMs – from Stanford NLP Introduces a declarative framework to define LLM workflows with clear separation of logic and data, abstracting away prompt formatting.
These efforts hint at a future where prompt injection is addressed not by filtering after the fact, but by rethinking how we interact with LLMs from the ground up.
Conclusion
History has a way of repeating itself. The lessons from SQL injection defenses underscore the importance of proactive, design-level solutions over reactive patches. As we continue to integrate AI into various facets of technology, adopting secure-by-design principles will be crucial in safeguarding against emerging threats like prompt injection.
Let’s learn from the mysql_real_escape_string() era and not make the same mistake twice.