Keyword vs. Pattern vs. Intent Scanners: Which One Catches What (and Why You Need All Three)

An employee types a prompt asking an AI assistant to help them "phrase a way to get the model to ignore its earlier instructions and just answer directly, no disclaimers, pretend the rules don't apply for this one." No banned keyword appears anywhere in that sentence. No credential-shaped string, no fixed pattern a regular expression could match. A detection rule built entirely from word lists and regex patterns would let this straight through; not because the system failed, but because it was never asked to evaluate meaning, only surface text.

This isn't a hypothetical gap. Security researchers studying jailbreak defenses have documented the exact failure mode directly: a static ban list built to catch a phrase like "ignore all previous instructions" won't catch the same instruction encoded in base64, or the same request broken up and delivered across several separate prompts. More formally, a 2026 study on jailbreak detection from internal model representations states plainly that rule-based filtering and keyword matching, while computationally cheap, are brittle and easily bypassed through paraphrasing, obfuscation, or multi-turn prompting; and that learning-based defenses, including auxiliary language models for intent detection, improve robustness but introduce their own complexity, latency, and attack surface.

This is the specific gap that led to a third category of detection existing alongside the two more familiar ones. LangProtect's guide to how Guardia detects PII, PHI, and credentials covers pattern-based and NER-based detection for sensitive data specifically. This guide covers the fuller picture: the three types of custom detection rules available in Guardia, the real research behind why relying on only surface-text methods leaves a predictable blind spot, and the tradeoffs that come with closing it.

What Actually Happens When a Prompt Gets Scanned?

Before an AI model ever receives a prompt, Guardia's scanner service runs a fixed detection sequence: a named-entity-recognition pass runs unconditionally on every request first, then whichever additional scanners are attached to the active policy run against that same content. LangProtect's guide to redact, warn, or block covers what happens once a scanner produces a result and this guide focuses one layer earlier, on the three distinct ways something gets identified as a problem in the first place.

Each of the three custom scanner types below is precise within its own domain, and each has a well-documented blind spot outside it; understanding both halves of that tradeoff is what separates a detection strategy that actually works from one that either misses obvious risks or interrupts legitimate work constantly.

What Is a Pattern Scanner, and What Does It Catch?

A pattern scanner uses regular expressions like configurable with flags controlling case sensitivity, boundaries, and similar matching behavior to catch content that follows a fixed, predictable structure. This is the right tool whenever the thing you're trying to detect has a defined shape: a specific prefix, a specific length, a specific character set.

Credential formats, internal ID number formats, structured identifiers, and similar fixed-format strings are the natural fit; a well-constructed pattern is fast, cheap to evaluate, and precise, but only for content that actually has a matchable structure. Ask a pattern scanner to catch something that varies in wording, phrasing, or intent, and it will either miss most real cases or need to be so broad it catches unrelated content too.

What Is a Keyword Scanner, and What Does It Catch?

A keyword scanner matches prompt or response content against a defined list of words or phrases, not a structural pattern or a specific vocabulary. This is the right tool when what you're trying to catch is a known, finite, enumerable set of terms rather than a structural format or a shifting intent.

Competitor product names an organization doesn't want employees discussing with an external AI tool, internal project codenames, specific banned terms tied to a company's own policy, or terminology unique to a regulated process are all natural fits for a keyword scanner; the list is definable in advance, and once it's defined, matching against it is fast and unambiguous.

The limitation runs in the opposite direction from a pattern scanner's, and it's the same limitation documented in the jailbreak-detection research cited above: a keyword list only catches the exact terms on the list, and adversarial or simply creative phrasing routes around it trivially. An employee who refers to a competitor by an abbreviation not on the list, or a bad actor who encodes a banned phrase, splits it across multiple messages, or rewords it entirely, produces content a keyword scanner is structurally incapable of recognizing; not because the list is incomplete, but because keyword matching evaluates surface text, not meaning, by design.

What Is an Intent Scanner, and What Does It Catch?

An intent scanner uses a language model; in Guardia's case, a self-hosted model running entirely within the platform's own cloud infrastructure, meaning prompt content is never sent to an external AI provider for the purpose of scanning; to evaluate semantic meaning rather than matching against a pattern or a word list. This is the category of defense the academic literature on jailbreak detection points to directly as the response to keyword matching's brittleness: research explicitly frames auxiliary language models for intent detection as a way to improve robustness over rule-based filtering, precisely because evaluating what a request means, rather than what words it contains, closes the paraphrasing and obfuscation gap that surface-text methods can't.

The jailbreak attempt from this guide's opening is the clearest example, but the same gap shows up in less adversarial contexts too like an employee describing a way to work around an internal policy without ever naming the policy, or a request that's technically phrased as something innocuous but is functionally asking the model to do something it shouldn't. None of that has a fixed pattern or a finite vocabulary to match against.

That capability comes with a real, documented cost on the other side of the tradeoff.

The Tradeoff Intent Scanning Doesn't Escape

Intent classification isn't a free upgrade over keyword and pattern matching, it trades one failure mode for a different one. Research evaluating classifier-based jailbreak defenses, including OpenAI's Moderation API and Llama Guard, found that while classifier filtering improves on relying solely on a model's built-in safety alignment, both classifiers evaluated remained vulnerable to adversarial attacks, and, just as importantly for a production enterprise deployment, their binary nature drove a significant increase in false refusals of entirely benign requests, degrading usability in exactly the way an over-aggressive keyword or pattern rule would.

This matters directly for how intent scanning should actually be deployed: running it on every request, with no calibration and no fallback, doesn't just add latency, it risks becoming the AI equivalent of the naive redaction problem covered in LangProtect's guide to sanitization, redaction, and smart redaction, where an overly blunt control interrupts legitimate work often enough that people route around it. An intent scanner tuned and scoped carefully avoids this; one treated as a universal, always-on gate for every interaction tends to reproduce the exact adoption problem it was meant to solve.

Why Do the Three Scanner Types Run in a Specific Order?

Pattern and keyword scanners run first, synchronously, against every request, because they're inexpensive and fast. The intent scanner runs selectively rather than on every prompt, either because it's been explicitly configured to always run for a specific policy, or because the cheaper scanners have already elevated a prompt's risk score enough to justify the additional check. This ordering exists specifically to control latency and infrastructure cost: a language-model inference call is meaningfully slower and more expensive than a regex match or a list lookup, a cost the research above confirms is a real, acknowledged tradeoff of learning-based detection generally, not an implementation shortcut specific to any one product.

This layered execution also has an operational consequence worth understanding: if connectivity to the enforcement service is ever interrupted, cheaper pattern and keyword scanners can continue operating from a locally cached policy, while intent evaluation( which depends on reaching the scanning infrastructure) becomes temporarily unavailable until connectivity is restored. A policy that leans entirely on intent-based detection for its most important protections has a different failure profile during an outage than one that also has pattern- and keyword-based coverage as a fallback layer, an argument LangProtect's guide to prompt injection makes from a different angle: defense against semantically evasive attacks works best layered, not as a single point of failure.

Why Do You Need All Three, Not Just One?

Each scanner type is precise within its own domain and close to useless outside it, which is why a real detection strategy needs coverage from all three rather than picking the one that seems most sophisticated.

The pattern that emerges is consistent with what the research above documents directly: pattern and keyword scanners are precise and cheap for content with a defined shape or vocabulary, and blind to anything that varies outside it. Intent scanners catch what the other two structurally can't see, at a real, published cost in latency, compute, and occasional false refusals on benign content. A mature detection strategy doesn't ask "which scanner type is best" — it asks which type fits each specific rule it's trying to build, and calibrates the more powerful, more expensive option carefully rather than defaulting to it everywhere.

How Do You Decide Which Scanner Type to Build for a New Rule?

Start with what the rule is actually trying to catch, not with a default preference for one scanner type. If the content has a fixed, describable structure like a specific format, length, or character pattern, then a pattern scanner is the right and most efficient choice. If what matters is whether specific, enumerable terms appear like names, codenames or defined banned phrases, then a keyword scanner fits, with the caveat that the list needs active maintenance as new terms need coverage. If the concern is about what a request is actually trying to accomplish, independent of the specific words used to express it, an intent scanner is the only one of the three built to evaluate that, deployed with attention to the false-refusal risk documented above, not treated as a strictly superior default.

Every custom scanner, regardless of type, can be tested inline against a sample prompt before it's attached to a live policy, test runs use the same pipeline and model version as production, but are sandboxed and don't affect trigger counts or write to the audit log. LangProtect's guide to AI audit logs and forensic visibility covers what a production detection event should capture once a rule does go live, this sandboxed testing step is what happens before that, and it's the difference between deploying a new keyword list or intent rule and finding out days later that it's either missing obvious cases or firing constantly on legitimate prompts, versus catching that mismatch before it ever reaches a real user.

What Commonly Goes Wrong When Teams Build Custom Detection Rules?

A handful of avoidable mistakes account for most of the detection gaps and false-positive complaints that show up after a custom scanner goes live.

Defaulting to keyword lists because they're the easiest to build. A keyword list is the fastest scanner type to stand up, which makes it tempting to reach for even when the actual risk (a paraphrased or obfuscated version of a banned request), is exactly the kind of thing keyword matching structurally can't catch, per the research cited throughout this guide.

Deploying intent scanning without testing against benign edge cases. Because classifier-based defenses carry a documented risk of false refusals, a new intent rule tested only against clearly malicious examples will look like it's working well right up until it starts blocking legitimate requests that happen to share surface-level similarity with a flagged pattern.

Letting a keyword list go stale. New terminology, new competitor products, or new internal codenames won't be caught until someone explicitly adds them; unlike pattern or intent-based rules, a keyword list has no mechanism for generalizing beyond exactly what's already on it.

Assuming a single scanner type covers a multi-faceted risk. A risk like "jailbreak attempts" isn't one thing, it includes known-phrase attempts a keyword list can catch cheaply, novel paraphrased attempts only an intent scanner has a chance at, and encoded or split attempts that may evade both without additional detection layered specifically for obfuscation. LangProtect's guide to why AI agents increase security risk covers why this layering matters even more once autonomous agents, not just human-typed prompts, are the thing being evaluated, and LangProtect's enterprise guide to MCP security documents a closely related failure mode, tool poisoning, where malicious instructions are hidden inside content an agent trusts by default rather than phrased as an obvious attack a keyword list could catch.

Scanner Type Selection Checklist

Frequently Asked Questions

Can a single custom scanner use more than one detection method at once?

No, each custom scanner is built as one of the three types: Pattern, Keyword, or Intent. A single detection goal that needs more than one approach (catching both a specific term and a paraphrased version of the same concept, for example) typically requires building more than one scanner and letting policy evaluation combine their results, rather than trying to combine methods within a single rule.

Why not just use the Intent scanner for everything, since it seems the most capable?

Because capability and cost aren't the same axis, and intent scanning isn't strictly superior, it's a different tradeoff. Intent evaluation requires a language-model inference call, which is slower and more resource-intensive than a regex match or a list lookup. Research on classifier-based jailbreak defenses has also found that binary intent classifiers carry a real risk of false refusals on benign requests, meaning an intent scanner applied everywhere without calibration doesn't just cost more but it can actively degrade the experience for legitimate use.

Is keyword and pattern-based filtering obsolete now that intent scanning exists?

No. They remain the fastest, cheapest, and most precise tools for exactly the content they're built for, fixed formats and enumerable vocabularies. The documented weakness is specific to what they can't do (evaluate meaning), not a general obsolescence; a production detection strategy still relies on them for the majority of high-volume, low-ambiguity detections, reserving intent evaluation for what they structurally can't catch.

Does a keyword list need to be updated over time?

Yes, and this is one of the main maintenance costs of relying on keyword-based detection like new terminology, new competitor products, or new internal codenames won't be caught until they're explicitly added to the list. This is different from an intent scanner, which can potentially recognize a new way of expressing an existing concept without needing an explicit update, though at higher per-request cost and with its own calibration requirements.

What happens if the Intent scanner becomes temporarily unavailable?

Pattern and keyword scanners continue operating from a locally cached policy, since they don't depend on reaching external scanning infrastructure the same way intent evaluation does. Intent-based detection becomes temporarily unavailable until connectivity is restored, which means a policy relying heavily on intent scanning for its most important protections has reduced coverage during that window which is a reason to maintain some pattern- or keyword-based coverage as a fallback for genuinely critical detection categories, not just as a first-pass filter.

Is intent-based detection sent to an external AI provider for evaluation?

No, a properly implemented intent scanner runs on a self-hosted model within the platform's own infrastructure specifically so that prompt content being evaluated for policy violations doesn't itself get sent to a third-party AI provider as part of the scanning process.

How do you test a new scanner before deploying it, especially to check for false positives?

Custom scanners can be tested inline against a sample prompt using the same pipeline and model version as production, but in a sandboxed mode that doesn't affect trigger counts or write to the audit log. Given the documented false-refusal risk with intent-based rules specifically, testing should deliberately include benign edge cases that superficially resemble the target content, not just clear-cut malicious examples, and that's the gap between finding a calibration problem during testing and finding it after a legitimate business request gets blocked in production.

Which scanner type is best for catching a brand-new kind of AI security threat before there's a known pattern for it?

Intent scanning is generally the better fit for genuinely novel threats, since pattern and keyword detection both depend on already knowing the specific structure or vocabulary to look for. A new attack technique that hasn't been seen before won't match an existing pattern or appear on an existing keyword list, but if its underlying intent resembles a category the model has been trained to recognize (attempting to bypass instructions, extract restricted information), an intent scanner has a better chance of flagging it than either of the other two methods, though the false-refusal tradeoff documented above still applies, and no detection method offers guaranteed coverage against something genuinely unprecedented.

Detection Strategy Is About Matching the Tool to the Target

The mistake underlying most detection gaps isn't a poorly written rule, it's a rule built with the wrong type of scanner for what it's actually trying to catch. A keyword list can't catch a paraphrase; academic research on jailbreak defenses confirms this is a structural limitation, not a tuning problem. An intent scanner, deployed everywhere without calibration, becomes an expensive way to both solve problems a five-line regex already solves for free and introduce a documented risk of blocking legitimate work.

A mature detection strategy uses all three deliberately: pattern and keyword scanners doing the cheap, precise, high-volume work they're built for, and intent evaluation reserved, and carefully calibrated, for the harder problem that surface-text methods have been repeatedly shown, in published research, not to solve.