Part 8 of The AI Engineering Playbook, we secure the system. A practical guide to defending against prompt injection, protecting user data, building guardrails, and making your AI cite its sources to build trustworthy applications.
In our last post, we discussed how to evaluate and debug our AI systems. Now that we know they are working correctly, we must ensure they work safely. Security for AI applications is a new and critical discipline. A model's power and flexibility can also be its greatest vulnerability.
This post covers my practical, multi layered approach to building secure and trustworthy AI features.
1. Defending the Gates: Mitigating Prompt Injection
Prompt injection is the "SQL injection" of the AI world. It's a malicious technique where a user crafts an input to hijack the prompt, making the model ignore its original instructions. There is no single magic bullet, so I use a "defence in depth" approach:
Input Filtering: Sanitise user inputs for suspicious patterns.
Clear Delimiters: Clearly separate my instructions from user provided data in the prompt.
The Principle of Least Privilege: Ensure the LLM only has access to the tools and data it absolutely needs for the current task.
Continuous Monitoring: Log and monitor prompts to detect unusual activity.
2. Protecting User Data: The PII Challenge
As a developer with a background in FinTech, I am acutely aware of the importance of protecting Personally Identifiable Information (PII). When using third party LLM APIs, you must assume that any data you send could be compromised.
For my personal projects, my first rule is to never really need to get PII or use it. If you do not handle it, you cannot leak it. When it is unavoidable, I tend to use regex to remove names and personal information before the data is ever sent to the LLM. If the data might be required for a future use down the pipeline, a more robust approach is to encrypt it.
On an enterprise scale, this PII challenge is one of the biggest drivers for companies to fine tune and self host their own models. When you send data to an external API, you are trusting that provider's security and privacy policies. For many companies, especially in sectors like finance or healthcare, this risk is unacceptable. By hosting a model within their own secure infrastructure, they ensure that sensitive user data never leaves their control. This makes fine tuning not just a performance or behaviour decision, but a critical security and compliance one.
3. Staying on Topic: Output Guardrails
Controlling the model's output is just as important as sanitising the input. The CMS and all tools I have created have guardrails, though some are stricter than others. The CMS bot, for instance, will only give information it knows about from its context and will refuse to answer anything else. For other bots, you still want guardrails around language to make sure the bot does not repeat certain phrases or get coerced into saying something it should not, these guardrails are already in place with the most popular llms.
4. Building Trust: Making the AI Cite Its Sources
A powerful way to mitigate hallucinations and build user trust is to force the model to show its work.
On my factual bot, it will reference the event or series the question was asked about. This allows the user to then ask more follow up questions or view the source data directly. This closes the loop and proves the AI is not just making things up. It is great to see that some of the newer models are starting to produce nice references to source material natively, which is a promising development.
Conclusion
AI security is not an optional extra; it is a core part of the design process. By adopting a proactive, defence in depth mindset, we can build applications that are not just intelligent, but are also safe, trustworthy, and respectful of user data.
In the final part of our series, we will take a brief, conceptual look at the maths that makes all of this possible.