Guardrails

Guardrails checks text for unsafe or sensitive content.

The following guardrails can be validated against:

• PII: Detects personal identifiable information such as names, addresses, phone numbers, email addresses, social security numbers, credit card numbers, or other personal data.
• Tokens/Passwords: Detects API tokens, passwords, API keys, access keys, secret keys, authentication credentials, or other sensitive credentials.
• Jailbreak: Detects attempts to bypass AI safety guidelines, manipulate the model's behavior, or make it ignore its instructions.
• Offensive Content: Detects offensive, hateful, discriminatory, violent, or inappropriate content.
• Malicious Code: Detects potentially malicious code, scripts, exploits, or harmful commands.
• Prompt Injection: Detects attempts to inject malicious prompts, override system instructions, or manipulate the AI's behavior through embedded instructions.

When validation passes, the input continues through the Pass output. When validation fails, the input is blocked and sent through the Fail output with a justification explaining why it failed.

The default selection remains PII, Tokens/Passwords, and Jailbreak. Model checks can produce false positives or miss some violations. Use this component in addition to other data-sanitization best practices, rather than as a sole safeguard.

Set up a check

1. Connect a text source to Input Text.
2. Choose a Checking Method and select the Guardrails to run.
3. Select or connect a Language Model when using either AI method.
4. Connect Pass and Fail to the corresponding downstream paths. Use Result Data to inspect the verdict.

Checking method	Behavior
AI checks (default)	Uses the original Guardrails evaluator: category-specific model checks, existing jailbreak/injection heuristics, and stopping at the first violation.
Rules + AI	Checks known patterns, then evaluates enabled semantic categories together in one model call unless rules already require blocking.
Rules only	Checks known patterns without calling a model, even if one is connected. Semantic categories without an AI verdict are reported as unverified.

Either AI method requires a model. To run without one, explicitly choose Rules only. Combining categories does not guarantee identical detection decisions to individual checks.

Advanced settings appear only for the chosen method and categories.

Create custom guardrails

Enable Custom Guardrail reveals a field for your own AI checking criteria. It requires an AI method.

In Custom Guardrail Description, enter a natural language description of disallowed data that you want to detect. Custom guardrails can run at the same time as the built-in guardrails.

For example, to block inputs that mention competitor names or products, enter:

competitor company names, competitor product names, or references to competing services

Existing flows

Saved flows are not automatically migrated. The original component remains available as Guardrails (Legacy). The current component is displayed as Guardrails. Its default AI checks method preserves the original prompts, heuristics, Pass/Fail routing, and Result Data payload.

Adopt Rules + AI explicitly to use the combined evaluation. In that method, a model can raise a rule's risk score but cannot override a rule block. All outputs share one cached verdict, so connecting Pass, Fail, and Result Data does not add model calls.

Advanced controls

Strictness increases from permissive to strict as you move right. In AI checks, it controls the existing jailbreak/injection heuristic. In rule methods, it controls the blocking threshold. The displayed value is 1 - threshold; stored thresholds retain their original meaning. For example, a stored block threshold of 0.75 displays as strictness 0.25.

Rule methods also expose Review Threshold and Action for Flagged Text. Findings at or above the blocking threshold go to Fail. Findings between the review and blocking thresholds use the selected action:

• block (default): route flagged text to Fail without modifying it.
• sanitize: opt in to removing supported directive lines or redacting detected sensitive values. Cleaned text goes to Pass only after deterministic rechecking succeeds. Findings without safely removable spans, unsupported categories, or model findings that cannot be localized are blocked.
• pass_through: explicitly allow flagged text unchanged.

Redaction Style appears only when sanitize is selected. Block When a Check Fails to Run is enabled by default for rule methods, including incomplete or malformed model verdicts in Rules + AI. Disabling it permits fallback to rule results and records errors and unverified categories.

Message Type selects user input or assistant output. Output supports additional solicitation and system-prompt-leak checks. Selecting Scope reveals Topic Restrictions and the relevant allowed/blocked topic lists. Topic matching uses whole words and phrases, including regular English plurals; list synonyms and irregular forms explicitly. For example, car matches cars, but not career. Organization-specific settings appear only with Enterprise Business selected.

For Tokens/Passwords, a random-looking HTTP(S) URL path alone does not count as a secret. Known credential formats and labeled secrets are still checked inside paths; query strings, fragments, and URL credentials retain entropy checks.

Model Evaluation in Rules + AI supports env (deployment setting, defaulting to ambiguous), ambiguous (skip AI when rules already block), or always (evaluate even rule-blocked messages). A deployment setting of off is rejected in Rules + AI; choose Rules only explicitly instead.

Deployment settings and limits

Environment settings override corresponding fields in rule methods:

• LANGFLOW_GUARDRAILS_BLOCK_THRESHOLD and LANGFLOW_GUARDRAILS_SANITIZE_THRESHOLD: finite values from 0 through 1, using the stored threshold scale.
• LANGFLOW_GUARDRAILS_LLM_MODE: ambiguous or always when Model Evaluation is env in Rules + AI.
• LANGFLOW_GUARDRAILS_SCOPE_MODE: off, allowlist, denylist, or both.
• LANGFLOW_GUARDRAILS_ALLOWED_TOPICS, LANGFLOW_GUARDRAILS_BLOCKED_TOPICS, LANGFLOW_GUARDRAILS_ENTERPRISE_ORGS, LANGFLOW_GUARDRAILS_ENTERPRISE_DOMAINS, LANGFLOW_GUARDRAILS_INTERNAL_HOST_LABELS, and LANGFLOW_GUARDRAILS_CLASSIFICATION_MARKERS: comma-separated values.
• LANGFLOW_GUARDRAILS_FAIL_CLOSED: true or false.

Rule evaluation accepts up to 64,000 input characters. Combined model evaluation accepts up to 12,000; longer input produces an evaluation error instead of silently checking only a prefix. These limits apply to the new rule methods; AI checks retains the legacy behavior.

Result Data can contain original text, including sensitive content. Route it only to appropriate destinations.

Guardrails (Legacy)

Legacy components are no longer supported and can be removed in a future release. You can continue to use them in existing flows, but it is recommended that you replace them with supported components as soon as possible. Suggested replacements are included in the Legacy banner on components in your flows. They are also given in release notes and Langflow documentation whenever possible.

If you aren't sure how to replace a legacy component, Search for components by provider, service, or component name. The component may have been deprecated in favor of a completely new component, a similar component, or a new version of the same component in a different category.

If there is no obvious replacement, consider whether another component can be adapted to your use case. For example, many Core components provide generic functionality that can support multiple providers and use cases, such as the API Request component.

If neither of these options are viable, you could use the legacy component's code to create your own custom component, or start a discussion about the legacy component.

To discourage use of legacy components in new flows, these components are hidden by default. In the visual editor, you can click Component settings to toggle the Legacy filter.

Guardrails (Legacy) is the original evaluator from before Langflow 1.12.2. It issues prompts to a language model for each enabled category, and it always requires a model. Jailbreak and Prompt Injection run heuristic detection first, and then fall back to LLM validation if needed.

Saved flows that used Guardrails before 1.12.2 keep the legacy component. To get legacy behavior on the current Guardrails component, use AI checks.

Use Guardrails (Legacy) in a flow

1. Connect a Chat Input or other text source to Input Text.
2. Select a Language Model for validation.
3. From the Guardrails dropdown, select one or more guardrails to enable. For example, select Tokens/Passwords to block API keys and credentials.
4. Connect Pass to components that should receive validated input.
5. Optionally, connect Fail to handle blocked inputs, such as a Chat Output component or Write File component.

Guardrails (Legacy) parameters

Some parameters are hidden by default in the visual editor. You can modify all component parameters through the component inspection panel that appears when you select a component.

Name	Type	Description
Language Model (model)	LanguageModel	Input parameter. Connect a Language Model component to use as the driver for this component. The model reviews the data, compares it against the guardrails, and determines if any data is in violation of the guardrails.
API Key (api_​key)	Secret String	Input parameter. Model provider API key. Required if the model provider needs authentication.
Guardrails (enabled_​guardrails)	Multiselect	Input parameter. Select one or more security guardrails to validate the input against. Options: PII, Tokens/Passwords, Jailbreak, Offensive Content, Malicious Code, Prompt Injection. Default: ["PII", "Tokens/Passwords", "Jailbreak"].
Input Text (input_​text)	Multiline String	Input parameter. The text to validate against guardrails. Accepts Message input types.
Enable Custom Guardrail (enable_​custom_​guardrail)	Boolean	Input parameter. Enable a custom guardrail with your own validation criteria. Default: false.
Custom Guardrail Description (custom_​guardrail_​explanation)	Multiline String	Input parameter. Describe what the custom guardrail should check for. This description is used by the LLM to validate the input. Be specific and clear about what you want to detect. Only used when enable_​custom_​guardrail is true.
Heuristic Detection Threshold (heuristic_​threshold)	Slider	Input parameter. Score threshold (0.0-1.0) for heuristic jailbreak/prompt injection detection. Strong patterns such as "ignore instructions" and "jailbreak" have high weights, while weak patterns such as "bypass" and "act as" have low weights. If the cumulative score meets or exceeds this threshold, the input fails immediately. Lower values are more strict. Higher values defer more cases to LLM validation. Default: 0.7.