Guardrail Tools: The Landscape (October 2026 snapshot)¶

TL;DR

• Enforce authorization with deterministic policy engines first. Use OPA, Cedar, or OpenFGA for RBAC and tool access before adding probabilistic classifiers.
• Combine specialized guardrail layers. Pair an injection classifier or managed API, a PII engine, a policy engine, a gateway check on every tool call, and red-teaming tools.
• Know what each detector actually checks. Content-safety models like Llama Guard do not detect prompt injection or enterprise data leaks.
• Measure every guardrail on your own traffic. Track false-positive rate, false-negative rate, and p95 latency across your domain documents and languages. Roll out in shadow → flag → block stages.

• You will learn:
  • What each guardrail tool detects and where it runs
  • Open models vs managed APIs vs policy engines
  • Agent, MCP, and gateway security tools, and the commercial AI-security platforms
  • Capability matrix and latency profiles
  • How to evaluate guardrails, including public benchmarks
• Prerequisites: Guardrails architecture, Threat model & OWASP
• Related: Eval & observability tools, Guardrail selection decision tree, Input guardrails, Tool & action guardrails

Read this first: this is a dated snapshot¶

This document reflects the ecosystem as of October 2026. Security companies acquired several guardrail vendors during 2025–2026, and maintainers archived several popular open-source projects (see Ownership and status changes).

• Check repository status first: Review the project's README, changelog, latest release date, license, and archive status before you adopt it.
• Look past detector marketing names: "Prompt injection detection" can mean a 22M-parameter classifier or a slow reasoning LLM with different recall and latency.
• Benchmark every guardrail on your own data: Never deploy a guardrail in production before you measure its accuracy and latency (Evaluate guardrails on your own data).

The architecture in 04-guardrails is durable, while product names change rapidly. Wrap every guardrail behind your own interface so you can swap vendors easily.

The landscape at a glance¶

flowchart LR
    U["User prompt"] --> IN["Input checks: injection, jailbreak, PII, topic"]
    IN --> AG["Agent / LLM"]
    D["Retrieved docs and tool outputs"] --> CTX["Context checks: indirect injection, ACL filtering"]
    CTX --> AG
    AG --> ACT["Tool-call checks: authorization policy, args validation, approval"]
    ACT --> T["Tools: SQL, create_ticket"]
    AG --> OUT["Output checks: toxicity, PII leakage, groundedness, format"]
    OUT --> R["Response to user"]

    subgraph S1["Frameworks"]
      F1["NeMo Guardrails / Guardrails AI / LlamaFirewall"]
    end
    subgraph S2["Classifiers and APIs"]
      F2["Llama Guard / Prompt Guard / Granite Guardian / ShieldGemma / Azure / Bedrock / Model Armor / OpenAI / Lakera"]
    end
    subgraph S3["Deterministic"]
      F3["Presidio / OPA / Cedar / OpenFGA"]
    end

Frameworks orchestrate checks across the request path. Classifiers and managed APIs detect risks probabilistically. Policy engines and PII recognizers authorize or redact deterministically or semi-deterministically. Red-teaming tools attack the full pipeline offline and in CI.

Ownership and status changes to know about¶

A. Guardrail frameworks (orchestrators)¶

Each card covers six fields: Link · Type/License · Strengths · Detects/covers · Best for · Watch-outs. "Detects/covers" lists only capabilities documented by the project.

NVIDIA NeMo Guardrails (Colang)¶

Guardrails AI (validators hub)¶

Meta LlamaFirewall (Purple Llama)¶

LLM Guard (Protect AI): archived¶

B. Open safety classifier models¶

You host these open-weight models on your own infrastructure. They give you full data residency and predictable compute cost, while your team manages model serving, scaling, and threshold calibration.

Meta Llama Guard (1 → 4)¶

Meta Llama Prompt Guard (1 → 2)¶

IBM Granite Guardian¶

Google ShieldGemma¶

OpenAI gpt-oss-safeguard¶

Other open guard models¶

These open models fill gaps the cards above leave. Check each license before production use.

C. PII detection and anonymization¶

Microsoft Presidio (community-owned)¶

D. Managed safety APIs¶

Azure AI Content Safety (Prompt Shields, groundedness detection)¶

Amazon Bedrock Guardrails (contextual grounding, automated reasoning)¶

Google Model Armor¶

OpenAI moderation API¶

Lakera Guard (now Check Point AI Guardrails)¶

E. Prompt-injection prototypes¶

Rebuff: archived¶

F. Policy engines (RBAC and tool authorization)¶

LLM classifiers only estimate risk probabilistically. Authorization must be deterministic. In our running example, a deterministic policy engine must decide whether a user can read a document, query a database table, or create a ticket in a queue. The agent cannot talk its way around a policy engine. See Access control & RBAC.

Follow these proven authorization patterns:

• Filter retrieval ACLs before prompting: Filter chunks using the end user's identity before they enter the prompt, never the service account's identity.
• Authorize every tool call with concrete arguments: Check the end user's identity, the tool name, and the exact argument values on every call.
• Log every policy decision in the trace: Record the input, allow/deny decision, and policy version on the same OpenTelemetry trace as the LLM call.
• Test policies like application code: Write unit tests for allow/deny rules and run regression suites whenever roles or schemas change.

G. Agent, MCP, and gateway security¶

Agentic RAG apps call tools through MCP servers and AI gateways. These are good choke points for guardrails, because every tool call passes through them. Keep the tool-call gate and tool tiers from Tool & action guardrails (§2 and §6). Use the tools below to enforce or audit them.

Follow these rules for agent traffic:

• Scan tool descriptions before you connect a server: Tool descriptions are untrusted input. Re-scan when a server updates.
• Enforce the tool tier at the gateway: Apply the T0–T3 tiers from Tool & action guardrails §6. For example, create_ticket is T1: show an inline preview and require one-click user confirmation before submit.
• Fail closed on tool-enabled turns: If a gateway guardrail times out on a tool call, block the call or route the turn to a no-tools mode.

H. Commercial AI-security platforms¶

Security vendors bought most independent AI-guardrail startups in 2024–2026. The products below combine runtime guardrails with model scanning, red teaming, or AI usage discovery. Verify current packaging with each vendor, and benchmark them on your own data like any other detector.

Red-teaming tools¶

Red-teaming tools attack your application offline and in CI to test how well your guardrails hold up. They form the evaluation side of guardrails. See Threat model & OWASP and Generation quality & safety evals.

garak (NVIDIA)¶

PyRIT (Microsoft)¶

promptfoo red teaming¶

DeepTeam (Confident AI)¶

Giskard scan¶

Comparison matrix¶

Legend:

• ✅ first-class / native
• 🟡 partial, via integration/plugin, preview, or with custom config
• ❌ not a primary capability
• ❔ not verified (ask the vendor)

"Self-host" means the detector runs inside your own environment.

This matrix reflects our assessment of public documentation in October 2026. Verify capabilities before you decide.

What the matrix does not capture¶

• Detection accuracy: Two tools with ✅ in the same column can have very different recall and false-positive rates on your domain traffic.
• Language coverage: Most classifiers perform best in English, so benchmark every target language your users speak.
• Context length limits: Small classifiers truncate inputs (Prompt Guard 2 caps at 512 tokens), so split long retrieved documents into chunks and score each chunk.
• Indirect injection scanning: Only a few tools explicitly distinguish retrieved documents from user prompts (Azure document attacks, Lakera indirect defense, LlamaFirewall AlignmentCheck). With most tools, you must explicitly wire chunk and tool-output scanning yourself. Small classifiers such as Prompt Guard 2 target explicit attack patterns, so expect lower recall on subtle injections in retrieved text.
• Agent-level privilege risks: Stop excessive agency and confused-deputy bugs with deterministic authorization, tool tiers, and user confirmation rather than text classifiers (Tool & action guardrails).

Same risk, different tool: a mapping for the running example¶

For the matching OWASP IDs (for example LLM01:2026 Prompt Injection and LLM03:2026 Excessive Agency), see the mapping table in Threat model & OWASP.

How to choose¶

Step 1: Put deterministic controls first¶

Deterministic controls like authorization policies, least-privilege roles, read-only database connections, retrieval ACLs, and human approval gates do not suffer from classifier false negatives. Implement a policy engine or IAM check before you add probabilistic detectors. See Tool & action guardrails.

Step 2: Decide where detection must run¶

flowchart TD
    A["Data may leave your network?"] -->|"No"| B["Self-hosted: Prompt Guard 2, Llama Guard, Granite Guardian, ShieldGemma, Presidio, NeMo / Guardrails AI"]
    A -->|"Yes"| C["Already on one cloud?"]
    C -->|"Azure"| D["Azure AI Content Safety"]
    C -->|"AWS"| E["Bedrock Guardrails via ApplyGuardrail"]
    C -->|"GCP"| F["Model Armor"]
    C -->|"Multi-cloud or none"| G["Lakera / Check Point, OpenAI moderation, or self-hosted models"]
    B --> H["Need dialog / topic flows?"]
    H -->|"Yes"| I["NeMo Guardrails"]
    H -->|"No, mainly output validation"| J["Guardrails AI"]

Step 3: Fill gaps by risk¶

Step 4: Rules of thumb¶

• Run fast, cheap checks first: Execute regex, schema, and policy checks before small classifiers, and run LLM rails last.
• Execute independent checks in parallel: Run input classifiers concurrently with vector retrieval to hide guardrail latency.
• Define fail-closed vs fail-open per stage: Fail closed for tool-enabled turns, Tier 3 intents (HR, finance, security procedures), and access-control checks. Fail open and flag only for read-only, low-risk Q&A. If a classifier times out on a tool-enabled turn, fail closed or route the turn to a no-tools mode. See Guardrails architecture §5.
• Wrap every detector behind one interface: Use a single check(stage, text, context) -> decision contract so you can swap vendors by changing configuration.
• Never rely on an LLM guardrail for authorization: Enforce permissions in OPA, Cedar, OpenFGA, or your database.

Latency and cost¶

Treat these numbers as order-of-magnitude planning estimates. Benchmark p50, p95, and p99 latency on your own payload sizes, and remember that scanning 10 retrieved chunks requires 10 classifier inputs (batched or sequential).

Fit the checks into the canonical per-stage budgets in Guardrails architecture §5. These are starting rules of thumb; calibrate them on your app:

Evaluate guardrails on your own data¶

Every probabilistic guardrail is a classifier. Evaluate it like a classifier before launch and monitor it continuously in production. See Online evals and Monitoring, alerting & drift.

• Build a labeled benchmark dataset per guardrail with hard benign examples (security docs, code, quoted emails) and real attack samples.
• Measure both error rates: Compute false-positive rate (benign traffic blocked) and false-negative rate (attacks missed) per category and language.
• Select thresholds from an ROC or PR curve: Never ship a vendor's default threshold without calibrating it to your risk appetite.
• Benchmark p95 and p99 latency using realistic production payload sizes, including full retrieved document batches.
• Test the full chunking pipeline: Verify whether attacks split across document chunks bypass a 512-token classifier window.
• Run red-teaming suites before and after changes and save the reports as regression baselines.
• Monitor production block and appeal rates: Sample both blocked and passed requests every week for human review.
• Re-evaluate after model or API updates: Re-run your benchmark whenever a vendor updates a hosted detector.
• Roll out in three stages: Start in shadow (log only, no user effect), move to flag (annotate the trace and notify reviewers, no block), then move to block (enforce). Promote a stage only when the measured error rates meet your targets.
• Sample online traffic by cost: Run deterministic checks and the injection classifier on 100% of traffic. Run LLM judges on 1–5% of traffic plus 100% of flagged or negative-feedback traces (Online evals).
• Validate every LLM grader: Calibrate LLM-based guardrails and red-team graders against human labels with the bar in LLM-as-a-judge (≥ 100 labelled items, ≥ 30–50 FAIL examples, TPR and TNR ≥ 0.85, Cohen's κ ≥ 0.60; ≥ 0.90 for high-risk slices).

Use a scorecard like this for each detector. The targets are starting rules of thumb; calibrate them on your data and risk tier:

Report each rate with a Wilson confidence interval, not only a point estimate. See Dataset strategy for sizing.

Public benchmarks as a baseline¶

Public benchmarks do not replace your own data. Use them to compare tools and to seed your attack sets.

A reference stack for the running example¶

Common mistakes¶

Key takeaways¶

• Layer deterministic and probabilistic controls: Combine policy engines (OPA, Cedar, OpenFGA), detectors (classifiers or managed APIs), PII redaction (Presidio), and red teaming.
• Match each detector to its exact threat: Content-safety models (Llama Guard, ShieldGemma, OpenAI moderation) do not catch prompt injection, and injection classifiers do not replace least-privilege architecture.
• Weigh residency against managed breadth: Self-host open models when data cannot leave your network. Use managed cloud APIs for document scanning, PII filters, and grounding checks, but read their limits first (for example, Bedrock contextual grounding does not support chatbot QA, and Automated Reasoning only detects).
• Keep authorization 100% deterministic: Enforce document, SQL, and tool permissions in OPA, Cedar, or OpenFGA using the end user's identity.
• Measure every guardrail on your own data: Track false-positive rate, false-negative rate, and p95 latency before launch and after every vendor update. Roll out in shadow → flag → block stages.
• Gate agent tools at one choke point: Scan MCP servers before you connect them, and enforce tool tiers and fail-closed rules at the gateway.
• Wrap every guardrail behind your own interface: The security market consolidates fast (LLM Guard and Rebuff archived, WhyLabs discontinued, Lakera → Check Point, Protect AI → Palo Alto Networks, CalypsoAI → F5, Prompt Security → SentinelOne, Presidio → community, promptfoo → OpenAI).

Further reading¶

• Guardrails architecture: where each guardrail check sits in the request lifecycle
• Input guardrails and Retrieval & context guardrails
• Output guardrails and Tool & action guardrails
• Access control & RBAC: deterministic authorization patterns for RAG and tools
• Guardrail selection decision tree
• Eval & observability tools: companion landscape for evaluation and tracing tools
• Simon Willison, The lethal trifecta for AI agents: why classifiers alone cannot solve prompt injection
• Beurer-Kellner et al., Design Patterns for Securing LLM Agents against Prompt Injections
• Hines et al., Spotlighting: defending against indirect prompt injection in retrieved text
• OWASP Top 10 for LLM Applications 2026 and OWASP Top 10 for Agentic Applications 2026; map tool presets with Threat model & OWASP
• Debenedetti et al., AgentDojo: a benchmark for prompt-injection attacks and defenses in tool-using agents
• Public benchmarks as a baseline: more guardrail and agent-security benchmarks
• References: full curated reading list