> ## Documentation Index > Fetch the complete documentation index at: https://openrouter.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Prompt Injection Detection > Regex-based prompt injection guardrail patterns OpenRouter's regex-based prompt injection detection scans incoming requests for common injection techniques using pattern matching. This feature is **free** and adds **minimal latency** to requests since the patterns are evaluated locally before the request is forwarded to the model provider.> [!NOTE] > > To enable prompt injection detection, navigate to your [workspace guardrails](https://openrouter.ai/workspaces), open or create a guardrail, and configure the **Security** section.## How It WorksWhen regex-based detection is enabled on a guardrail, every incoming message is scanned against a set of patterns derived from the [OWASP LLM Prompt Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html), among other resources. If a match is found, the configured action is taken:* **Flag** — The request passes through unmodified; the detection is recorded for observability (metrics + analytics events) but no enforcement is applied. Useful for measuring true-positive rates on your own traffic before switching to `redact` or `blocked`. * **Redact** — Matched spans are replaced with `[PROMPT_INJECTION]` and the sanitized request is forwarded to the model. * **Block** — The entire request is rejected with a `403` before it reaches the model.> [!NOTE] > > When multiple guardrails apply to the same request (for example, a workspace default plus an API key–scoped guardrail), the most restrictive action wins. Priority is `block` > `redact` > `flag`.## Detection PatternsThe following regex patterns are checked against all user-supplied message content. Patterns are case-insensitive unless noted otherwise.## Evasion DetectionIn addition to the regex patterns above, the detection system includes techniques to catch common evasion strategies.### Typoglycemia DetectionAttackers may scramble the middle letters of keywords while keeping the first and last letters intact (e.g., "ignroe" instead of "ignore"). The system checks for typoglycemia variants of these target words:### Misspelled Phrase DetectionAttackers may misspell a keyword inside an injection phrase to evade exact matching (e.g., "1gnore previous instructions", "ignore previous saefty rules", "revael your system prompt"). The system finds candidate phrase shapes word-by-word, allowing one edit (insertion, deletion, substitution, or adjacent transposition) or a middle-letter scramble per eligible keyword: \ \
Pattern NameCandidate Phrase Keywords
A `~` marks a slot that also accepts a misspelling; slots without it must match exactly.A candidate is detected only when **at least one keyword is misspelled and its corrected phrase matches one of the exact regex patterns above**. The check uses that candidate's words, including any filler words, not an unrelated exact match elsewhere in the message. This prevents a typo from expanding the exact blocking policy: "delte previous instructions" and "skip the securty rules for now" do not trigger this layer because their corrected forms are not exact detections. Standalone near-words (e.g., `systemd`, `prompt1`, or prose that fixes a typo like `"promt" should be "prompt"`) do not qualify either.Read verbs (`print`, `output`, `reveal`, `expose`) also require exact qualifier and target slots in the read-override candidate. A misspelled verb is not sufficient on its own: "prnit the previous instructions" stays clean in this layer, while "outupt original instructions" qualifies because "output original instructions" matches the exact policy. Typoglycemia and encoding detectors still run independently.### Encoding-Based EvasionThe system decodes Base64 and hex-encoded content (including space-separated hex pairs like `69 67 6e 6f 72 65`), then checks the decoded text for injection keywords:This catches attempts to hide malicious instructions behind encoding layers. Two encoding detectors run: .### Character-Spaced EvasionText with character spacing (e.g., `i g n o r e p r e v i o u s`) is normalized by collapsing spaces, then re-scanned against all patterns. This prevents simple spacing-based evasion.## Reporting False PositivesIf a detection incorrectly flags legitimate content, you can mark it as a false positive from the [Logs](https://openrouter.ai/logs) page. Generations with a guardrail event show a shield icon on the row; hover it to open the guardrail popover.When a single pattern was detected, click **Mark as false positive** directly in the popover:![Guardrail popover with a Mark as false positive button for a single detected pattern](https://mintcdn.com/openrouter-d02e98a0/asDbbA5Vp75E03XP/assets/guides/features/guardrails/false-positives/fp-popover-single-pattern.png?fit=max\&auto=format\&n=asDbbA5Vp75E03XP\&q=85\&s=2ba7445d9c69cc01118e1e891598bb17)When multiple patterns were detected, the popover instead links to the generation detail view, where you can select the specific patterns to report:![Guardrail popover linking to Review entity types in detail for a multi-pattern detection](https://mintcdn.com/openrouter-d02e98a0/asDbbA5Vp75E03XP/assets/guides/features/guardrails/false-positives/fp-popover-multi-pattern.png?fit=max\&auto=format\&n=asDbbA5Vp75E03XP\&q=85\&s=96c62ade14589743b4a056b293aa8c8f)In the detail view, check the patterns that were flagged incorrectly under **Mark as false positive**, then click **Submit**:![Generation detail view with per-pattern Mark as false positive checkboxes](https://mintcdn.com/openrouter-d02e98a0/asDbbA5Vp75E03XP/assets/guides/features/guardrails/false-positives/fp-detail-view-multi-pattern.png?fit=max\&auto=format\&n=asDbbA5Vp75E03XP\&q=85\&s=f2dec84fbf64692e87248014f370f1dd)The event is visually marked and your feedback is recorded for future detection improvements.> [!NOTE] > > Marking a detection as false positive does not retroactively unblock the request. If the action was **block**, the original request was already rejected.## Limitations- **Regex-based detection is not exhaustive.** Sophisticated or novel injection techniques may not be caught. - **Flag mode does not enforce.** A flagged request is forwarded to the model exactly as submitted — the detection is recorded for dashboards and analytics only. Use `flag` to measure match rates on real traffic; switch to `redact` or `block` once you're confident the false-positive rate is acceptable. - **False positives** are possible. Some legitimate prompts may contain phrases that match these patterns (e.g., a prompt about security testing). Test your guardrail configuration with representative traffic — ideally in `flag` mode first — before enforcing broadly. You can [report false positives](#reporting-false-positives) from the Logs page, or exempt specific known-safe phrases via the [Allowlist](/docs/guides/features/guardrails/prompt-injection/allowlist).## Further Reading- [Allowlist](/docs/guides/features/guardrails/prompt-injection/allowlist) — exempt specific known-safe phrases from detection - [OWASP LLM Prompt Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) - [Guardrails documentation](/docs/guides/features/guardrails) - [Guardrails API reference](/docs/api/api-reference/guardrails/list-guardrails)