The five categories of LLM security tools
“LLM security” is not one product; it is a stack. Sorting the market into layers makes it far easier to see what you have and what you are missing.
| Layer | What it does | Example approaches |
|---|---|---|
| Input/output filters | Screen prompts and responses for injection, PII, and unsafe content | Guardrail models, content classifiers |
| Firewalls and gateways | Sit in front of the model to filter and route traffic | LLM firewalls, AI gateways |
| Runtime enforcement | Decide whether each agent action is allowed as it happens | Policy engines on tool calls and MCP |
| Red teaming | Test the system adversarially before and after deployment | Automated jailbreak and extraction suites |
| Observability | Capture and query what models and agents actually did | LLM/agent tracing and audit |
No single tool spans all five well. A real program combines them, weighted to the risks you carry.
The landscape by category
This is a map, not a ranking. Each tool is strong in the layer it was built for.
Input and output filters
The largest and oldest category: models and classifiers that inspect prompts and completions. Meta’s open-source LlamaGuard is a common baseline; Lakera and Prompt Security offer commercial guardrails focused on prompt-injection and content risks; cloud providers ship native filters like Google Cloud Model Armor and Azure AI Content Safety. These are effective at what they do: catching bad text going in or coming out.
LLM firewalls and gateways
A firewall or gateway puts a checkpoint in front of the model, applying the filters above plus routing, rate limiting, and logging. It is the natural place to enforce policy on model traffic. Its blind spot is everything that happens after the model responds, which for an agent is most of the risk. (More on this in What Is an LLM Firewall.)
Runtime enforcement
The newest layer, and the one built for agents. Instead of filtering text at the edge, runtime enforcement evaluates each action an agent takes, a tool call, an MCP request, a command, against policy at the moment it runs. This is where Highflame sits: it governs the agent’s actions and identity at request time, not just the model’s words. It is complementary to the filters above, not a replacement for them.
Red teaming
Adversarial testing tools probe an LLM or agent for jailbreaks, extraction, and manipulation before attackers do, and re-test to prove fixes hold. Red teaming is a build-time and continuous-assurance layer that feeds the enforcement layers rather than replacing them.
Observability
Tracing and audit tools capture what models and agents did so you can investigate and prove behavior. For agents this has to reach beyond model calls to tool use and delegation, which is the subject of AI observability.
How to choose: the agentic dimension
Most buying guides compare detection quality on prompt injection and PII, which matters, and our guardrail-model research covers that evidence. But nearly every list still assumes a chatbot. The criterion those lists miss, and the one that decides whether a tool fits an agent deployment, is simple:
- Does it see the agent’s tool calls, or only the prompt and response?
- Does it govern MCP traffic and the servers an agent connects to?
- Does it reason over a session, catching escalation that spans turns, or judge each request in isolation?
- Can it tie an action to an agent identity and a human owner for audit?
A tool can be excellent at filtering text and still answer “no” to all four. For a chatbot that is fine. For an autonomous agent it is the gap where incidents happen.
Where Highflame fits
Highflame is in the runtime-enforcement layer: it gives every agent an identity, evaluates each tool call, MCP request, and command against one policy before it runs, and records an attributable audit trail. It is designed to sit alongside the filters, gateways, and red-teaming you already use, covering the agentic action layer most of the market does not. See how it works on the platform page or for coding agents.