Guardrail Rule Builder

Write block, flag, redact and require rules in a one-line-each syntax, run them against your own sample text, and export the JavaScript and Python that enforces them.

Your rulesOne per line: action matcher argument [-> replacement] [ : reason]. Actions: block, flag, redact, require. Matchers: regex, contains, length > N.

Sample text to test them onBlocks separated by a line containing only three dashes. Paste real inputs or real model output.

Match without regard to case (recommended: people evade a case-sensitive filter by accident)

Samples blocked

2 of 4

1 flagged, 1 allowed through. A rule set is only as good as the sample it disagrees with you about, so put the awkward cases in the box above.

Rules parsed: 6
Rules refused as unsafe to run: 0
Lines that did not parse: 0
Samples with something redacted: 2
Samples tested: 4

Every sample, and what fired on it:

1. ALLOWED — "Your refund is on its way. Sources: order #4821." — no rule fired
2. BLOCKED — "Sure — the key is sk-ABCDEFGHIJKLMNOPQRSTUVWX and the accoun…" — block at character 18 (line 2: looks like a leaked API key); redact at character 65 (line 3: a nine-digit id in the answer)
3. BLOCKED — "As an AI language model, I cannot help with that." — flag at character 0 (line 5: the boilerplate refusal opening); require at character 0 (line 7: every answer must cite its sources)
4. FLAGGED — "Email [email protected] if it has not arrived. Sources…" — redact at character 6 (line 4: an email address in the answer)

The samples after redactionSeparated the same way you typed them. Unchanged samples appear unchanged.

JavaScriptRead-only. Select all and copy.

// Generated guardrails. Every rule runs on the same text, in this order.
const RULES = [
  {
    action: "block",
    reason: "looks like a leaked API key",
    hit: (t) => /(?:sk|pk)-[A-Za-z0-9]{20,}/i.test(t),
  },
  {
    action: "redact",
    reason: "a nine-digit id in the answer",
    hit: (t) => /\b\d{3}-\d{2}-\d{4}\b/i.test(t),
    redact: (t) => t.replace(/\b\d{3}-\d{2}-\d{4}\b/gi, "[ID-NUMBER]"),
  },
  {
    action: "redact",
    reason: "an email address in the answer",
    hit: (t) => /[\w.+-]+@[\w-]+\.[\w.]{2,}/i.test(t),
    redact: (t) => t.replace(/[\w.+-]+@[\w-]+\.[\w.]{2,}/gi, "[EMAIL]"),
  },
  {
    action: "flag",
    reason: "the boilerplate refusal opening",
    hit: (t) => t.toLowerCase().includes("as an ai language model"),
  },
  {
    action: "block",
    reason: "longer than this endpoint will accept",
    hit: (t) => t.length > 4000,
  },
  {
    action: "require",
    reason: "every answer must cite its sources",
    hit: (t) => t.toLowerCase().includes("sources:"),
  },
];

export function check(text) {
  const fired = [];
  let redacted = text;
  // Every rule sees the ORIGINAL text; redactions accumulate on a copy, so one
  // rule cannot hide the evidence a later rule was looking for.
  for (const rule of RULES) {
    const hit = rule.hit(text);
    if (rule.action === "require" ? !hit : hit) fired.push(rule);
    if (rule.action === "redact" && hit) redacted = rule.redact(redacted);
  }
  const blocked = fired.some((r) => r.action === "block" || r.action === "require");
  return {
    verdict: blocked ? "blocked" : fired.length ? "flagged" : "allowed",
    fired: fired.map((r) => r.reason),
    redacted,
  };
}

PythonRead-only. Select all and copy.

import re

# Generated guardrails. Every rule runs on the same text, in this order.
RULES = [
    {"action": "block", "reason": "looks like a leaked API key", "hit": lambda t: re.search(r"(?:sk|pk)-[A-Za-z0-9]{20,}", t, re.IGNORECASE) is not None},
    {"action": "redact", "reason": "a nine-digit id in the answer", "hit": lambda t: re.search(r"\\b\\d{3}-\\d{2}-\\d{4}\\b", t, re.IGNORECASE) is not None},
    {"action": "redact", "reason": "an email address in the answer", "hit": lambda t: re.search(r"[\\w.+-]+@[\\w-]+\\.[\\w.]{2,}", t, re.IGNORECASE) is not None},
    {"action": "flag", "reason": "the boilerplate refusal opening", "hit": lambda t: "as an ai language model" in t.lower()},
    {"action": "block", "reason": "longer than this endpoint will accept", "hit": lambda t: len(t) > 4000},
    {"action": "require", "reason": "every answer must cite its sources", "hit": lambda t: "sources:" in t.lower()},
]

def check(text: str) -> dict:
    fired = []
    for rule in RULES:
        hit = rule["hit"](text)
        if (not hit) if rule["action"] == "require" else hit:
            fired.append(rule)
    blocked = any(r["action"] in ("block", "require") for r in fired)
    return {
        "verdict": "blocked" if blocked else ("flagged" if fired else "allowed"),
        "fired": [r["reason"] for r in fired],
    }

What this assumes: every rule is tested against the ORIGINAL text and the redactions are applied to a separate copy, so one rule cannot hide a later rule's evidence by rewriting the thing it was looking for. A regex whose shape can backtrack catastrophically is refused rather than run: your filter executes on your own request path, so a pattern that takes a second on a hostile string is an outage you wrote yourself. require fires when its matcher does NOT match. Matching is done by JavaScript's regex engine here and Python's in the generated code, and the two differ on lookbehind and named groups. Everything on this page runs in your browser. Nothing you paste is uploaded, logged or sent anywhere.

Guardrails fail in two directions and only one of them is visible. A rule that misses something reaches you as an incident; a rule that fires on ordinary text reaches you as nothing at all, because the user whose legitimate question was blocked does not file a ticket, they leave. That asymmetry is why the sample box above matters more than the rule box: the interesting text is the text you expect to pass, and a rule set you have only tested on the thing you were trying to catch has been tested in one direction.

Where each rule belongs

Input rules are free and fast — they run before you spend anything, so a request that was never going to be acceptable costs nothing. Output rules are the ones that catch what the model produced, and they run after you have already paid for the tokens. Length is nearly always an input rule. Leaked-credential patterns are nearly always output rules. Anything expensive belongs on whichever side has fewer calls.

Why a pattern gets refused here

A filter runs on your request path, synchronously, while other work waits behind it. A regular expression with a repeat inside a repeat can take exponential time on a string a user chooses, which turns your safety rule into a way of taking your service down. The check above is structural — it names the shape and the offset rather than timing anything — and a rule it refuses is reported rather than quietly skipped, because a rule you believe is protecting you and is not is worse than no rule.

Guardrail Rule Builder

Where each rule belongs

Why a pattern gets refused here

The reasoning behind this

Related tools