Rule-Based Guard

Introduction

The Rule-Based Guard scans both incoming messages and the agent's response against a list of Java regular expression patterns, and blocks, redacts, or redirects whenever any pattern matches.

What it does

The Rule-Based Guard intercepts content at two points in every agent run. Before the main LLM receives the user's messages, the guard checks all message text against your patterns. After the LLM produces a response, the guard checks that response text as well. Both directions use the same rules.

When any pattern matches, the guard applies the action you configured:

• Block stops the agent run immediately.
• Sanitize replaces every matched region with your replacement text and lets the agent continue with the redacted content. The LLM never sees the original value.
• Redirect jumps execution to another task instead of continuing.

Because everything runs in the JVM with no network calls, the guard adds no latency and no cost.

When to use it

Use a Rule-Based Guard when the content to detect has a known, predictable format and you need guaranteed, deterministic enforcement with zero performance overhead.

Typical scenarios include the following:

Get started

How to use it

To use the Rule-Based Guard Element, follow these steps:

1. Locate the Rule-Based Guard element under the Decisions section in the palette.
2. Drag and drop the element into the Drop a guard to here section.
   

Configure Form Properties

To properly integrate and configure the rule-based guard, set the following fields:

• Personalized Names: Specify a name for the rule-based guard.
• Purpose: A label describing what this guard instance does. Not evaluated at runtime. Enter a plain-language description (e.g., Block SSNs and email addresses). This is a required field.
• Patterns (Required): The list of regex patterns to match against content. Add one row per pattern. Each row contains one Java regular expression. Any match triggers the violation action.
• Replacement Text: The text that replaces matched content when the action is Sanitize. Enter any string (default is [REDACTED]). This is a required field.
• On Violation (Required): What happens when any pattern matches. Select Block, Sanitize, or Redirect
  
  • Redirect Task ID: This setting only appears when Redirect is selected. The task to jump to when a violation is detected. Enter the ID of an existing task in this agent. This is a required field.

Samples

Row 1, Social Security Number:
  Pattern: \b\d{3}-\d{2}-\d{4}\b

Row 2, Email address (case-insensitive):
  Pattern: (?i)\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b

Row 3, Visa card number:
  Pattern: \b4[0-9]{12}(?:[0-9]{3})?\b

Best Practices

• Patterns use Java regular expression syntax. For case-insensitive matching, embed the flag directly in the pattern: (?i)your pattern. The pattern is tested with find(), meaning it matches anywhere in the scanned text.
• Invalid patterns are skipped silently. A pattern with a syntax error is logged as a warning, but does not stop the agent. Test every pattern before deploying to production; a skipped rule means no protection.
• Sanitize mode replaces all matched regions, not just the first. Every occurrence of each matching pattern is replaced, in both input and output.
• Multiple patterns all apply. Unlike a decision's ordered routes, all patterns in the list are checked, and all matches are replaced. There is no first-match-only behaviour.
• Block and Redirect act on the first matching pattern. Sanitize continues checking remaining patterns after each replacement.