Best open source AI and LLM security tools

Use NeMo Guardrails or Guardrails AI to constrain and validate LLM behaviour, LLM Guard for input and output scanning such as prompt injection and PII, Llama Guard as a safety classifier, and garak or promptfoo to red-team your app. None of them fully stops prompt injection on its own.
What are the main security risks in LLM apps?
The OWASP Top 10 for LLM Applications is the most widely cited list. Prompt injection sits at the top: instructions hidden in user input, documents or web pages that make the model ignore your rules.
Other common risks include leaking sensitive data in outputs, insecure handling of model output (for example running generated code or SQL), excessive agency where an agent has more tool permissions than it needs, and denial-of-wallet through runaway usage.
These risks grow with capability. A chatbot that only answers questions has a small blast radius; an agent that can send email, edit records or run code has a much larger one.
Which open source AI security tools are worth using?
| Tool | Type | Language | What it covers | Best for | Trade-off |
|---|---|---|---|---|---|
| NeMo Guardrails | Guardrail framework | Python | Dialogue rails, topic control, input and output checks | Controlling conversational flows | Its own config language to learn |
| Guardrails AI | Output validation | Python | Validators for structure, PII, toxicity and more | Enforcing schemas and content rules | Validators vary in quality; test each |
| LLM Guard | Input and output scanners | Python | Prompt injection, secrets, PII, toxicity scanners | A scanning layer in front of any model | Adds latency per scanner |
| Llama Guard | Safety classifier model | Model weights | Classifies prompts and responses against a hazard taxonomy | Content moderation you can self-host | Check the model licence; needs GPU for speed |
| garak | Vulnerability scanner | Python | Probes for jailbreaks, leakage and injection | Red-teaming models and endpoints | Findings need human triage |
| promptfoo | Eval and red-team | TypeScript | Automated attack generation against your app | Security tests in CI | Needs good app-specific configuration |
Can any tool stop prompt injection?
Not reliably. Detectors catch many known patterns but attackers rephrase, encode or hide instructions in documents. Treat scanners as one layer, not the defence.
The durable fix is architectural: limit what the model can do. If an injected instruction cannot trigger a harmful tool call or reach sensitive data, the attack has little payoff.
Design reviews should ask one question for every tool the model can call: what is the worst thing that happens if an attacker controls this call? If the answer is unacceptable, add a confirmation step or remove the tool.
- Give agents least-privilege tools and read-only access where possible.
- Require human confirmation for irreversible actions.
- Keep untrusted content clearly separated from system instructions.
- Never let model output run as code, SQL or shell without validation and sandboxing.
How do guardrails differ from scanners?
Guardrail frameworks such as NeMo Guardrails shape behaviour: which topics the assistant handles, how it responds when a request is out of scope, and which checks run at each turn.
Scanners such as LLM Guard inspect text going in and out and flag or block problems. Validators such as Guardrails AI check that output matches a schema or rules and can ask the model to retry. Most production apps use at least one of each kind.
Red-teaming tools such as garak and promptfoo sit outside the request path entirely. They attack your app on purpose, so you find weaknesses before users or attackers do.
How to secure an LLM app step by step
- Threat-model your app: list data it reads, tools it can call and who supplies input.
- Remove unnecessary tool permissions and secrets from the model’s reach.
- Add input scanning for injection, secrets and PII on untrusted sources.
- Validate every structured output against a schema before acting on it.
- Red-team with garak or promptfoo before launch and on each major change.
- Log prompts, tool calls and blocks, and review them regularly.
- Set rate limits and spend caps to contain abuse.
Where AI security tooling falls short
- False positives that block legitimate users, leading teams to switch scanners off.
- Scanners only on the user message while injected text arrives through retrieved documents or web pages.
- Relying on a system prompt that says “ignore malicious instructions”.
- Red-teaming once at launch, then never again as prompts and tools change.
- Logs that store sensitive prompts without access control or retention limits.
Building a layered defence
A realistic stack for a small team is: least-privilege tool design, LLM Guard or a similar scanner on untrusted inputs, schema validation on outputs, and a promptfoo or garak run in CI. Add a guardrail framework when conversation control becomes complex.
Security tools are software dependencies like any other, so check their activity and licence. RepoLoot’s catalog includes AI security projects with notes on difficulty and what they are good for, which helps shortlist before a proof of concept.
Document which layer handles which risk. When a new attack technique is published, that map tells you quickly whether you are exposed and which control to strengthen.
Which OWASP LLM risks do these tools address?
Mapping tools to risks shows where coverage is thin. Several risks have no off-the-shelf fix and depend on how you design the application.
| Risk | Tools that help | Design control that matters most |
|---|---|---|
| Prompt injection | LLM Guard, garak, promptfoo | Least-privilege tools and human approval |
| Sensitive data disclosure | LLM Guard, Guardrails AI validators | Keep secrets out of prompts and context |
| Improper output handling | Guardrails AI, schema validation | Never execute output without sandboxing |
| Excessive agency | NeMo Guardrails flows | Narrow tool scopes and allow lists |
| Unbounded consumption | Gateway rate limits and budgets | Per-user quotas and spend alerts |
How do you protect RAG and agent pipelines specifically?
In RAG, the attack often arrives through a document rather than the chat box. Scan content at ingestion time as well as at query time, and record the source of every chunk so you can remove poisoned material quickly.
Apply document-level permissions in retrieval. The model should only see chunks the current user is allowed to read, otherwise a clever question can surface another team’s data.
For agents, keep an audit log of every tool call with its arguments and the user it acted for. Review blocked and unusual calls each week; they are your early warning system.
Finally, treat model output shown to users as untrusted too. Rendered links, images or markdown can leak data to external servers if an injected instruction makes the model include them.
How do you choose between these tools?
Measure latency and false positive rate for each layer on real traffic samples before enabling blocking. Start in log-only mode, review what would have been blocked, then switch on enforcement.
- Need to test before launch: start with promptfoo or garak and fix what they find.
- Accepting untrusted text or documents: add LLM Guard or similar scanners on input.
- Producing structured data or actions: add Guardrails AI or plain schema validation on output.
- Running a conversational assistant with strict scope: consider NeMo Guardrails.
- Moderating user-generated prompts and responses: self-host a safety classifier such as Llama Guard.
What does good AI security monitoring look like?
Prevention will miss things, so detection matters. Log every prompt, retrieved source, tool call and scanner verdict with a user and session identifier, stored with the same care as other sensitive data.
Alert on patterns rather than single events: bursts of blocked prompts from one account, sudden spikes in token usage, or tool calls outside normal hours. Keep a simple runbook for disabling a tool or revoking a key quickly.
Revisit your threat model whenever you add a tool, a data source or a new user group. Each one changes what an attacker can reach.
Frequently asked questions
- What is the best open source tool against prompt injection?
- LLM Guard and similar scanners detect many known injection patterns, and garak or promptfoo help you test for them. No tool fully prevents prompt injection, so combine detection with least-privilege tools, human approval for risky actions and strict output validation.
- What is the difference between NeMo Guardrails and Guardrails AI?
- NeMo Guardrails, from NVIDIA, focuses on controlling conversation flow and topics using configurable rails. Guardrails AI focuses on validating model outputs against schemas and rules, with a library of validators. They solve different problems and can be used together.
- How do I red-team an LLM application?
- Define what harmful behaviour looks like for your app, then run automated probes with tools such as garak or promptfoo’s red-team mode against your real endpoint, including tools and retrieval. Review findings manually, fix root causes, and rerun tests on every significant change.
- Is Llama Guard free to use?
- Llama Guard weights are released by Meta under a community licence that permits many uses but includes conditions. Read the licence that ships with the specific version before using it commercially. You can self-host it like other open models.