– By Allie Howie.
I see many AI Runtime Security vendors offering LLM guardrails, as well as some evaluation platforms. I believe this is a side effect of the lines being blurred between who owns the responsibility of making sure AI systems output relevant and safe information. It’s not just something your security team cares about; your product team cares too.
This concern is most evident at a startup where the security and product teams are usually the same people. At a startup with limited funds and limited team members, would you rely on guardrails from your evaluation platform or onboard a new AI Runtime Security vendor for better guardrails?
The way I see the market right now, the products with the best guardrails:
- Come from AI Runtime Security-specific products, not eval platforms.
- Come from companies with prestigious/robust security research teams that are keeping up with the rapidly evolving threat landscape.
- Offer solutions at the application layer, not the network layer, for enhanced contextual awareness.
However, not everyone can afford an AI Runtime Security product. Most of these new products are reserved and marketed towards enterprise budgets. No matter where you get your guardrails from (an eval platform or an AI Runtime Security product), it’s important to be an informed consumer. That means understanding which LLM guardrails are a commodity, which are not, and how close to your LLM you need these guardrails to sit.
So which LLM guardrails are a Commodity?
Over the last couple of years, stories of AI chatbots gone wrong have consumed news headlines. For example, an Air Canada chatbot gave a customer misleading information about bereavement fares and was later ordered to provide a refund to the customer. In February 2023, Google lost $100 billion in market value after its Bard AI chatbot shared inaccurate information. In August 2024, Slack AI leaked data from private channels.
These headlines helped illustrate the need for some sort of guardrails that could prevent LLMs from outputting wrong information, private data, or offensive content. Security startups got to work and started offering guardrails that most businesses would need. These were novel at first, but today you’ll see most AI Runtime Security products and some eval platforms offering guardrails for:
- PII – detect information that identifies individuals
- Toxicity – detect offensive or harmful language
- Secrets – detect secret keys or tokens
- Prompt Attacks – detect prompt injection and jailbreak attacks
While these are a commodity, they are a wonderful starting place for an organization without any guardrails in place today. Due to the fact that LLMs are non-deterministic and they are trained on the internet and datasets that may not be up to our standards and certainly not aligned to our every use case, issues like toxicity and prompt injection are features of AI, not bugs. As a result, we will not be able to update LLMs fast enough with mitigations for new prompt attacks that work. It is advisable to implement guardrails like these in front of the LLM, anticipating that it will remain vulnerable to prompt injections. It will never be bulletproof, because again, these vulnerabilities are features, not bugs, that can be fixed.
Which LLM guardrails are NOT a Commodity?
In cybersecurity marketing, fear often leads. We often suggest investing in this cybersecurity tool to avoid becoming a news headline. While adding LLM guardrails can help prevent headlines like these, they can also enable product performance.
AI products that output irrelevant information will not be revenue-generating. Customizable guardrails help tailor your AI application to accept on-topic inputs and monitor outputs to make sure they are relevant and aligned to your business use case. It’s cybersecurity features like these that remind us that cybersecurity is a secondary market. The primary focus is on the product, with cybersecurity taking a secondary role to ensure its security. With AI, this is no longer the case. We need security in the loop earlier to keep AI aligned to business goals.
For instance, you can customize and configure some guardrails to ensure your AI application recommends your company, not a competitor. If you’re building an AI chatbot for Tesla, you wouldn’t want to output a recommendation for Toyota. AI alignment poses a significant challenge as it is not a universal solution. It will be unique to each business. Customizable guardrails prevent commoditization and distinguish products that offer them.
How Close to Your LLM Should your Guardrails Sit?
Security vendors are providing various options for the deployment of these guardrails. Some sit at the network layer, others at the kernel layer, and others right next to the LLMs in the form of an API wrapper. Each of these has tradeoffs.
Network layer guardrails may be easy to deploy as they can be added to an existing network security tool. However, these don’t typically have insight into internal tool calls your AI agents make or steps within an LLM workflow. They’ll just see final inputs and outputs that come in and out of the network gateway. This makes it harder to debug the exact location and manner in which your AI application produced an undesirable output.
The eBPF solutions deploy guardrails at the kernel layer, enabling them to see everything. They will see every input, output, and tool call. However, with great power comes great responsibility. Everyone remembers the CrowdStrike blue screen of death debacle that delayed thousands of flights last summer thanks to a bad software update to one of their products deployed via eBPF. Thanks to that, there’s some amount of risk and consumer hesitation with this type of deployment.
Deploying guardrails near the LLM is a straightforward process. They wrap LLM calls in additional APIs and will get visibility into granular LLM actions that allow for a good debugging experience; however, they may introduce additional latency into the application. You might find that latency increases the more guardrails you add.
There’s no clear-cut answer here for which is best. If you have a small budget, you might want to add-on guardrails to an existing network security product. If you have high confidence in a vendor and feel comfortable deploying an eBPF solution, you’ll gain great visibility into your runtime security and guardrails. If you want an easy-to-deploy solution, APIs might be a good way to go, but make sure to ask your vendor about latency.
Conclusion
Overall, investing in some sort of LLM guardrails is a good idea since we’ll never fix things like prompt injection with a shift-left strategy. Lots of these are now commoditized, but you can evaluate vendors based on guardrail customizability and deployment options as differentiators. AI security is not just important to prevent your application from becoming a headline; it’s also a business enabler. Use guardrails to secure your application against prompt attacks, but also to improve product performance and align your AI to your unique use case.
Default LLM guardrails are commoditized, but alignment will never be.