The Best LLM Guardrails Tools in 2026, by Where They Actually Run

“Guardrails” gets used for three different jobs, and teams buy one tool expecting all three. It does not work. A gateway that blocks a toxic response at runtime does nothing to find the jailbreak in your prompt before you ship. A red-teaming framework that hammers your app in CI is not watching production at 2am. And an observability tool that flags a hallucination after it happened did not stop it reaching the user.

So I split this by where the guardrail actually runs:

• Runtime, in the request path. Blocks or filters a response inline, before it reaches the user.
• Pre-deployment red-teaming. Attacks your app to find the holes before real users do.
• Production monitoring. Scores live outputs to catch violations that slipped through.

One tool for each layer, and why you probably need more than one.

The short version

Tool	Guardrail layer	How it works	Free tier	License
Portkey	Runtime, in the request path	50+ guardrails at the gateway	OSS gateway free	Apache 2.0
DeepEval	Pre-deployment red-teaming	DeepTeam - 50+ vulnerabilities, OWASP	OSS free	Apache-2.0
Langfuse	Production monitoring	LLM-as-judge scorers, annotation	50k units/mo cloud	MIT

1. Portkey - guardrails at runtime, in the gateway

If you want a guardrail that actually blocks a bad response before it reaches the user, it has to sit in the request path - and Portkey already does. It is an LLM gateway that routes your calls to 1,600+ models, and it ships 50+ integrated guardrails that run inline as traffic passes through. Because Portkey is the proxy handling your calls anyway, adding a guardrail does not mean standing up a separate service - you configure it in the control plane and it enforces on the live path.

The budget story is good too. The open-source gateway is Apache 2.0 and self-hosts free via Docker, and guardrails are part of the free gateway along with routing, fallbacks and load balancing. So the runtime enforcement layer costs nothing to run yourself.

The gotcha is not the guardrails - it is the observability around them. The open-source gateway gives you routing, guardrails and a basic dashboard, but real logging, traces, analytics and retention live on the managed Production tier at $49/mo for 100k logs. So you can enforce guardrails for free self-hosted, but seeing which ones fired and how often is a paid feature unless you build your own logging. Know that split before you plan a deployment. The Portkey alternatives post covers the gateway field if runtime routing is your priority.

2. DeepEval - red-team the app before you ship

Runtime blocking is only as good as your knowledge of what to block. That is what red-teaming is for, and DeepEval is the strongest open pick here through its sibling framework, DeepTeam - 50+ vulnerabilities, 20+ attack vectors, mapped to the OWASP Top 10 for LLMs and NIST AI RMF. You point it at your app and it generates adversarial attacks - prompt injection, jailbreaks, data-leak probes - to find the holes before real users do.

It is genuinely free to run: DeepEval and DeepTeam are both Apache-2.0 and fully usable with no Confident AI account. And because DeepEval is pytest-shaped, you can run red-team suites in CI the same way you run functional tests, with deepeval test run. For a Python team that already writes tests, this is the natural home for pre-deployment safety checks.

The honest gotcha: this is a test, not a runtime blocker. DeepTeam tells you your app is vulnerable to a jailbreak; it does not stop that jailbreak in production - that is Portkey’s job. And DeepEval’s metrics are nearly all LLM-as-judge, so large red-team suites fire many inferences and get slow and expensive, with runs measured in minutes. Cost-model the judge calls before you scale the suite. Pair red-teaming with a runtime guardrail for real coverage.

3. Langfuse - catch what slips through in production

Even with runtime guardrails and pre-ship red-teaming, things get through - and you need to know when. That is the monitoring layer, and Langfuse is the pick. It does not block a response in the request path, but its LLM-as-judge scorers, custom scorers and human annotation queues let you score live outputs and flag violations for review, on top of full tracing so you can open the exact request that went wrong.

It is the cheapest way to run that layer at scale: self-hosting is free under MIT with only three features enterprise-gated, and even managed it is dramatically cheaper than closed alternatives - roughly $101/mo at 1M events versus LangSmith’s ~$2,514/mo per its pricing. If you want the monitoring layer of guardrails without a per-trace bill, self-host it.

Two catches. This is detection after the fact, not prevention - Langfuse tells you a hallucination reached a user, it does not stop the next one, so it complements Portkey rather than replacing it. And self-hosting means the v3 four-service stack (Postgres, ClickHouse, Redis, S3-compatible storage), where the migration bites. The wider observability field is in the best LLM observability tools ranking.

So which one?

• You need to block bad output at runtime - Portkey. 50+ guardrails inline at the gateway, free to self-host, but budget for the paid tier if you want to see what they caught.
• You need to find vulnerabilities before you ship - DeepEval with DeepTeam. Apache-2.0, OWASP-mapped red-teaming that runs in CI. Cost-model the judge calls.
• You need to catch violations in production - Langfuse. LLM-as-judge scoring plus tracing, cheapest at scale when self-hosted under MIT.

The real answer for a serious app is not one of these - it is layers. Red-team with DeepEval before you ship, enforce at runtime with Portkey, and monitor with Langfuse. Picking one and calling it “guardrails” leaves a gap in the other two. Every fact here was read from each vendor’s own materials on 23 July 2026, and this category ships breaking changes monthly - we re-verify every 30 days.