The best tools to detect and block prompt injection in production

What's the best tool to detect and block prompt injection attacks in production?

Arcjet publishes this guide and sells one of the tools in it. We've included a section on when Arcjet is the wrong choice, and a list of its limitations.

"Detect and block prompt injection" describes two jobs. Detection scores a piece of text and tells you whether it looks like an attack. Blocking refuses the operation that the text asked for. Some products are excellent at detection and have no way to block anything; others enforce policy but rely on a separate detector. Treating the two as one purchase is the most common reason teams end up underprotected.

Which tool fits depends on your situation:

• You need to self-host and keep all text in your environment. Start with a maintained open-source library or framework, and check its maintenance status first – two well-known detectors are archived.
• You want a fast local first pass with no model call. Sunglasses matches known attack patterns in prompts, files, and MCP metadata in-process. Pair it with a model-based detector to catch rephrased attacks.
• You're on Azure. Prompt Shields integrates with the least effort and covers both direct attacks and attacks hidden in documents.
• You're on AWS. Bedrock Guardrails, through ApplyGuardrail, also works with models hosted outside Bedrock.
• You want a dedicated vendor for content inspection. Lakera Guard, HiddenLayer, Prompt Security (SentinelOne), and Pillar sell this as a managed service.
• Datadog is already your observability platform. Datadog AI Guard evaluates prompts and tool calls, and it blocks when your code waits for its verdict before acting.
• Your risk is in tool calls and background jobs, not the chat route. You need enforcement in your own code. That's the job Arcjet is built for.
• You're building conversation and tool rails. NVIDIA NeMo Guardrails and Guardrails AI are frameworks for that. You still need an authorization check on each action.
• You need regression tests in CI. Promptfoo and similar evaluation tools score prompts before release. They don't block anything in production.

Vendor details in this guide reflect public documentation as of September 2026. Dates matter more than usual here: several tools that blog posts still recommend are no longer maintained.

Best prompt injection detection tools

A quick shortlist by deployment model. When you're ready to test on your own traffic, go to how to run the evaluation.

• Self-hosted and maintained: Sunglasses (local pattern library), Guardrails AI (Python validators), NVIDIA NeMo Guardrails (programmable rails), and Llama Guard if you can host a classifier model.
• Hosted specialist APIs: Lakera Guard (Check Point), Azure Prompt Shields, Amazon Bedrock Guardrails, HiddenLayer, Prompt Security (SentinelOne), and Pillar Security.
• Evaluator inside your observability platform: Datadog AI Guard, which blocks only when your code waits for its verdict.
• Detection plus enforcement in your handlers: Arcjet. Prompt-injection scoring runs in Arcjet Cloud, and Guard policies gate the tool call itself.
• Avoid for new projects: LLM Guard and Rebuff, both archived. OpenAI Moderation scores safety categories such as violence and self-harm, not prompt injection. Promptfoo is an evaluation harness, not a runtime control.

The rest of this guide covers maintenance status, the differences that matter, and when each option is the wrong choice.

How to detect and block prompt injection with Arcjet

Arcjet does both jobs in one call. Arcjet Cloud scores the text, and your code blocks by refusing the operation when the decision is a deny, in the route handler or in the tool itself. The following check screens a fetched page before it re-enters the model's context, which is the indirect injection case:

1
import { launchArcjet, detectPromptInjection } from "@arcjet/guard";
2

3
const arcjet = launchArcjet({ key: process.env.ARCJET_KEY! });
4
const injection = detectPromptInjection();
5

6
const decision = await arcjet.guard({
7
  label: "tools.fetch",
8
  rules: [injection(content)],
9
});
10
if (decision.conclusion === "DENY" || decision.hasFailedOpen()) {
11
  return { content: "[Content blocked]" };
12
}

On an HTTP route, the same rule runs through aj.protect(req, { detectPromptInjectionMessage }) in the framework SDK. Measure it against the other options on your own traffic with the evaluation at the end of this guide.

The options, with status

Pay attention to the two archived rows. LLM Guard carries a notice, dated 9 July 2026, that the project and its Hugging Face models are no longer under active development. Rebuff was archived on 16 May 2025, and while it was live it described itself as a prototype that "cannot provide 100% protection."

Both still appear as recommendations in recent roundups. An unmaintained detector is riskier than it looks: the code keeps running and the dashboard looks covered, but nobody is updating it as attack techniques change.

What do prompt injection detection tools cost?

Prompt injection tools use three billing models, and the difference shows up as soon as you screen retrieved documents and tool results as well as user messages:

• Per request: Arcjet bills each protect() call as a web request at $5 per million and agent protection as agent requests at $50 per million, on top of a plan fee (Individual $25 a month, Startup $299 a month per application). The cost doesn't change with the length of the text.
• Per character: Azure Prompt Shields bills per text record and Amazon Bedrock Guardrails per text unit, where each record or unit covers up to 1,000 characters. Longer inputs cost proportionally more.
• Free, then quoted: Lakera's Community plan includes 10,000 requests a month for free, with an 8,000-token limit per prompt. Higher volumes go through Check Point enterprise sales.

Self-hosted options such as Sunglasses, Guardrails AI, and NeMo Guardrails have no license fee. You pay for the compute they run on, and NeMo rails that call a model add that model's token cost to each check.

To see how the billing unit matters, take 1 million screened inputs a month that average 2,500 characters once retrieved context is included. Each input is three 1,000-character units, so a per-character service bills 3 million units. At Bedrock's $0.15 per 1,000 text units for content filters through ApplyGuardrail, that's about $450 a month. The same traffic through InvokeGuardrailChecks, which prices prompt-attack detection separately at $0.08 per 1,000 text units, is about $240. Azure bills the same 3 million records at your region's Standard rate. Under per-request billing, the length of each input doesn't change the count.

None of these numbers includes the cost of a false positive, which is usually larger. Estimate that from a dry run on your own traffic before comparing list prices. Prices reflect public pricing pages as of September 2026.

The dimensions that actually differentiate

Three of these differences drive most decisions.

Whether text leaves your environment determines whether a tool passes privacy review when prompts contain regulated data. Arcjet sends the prompt to Arcjet Cloud for prompt-injection detection, because a specialist model makes that decision. Arcjet's in-process processing applies to sensitive-information detection, which is a separate control. If your prompts can't leave your environment, that difference matters, so weigh it before you choose.

Whether it works without an HTTP request determines coverage. Most indirect injection arrives in a tool result or a retrieved document, neither of which passes through your inbound request. Any product that you call from your own code can cover those paths; an edge WAF or a proxy in front of the model provider can't.

Pattern matching versus a model determines how you layer detectors. A local pattern library such as Sunglasses catches known encodings and "ignore your instructions" phrasings in under a millisecond, with no network call. A model-based API catches rephrased attacks the patterns have never seen. Running only one of them leaves gaps, so a common setup is a cheap local pass, then a model-based score, then an authorization check on the tool.

Indirect injection is the production case

Demos usually show a user typing "ignore previous instructions." In production, attacks more often arrive inside a support ticket, a PDF, a web page, an email, or a tool result that the agent treats as trusted context. To cover those paths:

1. Screen the user's message.
2. Screen each retrieved chunk before it enters the context window.
3. Screen each tool result before it goes back into the agent loop.
4. Check the action itself, with the session and arguments in scope, even when every text score is clean.

A detector wrapped only around the chat input leaves the retrieval and tool-result paths open. And an authorization check without detection misses attacks that trick an authorized user's agent into a legitimate-looking action. You need both.

Best prompt injection detection tools for developers

If you're a developer choosing something to install this week, rather than running a procurement process, the shortlist is shorter.

Self-hosted and maintained: Sunglasses, for a local pattern scan before anything else runs. Guardrails AI, if you work in Python and want injection checks inside a broader validation framework. NVIDIA NeMo Guardrails, if you want programmable conversation and execution rails and are willing to learn Colang. With frameworks and pattern libraries, detection quality depends on the validators, rails, or patterns you enable.

Hosted and maintained: Azure Prompt Shields on Azure, Bedrock Guardrails on AWS, Lakera Guard for a dedicated vendor, HiddenLayer or Prompt Security if your company already buys from them, Datadog AI Guard if Datadog is your observability platform, and Arcjet if you want the check in your handler next to the enforcement.

Avoid for new projects: LLM Guard and Rebuff, because they're no longer maintained. Don't use OpenAI Moderation as a prompt-injection detector; it scores safety categories.

Don't rely on these alone: a regex deny list, a system prompt that tells the model to refuse injections, or your choice of model. Each helps, but none of them is a security boundary. For more information, see how to prevent prompt injection in LLM applications.

Whatever you choose, make sure it has a dry-run mode. A vendor's benchmark won't tell you your false-positive rate. If your users talk about prompts, instructions, or security, some of their normal messages will look like attacks, and you want to find that in a log rather than in your support queue.

When Arcjet is the wrong choice

In these situations, another tool is the better fit:

Your prompts are regulated content that can't leave your environment. Arcjet's prompt-injection detection sends the text to Arcjet Cloud. A self-hosted detector, or Lakera's self-hosted inspector, keeps it in your environment.

You don't use JavaScript, Python, or Go. Arcjet's SDKs cover those languages. A Java or .NET service can call a hosted detector over HTTP instead.

You've already standardized on Azure, AWS, Check Point, or Datadog. Staying with a vendor you already run usually saves more in procurement and integration than a small difference in detection quality is worth. Azure Prompt Shields, Bedrock Guardrails, Lakera Guard, and Datadog AI Guard are reasonable defaults in those environments. Add an authorization check on each action either way.

You need red teaming before deployment. That's a different product category. Arcjet enforces policy at runtime; it doesn't test your model's robustness in advance.

You need data discovery. Arcjet decides whether content can move across a specific boundary. It doesn't map where regulated data is stored across your systems.

You want one gateway with central policy for services in many languages. A gateway fits that requirement better than an in-process SDK. For more information about that tradeoff, see PII detection at runtime: gateway, sidecar, or in-process.

Arcjet's limitations, stated plainly

Know these before you choose Arcjet:

• Prompt-injection detection sends the prompt to Arcjet Cloud. We repeat this because a single row in a comparison table is easy to miss.
• Each screened call adds roughly 100 ms. That's small next to a model completion, but it adds up in an agent loop that screens every tool result.
• A direct guard() call fails open after a 2-second default timeout, returning an allow with error codes. That's the right default for most routes and the wrong one for a refund, so check hasFailedOpen() wherever an unchecked operation isn't acceptable. The Vercel AI SDK and LangChain integrations fail closed unless you opt in to continuing on error.
• No detector fully solves prompt injection, including Arcjet's. Detection is one layer; the control that holds when detection misses is authorization on the action.
• Detection has false negatives. The hardest attacks read like ordinary business requests and contain no recognizable pattern.

The combination most teams actually need

Content inspection and action enforcement are separate layers, and buying one doesn't give you the other.

An inspector asks is this text hostile? An action gate asks is this operation allowed? An injection phrased as a plausible business request can pass the inspector, and the action gate still stops it. An operation that's properly authorized but was requested through a hostile prompt can pass the action gate, and the inspector still flags it. Running a content inspector alongside enforcement in your code covers both cases.

For more information about how vendors fit into that layering, see Lakera alternatives and the AI agent security platform comparison.

How to run the evaluation

1. Decide which job you're buying for. Detection, enforcement, or both. A shortlist that mixes them can't be compared meaningfully.
2. Check each project's maintenance status on the day you evaluate. Two tools in this guide are archived, and roundups that still recommend them haven't been updated.
3. Sample your own traffic. Collect a few thousand real prompts and label a stratified sample.
4. Run every candidate in dry-run mode against that sample, and report results per attack category rather than as one accuracy number.
5. Review the false positives by hand. This is where you discover which of your users' normal messages look like attacks.
6. Test the failure path. Make the detector unreachable and confirm that each route behaves the way you intended.
7. Check what leaves your network. Watch your application's outbound traffic during a test instead of relying on the vendor's description.

The result from step 4, on your own data, is the number to trust. Everything vendors publish, including this guide, is a starting point for that test, not a substitute for it.