Skip to main content
SecureAI Guard

LLM security alternatives, and how to compare them

The open-source and platform options for guarding an LLM application, described from their own documentation, plus the questions that separate them in a demo.

Published ·7 min read·SecureAI Guard
alternatives
comparison
LLM guardrails
evaluation

If you are evaluating SecureAI Guard you are evaluating alternatives, and you should. This page describes the main ones. Everything asserted here about another product is taken from that product's own public documentation and linked to it, so you can check it rather than take our word for it. Where a capability is not described in a product's documentation, this page says "not publicly documented" — which is a statement about the documentation, not about the product.

What this page deliberately does not contain: a side-by-side table with a column for SecureAI Guard. A comparison table is a set of falsifiable claims about our own product, and the reader's very next click is the API reference that would substantiate them. Ours is not published yet. Until it is, a tick-box table from us would be unverifiable at exactly the moment it mattered, so this page gives you the evaluation method instead. When the reference ships, the table follows.

Sourced as of 12 August 2026. Products change; re-check the links before relying on any line below.

The four categories of alternative

Almost every option a platform team considers falls into one of four groups, and they are not competitors with each other so much as different layers.

1. Open-source guardrail frameworks

You run them, you own the tuning, there is no per-request fee and no data leaves your network.

NVIDIA NeMo Guardrails — Apache 2.0. Described in its README as "an open-source toolkit for easily adding programmable guardrails to LLM-based conversational systems", distributed as a Python library (pip install nemoguardrails) with a server mode and Docker deployment also available. Its documentation defines five categories of rail: input rails, dialog rails, retrieval rails (applied to retrieved chunks in RAG), execution rails (applied to custom actions and tools) and output rails. The README documents jailbreak and injection detection, LLM self-checking for input/output moderation and fact-checking, and integrations with third-party safety tools. The retrieval-rail concept is the one to look at closely if indirect injection is your concern: it is the right place in the pipeline.

Guardrails AI — Apache 2.0. "A Python framework that helps build reliable AI applications", per its README, by running input and output guards that "detect, quantify and mitigate the presence of specific types of risks", and by generating structured data from LLMs. Individual checks are called validators and are distributed through Guardrails Hub; the README demonstrates RegexMatch, CompetitorCheck and ToxicLanguage. The set of validators available on the Hub is larger than the README enumerates — check the Hub itself for the risks you care about rather than inferring coverage from the README.

What these give you and what they ask of you. Both are strong technical foundations, both are free, and for a team with capacity to own detector tuning they are a legitimate answer to the whole question. What neither is, out of the box, is an evidence system: producing audit records structured per control, with retention and redaction policies an assessor will accept, is your build. Budget for that separately, and see build vs buy for what it costs.

2. Controls built into the platform you already pay for

Azure AI Content Safety Prompt Shields — Microsoft documents Prompt Shields as "a unified API in Azure AI Content Safety that detects and blocks adversarial user input attacks on large language models", split into two detectors. Prompt Shields for user prompts (previously called Jailbreak risk detection) covers attempts to change system rules, embedded conversation mockups, role-play and encoding attacks. Prompt Shields for documents covers instructions hidden in third-party content, with documented subtypes including manipulated content, information gathering, availability, fraud and malware.

Microsoft also publishes the limitations, which is worth reading in full: models are trained and tested on eight languages (Chinese, English, French, German, Spanish, Italian, Japanese, Portuguese) with other languages working "with varying quality"; there are text-length, region and rate limits; and the documentation states plainly that Prompt Shields "may not catch all attack vectors or may flag legitimate prompts" and that you should "always implement additional validation layers". If you are already on Azure, this is the cheapest credible starting point in this list.

OpenAI's moderation endpoint — free, and it classifies text and images across harm categories including harassment, hate, illicit, self-harm, sexual and violence. Be precise about what it is for: OpenAI's moderation documentation does not address prompt injection. It is a harm classifier, not an injection detector, and treating it as the latter is the single most common gap we see in a homegrown layer.

3. Your own code

For many applications this is the real incumbent, and it is a reasonable one. Length limits, rate limits, a model allow-list and regex redaction of checksummed identifiers are cheap, deterministic and never drift. The parts that do not stay cheap — indirect injection, the false-positive budget, and evidence an assessor accepts — are set out in build vs buy: writing your own LLM guardrails.

4. Dedicated LLM-security products

This is our own category, and it includes several commercial vendors besides us. We do not name them on this page yet, and the reason is the rule at the top: we will not describe another company's product from anything except its own documentation, checked and dated. When we have done that work properly for each, they will be listed here with links. Meanwhile the section below is written to be used against any vendor in this category, us included — and if we answer one of these questions less well than someone else does, that is a real result.

The eleven questions that actually separate them

Ask these in the demo, in this order. Most of them have a short factual answer, and the ones that do not are the informative ones.

Architecture

  1. Is it a proxy, an SDK, a sidecar or a hosted API? This determines your latency, your blast radius and your data-residency answer, and it is the question everything else depends on.
  2. Does it inspect the whole assembled context, or only the user's message? Ask them to show you where in the pipeline retrieved documents are inspected. If the answer is "the user's message", indirect prompt injection is not covered, whatever the marketing says.
  3. Does it inspect completions as well as prompts? Roughly half of what matters — unexpected tool calls, exfiltration URLs assembled from conversation content, system-prompt leakage — is only visible on the way back.

Operational

  1. Fail open or fail closed, and is that configurable per route? There is no universally right answer. There is a wrong answer, which is not knowing.
  2. What does it add at p50, p95 and p99, measured on what hardware, at what concurrency, with what payload size? A single "sub-100ms" number without those four qualifiers is not a measurement.
  3. Is there a report-only mode you can run in production? Without one you cannot establish a false-positive baseline before you enforce, and you will be tuning thresholds during an incident.
  4. What happens when a detector fires — block, redact, tokenise, downgrade the tools, or ask a human? A binary block/allow verdict is the thing that gets guardrails switched off.

Data and evidence

  1. Is prompt content stored, where, for how long, and is it used for training or detector improvement? Get this in the contract, not the demo.
  2. Can it run fully air-gapped with no outbound calls, and does detection quality change when it does? The second half of that question is the one that gets skipped.
  3. What does the audit record contain, and can it be exported per control? Ask to see one record. Structured evidence against a named framework — NIST AI 100-1 and its Generative AI Profile, or an ISO/IEC 42001:2023 Statement of Applicability — is a different artefact from an application log, and the difference is expensive to retrofit.

Honesty

  1. What does this product not do? Every serious answer to this question names something. A vendor who cannot name a limitation of their own detector has either not measured it or is not telling you. Ours are written on the features page, under each control, in the same type size as the claims.

How to decide, rather than how to be sold to

The only evaluation that predicts production behaviour is one run on your own traffic. Take one representative week, replay it through each candidate in report-only mode, and count four things: attacks caught, attacks missed, legitimate requests flagged, and added latency at p95. The false-positive column will decide this for you more often than the detection column, because that is the column that determines whether the control is still switched on in six months.

The full method — corpus construction, metric definitions, and the mistakes that make a guardrail benchmark meaningless — is written up in how to benchmark an LLM guardrail on your own traffic.