This article was written without sponsor recommendation. This is a genuine, Cyber_AI team-driven list of tools that we’ve found and think that you’ll find useful.

Leave a comment

If you spend any time looking at AI security tooling on GitHub, you will quickly encounter the same names. Garak, Promptfoo, PyRIT, Llama Guard and a handful of other projects dominate most lists. They are good tools, but the ecosystem has moved on quickly, particularly around AI agents, MCP, RAG and application-layer attacks.

There are some less well-known projects worth adding to the security engineer’s toolbox. None of these should be treated as a magic security control. They are practical tools for testing specific parts of an AI stack, and that makes them interesting. Here are five worth investigating today.

1. Augustus

Check out Augustus

Augustus is a good example of a tool that deserves more attention than it currently gets. Developed by Praetorian, it is a Go-based LLM vulnerability scanner aimed directly at security professionals.

The basic idea is familiar: give it an LLM endpoint and throw adversarial tests at it. What makes Augustus interesting is the breadth of its attack library. The project currently advertises more than 210 adversarial attacks covering areas such as prompt injection, jailbreaks, encoding attacks and data extraction. It also supports 28 LLM providers and produces vulnerability reports rather than simply dumping model responses to the terminal.

The Go implementation is useful from an operational perspective, too. You get a single binary rather than another Python environment to maintain, and the project is designed around concurrent scanning, rate limiting and retries.

That makes Augustus particularly interesting for security teams that want to turn LLM testing into something closer to conventional vulnerability scanning. Instead of asking whether an AI application has been “red teamed”, you can start asking which probes it fails, whether those failures are reproducible and whether the results change after a security fix.

It is not a replacement for manual testing. Automated probes tend to find known classes of failure. They do not understand your application’s business logic particularly well. But that is not really the point. Augustus is useful for establishing a repeatable baseline.

2. Agentic Radar

Check out Agentic Radar

The security problem changes quite a bit when an LLM stops being a chatbot and starts calling tools. Agentic Radar approaches that problem from the static-analysis side. Rather than concentrating primarily on whether a model can be jailbroken, it examines the architecture of an agentic workflow and looks for potentially dangerous patterns.

The project supports frameworks including LangGraph, CrewAI, AutoGen, OpenAI Agents and n8n. It can identify agents, tools and MCP integrations, then produce a security report with vulnerability mappings. This is useful because agent security is partly an architecture problem. If an agent has unrestricted access to a shell, filesystem, browser, internal APIs and credentials, improving the model’s refusal behaviour is not going to solve the underlying problem.

Think about it like SAST for agent workflows. You are looking for excessive permissions, risky tool usage and potentially dangerous workflow structures before the application reaches production.

There is an important limitation: static analysis cannot tell you everything about what an agent will actually do. Runtime behaviour, model-specific behaviour and indirect prompt injection still require dynamic testing. Agentic Radar is therefore most useful as one layer in an agent security pipeline. For teams building lots of small agents, however, that first-pass architectural scan could become very useful.

3. AI-Scanner

Get AI-Scanner

AI-Scanner takes a slightly different approach. It is an open-source web application built on top of NVIDIA’s Garak, designed to make AI security assessments easier to run and manage.

The project currently includes 179 community probes across 35 vulnerability families and supports both API-based LLMs and browser-based chat interfaces. It also provides scheduled scanning, attack-success-rate tracking, reports and SIEM integration.

That last part is what caught my attention. A lot of AI security tooling is designed for an engineer sitting at a terminal and testing something during development. AI-Scanner starts to look more like an operational security product. You can repeatedly scan a target, track whether its security posture is improving and push results into existing security infrastructure.

That matters because AI applications change constantly. Models get swapped, system prompts get rewritten, RAG data changes and new tools get connected. A one-off penetration test can become stale surprisingly quickly. The Garak foundation also means you are not starting from zero in terms of attack coverage. The interesting part is the layer around it: scheduling, target management, reporting and operational visibility. If you already use Garak, this is worth looking at as a way of making that testing more accessible to the rest of the security team.

4. MCP Armor

Take a look at MCP Armor

MCP has rapidly become one of the more interesting new security boundaries in AI systems. An MCP server gives an agent access to external capabilities, which means the security question becomes much bigger than “can someone jailbreak the model?”

MCP Armor is designed specifically around that problem. It can perform static and dynamic scans of Model Context Protocol operations, looking for risks in the communication between agents and tools. The project is designed to run locally, and its documentation describes prompt-injection checks using a local security model rather than sending source code to an external service. This is exactly the kind of tooling that is likely to become more important as agent deployments mature.

Consider an agent connected to an MCP server that can query a database, access files or call an internal API. The MCP server itself becomes part of your attack surface. Tool descriptions can contain malicious or misleading instructions, permissions can be excessive and the data returned by a tool can contain indirect prompt injection. Traditional application security tools do not necessarily understand those relationships.

MCP Armor is therefore worth experimenting with even if your current MCP deployment is small. The technology is still developing, and security controls are easier to introduce before dozens of internal agents depend on an unexamined tool ecosystem.

5. TriShieldRAG

Check out TriShieldRAG

The final pick is more research-oriented, but it addresses a problem that security teams building RAG systems should understand: knowledge-base poisoning. TriShieldRAG is an implementation associated with research into the PoisonedRAG attack. Its repository describes a three-layer defence intended to reduce the effectiveness of knowledge-base poisoning attacks against RAG systems. The project was still being updated in July 2026.

This is interesting because RAG security is often reduced to prompt injection. That is too narrow. If an attacker can influence the documents entering a retrieval system, they may not need to attack the model directly. They can attack the information the model is expected to trust. A malicious document can then become part of the context supplied to the model during a later query.

That makes the RAG pipeline a security boundary in its own right. TriShieldRAG is useful partly because it gives security engineers something concrete to experiment with. You can reproduce the attack, inspect how the defensive layers work and consider which elements make sense in your own retrieval architecture.

I would not take the implementation and drop it directly into a production system. It is better viewed as a practical research project that helps make RAG poisoning less abstract.

The bigger picture

The interesting thing about these five projects is that they cover different parts of the AI attack surface. Augustus and AI-Scanner are primarily concerned with testing model behaviour, whereas Agentic Radar looks at the application architecture. MCP Armor focuses on the increasingly important agent-to-tool boundary, before, finally, TriShieldRAG looks further down the pipeline at the integrity of retrieved knowledge.

Share

AI security is increasingly becoming normal application security applied to systems with probabilistic components. You still need authentication, authorisation, logging, secrets management, network segmentation and supply-chain controls. You now also need to consider prompt injection, model behaviour, tool permissions, poisoned context and agent autonomy.

The practical lesson is not to install five more security tools and call the problem solved. It is to use small open-source projects to test individual assumptions about your AI architecture. If your organisation is deploying agents, start with the tool boundary. If you are building RAG, test the retrieval layer. If you operate an LLM API, establish an adversarial testing baseline. Then automate those checks where possible.

That is where these smaller GitHub projects become useful. They turn broad AI security concepts into things a security engineer can actually run, break and measure.

Message Austin Miller