How to add guardrails to an LLM app: a step-by-step guide

By the end of this guide you will have a working set of LLM guardrails around an AI application: checks on what goes in, checks on what comes out, a policy that decides whether to block or only log, and a repeatable red-team test that tells you if the checks hold. The tooling for this is a guardrail layer (usually an API your app calls) plus a testing tool that attacks your app on purpose.

If you want to add LLM guardrails without rebuilding your app, the practical route is to treat them as a screening step in the request and response path. This guide covers how to choose between the kinds of tool on offer and compares seven options from our Developer platforms category.

Key takeaways

• Screen every user input, tool call and model output against a written policy, start in log-only mode, then switch to blocking once the false positives are understood.
• The main decision is whether you need a runtime guardrail, a pre-release red-team tool, or both: they solve different problems.
• Free entry points exist, such as Lakera Guard's Community plan, the open-source Promptfoo, and Fireraven's free starting credits, but each has caps.
• Guardrails reduce risk and do not remove it. A person should review policies for anything legal, medical, financial or involving children.

What you need before you start

• A working LLM app or agent. Even a prototype will do, as long as you can reach the point where a prompt goes in and a response comes out.
• A short policy in plain words. List what the app must never do: leak personal data, follow instructions hidden in documents, call tools it should not, or produce offensive content.
• A test set. A handful of normal prompts and a handful of hostile ones (jailbreak attempts, requests for secrets, instructions buried in pasted text).
• Access to your code. Most guardrail layers are called from your backend or from an AI gateway.
• Time. A first working integration takes under a day for a small app. Tuning the policy takes longer.
• Difficulty. Moderate: you need to be comfortable calling an API and reading logs.

Which kind of AI tool fits this job

Pick by where in the life of the app the risk sits.

A runtime guardrail API for live traffic. Your app sends each input, tool call or output to a service that returns a verdict. Lakera Guard screens inputs, tool calls and model outputs for prompt attacks, data leakage and unsafe content, with per-project policies and an Enforce or log-only choice. Fireraven pairs a guardrail layer called FireGuard with automated red-teaming, and its actions can block, warn or allow with logging. DeepRails focuses on the quality of the answer: its Defend API scores outputs for correctness, completeness, safety and adherence, then repairs weak answers.

An observability platform with guardrails built in. Fiddler AI traces agent activity and places guardrails in the request and response path, screening for hallucinations, toxicity, PII and PHI, prompt injection and jailbreak attempts. Openlayer leans towards testing and monitoring, with tests that can run in CI and block a risky deployment, plus guardrails for prompt injection and data leakage aimed at larger organizations. Choose this kind when you also want traces, alerts and audit records.

A red-team tool that attacks your app before release. Promptfoo is open source and generates attacks for your app, including direct and indirect prompt injection, jailbreaks and PII leaks, then reports findings in CI/CD. It tests your defences rather than enforcing them at runtime.

A scanner for agent code. Agentic Radar reads the source code of an agent workflow, draws a graph of the agents and tools, and maps risks to the OWASP Top 10 for LLM Applications. It is static analysis, so it does not test a running system.

Most teams end up combining one runtime layer with one testing tool.

Step 1: Write down what the app must never do

You finish this step with a short policy that a tool can enforce and a test can check.

1. List the harms that matter for your app: prompt injection, data leakage, unsafe tool use, offensive output, wrong answers.
2. Mark each as block, warn or log only. Start with blocking only for the clear-cut cases.
3. List the tools the agent may call and the ones it must never call.
4. Note any regulation your sector cares about, and ask a qualified person to review it.

Check it worked by handing the policy to a colleague and asking them to write one test prompt per rule.

Step 2: Map where untrusted text enters

Guardrails only help where traffic actually passes through them, so find every entry point first.

1. Trace the path of a request: user message, retrieved documents, tool results, model output.
2. Mark every place where text from outside your control can reach the model, including web pages and uploaded files.
3. For agents, run a static scan such as Agentic Radar to list the tools and external services the workflow touches. Its supported frameworks are a growing list, so check yours is covered.
4. Decide which points need an input check and which need an output check.

Check it worked by producing a one-page diagram with each check point labelled.

Step 3: Choose and connect a guardrail layer

Pick the tool that matches your risk and deployment constraints, then wire it into the request path.

1. Compare the options in the table below. Note whether you need self-hosting: Lakera Guard, Fireraven and Fiddler AI all list self-hosted or on-premises options, some only on enterprise plans.
2. Create an account and a project for the app. Give each app its own policy where the tool supports projects.
3. Call the guardrail from your backend or gateway before the prompt reaches the model, and again on the model's response.
4. Send tool calls through the same check if your agent uses tools.

Check it worked by sending one harmless prompt and one obvious attack, and confirming the verdicts differ.

Step 4: Run in log-only mode and read the results

Switching on blocking before you have seen real traffic usually breaks legitimate use.

1. Set the policy to log or warn, not block.
2. Run your normal prompts and your hostile prompts through the app.
3. Open the dashboard or request logs and look for false positives (good requests flagged) and misses (attacks allowed).
4. Adjust the policy, thresholds or allowed domains and run the set again.

Check it worked by seeing every hostile prompt flagged and few normal prompts flagged.

Step 5: Turn on enforcement and add a safe fallback

Now the tool can stop things, so decide what the user sees when it does.

1. Switch the clear-cut rules from log to block.
2. Write a short, neutral message for blocked requests that does not reveal the rule.
3. For personal data, prefer redaction or masking where the tool supports it, rather than failing the whole request.
4. Keep log-only mode for the rules you are still unsure about.

Check it worked by confirming that a blocked request returns your fallback message and that the block appears in the logs.

Step 6: Red-team the app

A guardrail is only as good as the attacks it has been tried against, so test it deliberately.

1. Run an automated red-team tool such as Promptfoo against your app. Its command-line version defines tests in YAML and can run locally. Fireraven's RedRaven component also runs automated pentesting and can export recommended policies to FireGuard.
2. Include indirect injection: instructions hidden in a document or web page the app reads.
3. Fix the gaps, update the policy and rerun.
4. Keep failing cases as permanent regression tests. Openlayer can turn failed production sessions into regression tests.

Check it worked by rerunning the suite after a fix and seeing the earlier failure pass.

Step 7: Monitor in production and keep records

Attacks change, so the work continues after launch.

1. Watch violations and trends on the dashboard. Fireraven describes a dashboard with violations, trends and audit evidence, and Fiddler AI logs every enforcement decision for audit purposes.
2. Set alerts for spikes in blocked requests or quality drops.
3. Add output-quality checks if wrong answers are your main risk. DeepRails has a Monitor pipeline that scores live traffic.
4. Re-run your red-team suite on every change to prompts, models or tools.

Check it worked by reviewing a week of logs and confirming that each blocked request has a recorded reason.

Tools for this job compared

Tool	Good fit for	Pricing	Stated limits
Lakera Guard	Runtime screening API with projects and policies; web, API, self-hosted	Freemium	Community capped at 10k screening requests a month and an 8k-token prompt size; dashboard not available to self-hosted customers
Fireraven	Guardrails plus automated red-teaming for agents; web, self-hosted	Pricing unknown	Credit pricing beyond the 500 free starting credits is not published; default daily cap of 1,000,000 request units
Fiddler AI	Observability with in-path guardrails; web, API, self-hosted	Freemium, paid from $0, usage-based (checked 24 Oct 2026)	Developer plan billed per trace; Enterprise guardrails, VPC and on-premises need Enterprise
Promptfoo	Open-source evaluation and red-teaming in CI; CLI, web, API	Open source	Community caps red teaming at 10k probes a month; monitoring, SSO and API access are Enterprise
Agentic Radar	Static scanning of agent workflows	Open source	Static analysis only, so it does not test a running system; some frameworks marked coming soon
DeepRails	Detecting and fixing wrong or low-quality answers; web, API	Freemium, paid from $49/mo (checked 24 Oct 2026)	Free plan is Playground-only; API usage billed per 1K calls on top of the plan fee
Openlayer	Testing, tracing and governance with CI checks; API, CLI	Freemium	Basic: 1 member, 5 projects, 20,000 inference logs a month; on-premise and SAML SSO are Enterprise

Prices and plan limits change, so confirm the current terms on each vendor's site before you commit.

Common mistakes to avoid

• Only screening the user's message. Attacks also arrive through retrieved documents, tool results and web pages. Fix it by placing checks on every entry point you mapped in Step 2, and on tool calls.
• Blocking on day one. An untuned policy flags legitimate requests, and users notice before you do. Fix it by running in log-only mode first and enforcing only the rules you trust.
• Treating a guardrail as a guarantee. No filter catches everything, and vendors describe detection, not perfect prevention. Fix it by combining guardrails with least-privilege tool access and regular red-team runs.
• Ignoring plan limits. Free tiers have caps on requests, prompt size or probes, and long text may be scored in windows. Fix it by checking the limits against your traffic before you route production through a free plan.
• Skipping human review of the policy. Rules about health data, payments or children's content have legal weight. Fix it by having a qualified person approve the policy and the fallback messages.

How we put this together

This is an evidence-based guide built from each tool's listing in our directory, which is compiled from the vendor's own site and pricing page. It is not a review based on using the tools. We don't rank tools, and nobody paid to be included. Some outbound links may be affiliate links; see our disclosure.

Frequently asked questions

Is there a free way to add guardrails to an LLM app?

Yes, within limits. Lakera Guard's Community plan costs $0 a month, Promptfoo's Community edition is free, and a new Fireraven organization starts with free credits. Each has caps, such as 10k requests a month on Lakera Guard, so check them against your traffic.

What is the difference between guardrails and red-teaming?

Guardrails sit in the live request path and block, warn or log. Red-teaming attacks your app before and after release to find the gaps. You usually want both: red-team results tell you what the guardrail policy is missing.

Can guardrails stop prompt injection completely?

No. Several tools in this guide detect and block prompt injection, but they are one layer. Limit what tools an agent may call, treat outside text as untrusted, and keep testing as attacks change.

Do guardrails slow my app down?

They add a check in the request path. Fiddler AI states that its guardrails respond in under 80 milliseconds, but other vendors do not publish a figure here, so measure the added delay in your own app.

Can I keep guardrail checks inside my own infrastructure?

Some tools list self-hosted deployment, including Lakera Guard (Enterprise), Fireraven, Fiddler AI (VPC and on-premises on Enterprise) and Promptfoo. Plan restrictions apply, so read each vendor's terms before you commit.

Compare more options in our Developer platforms category.