Mesedi
Start free →

Docs / Security / Custom patterns

Custom security patterns

Three of Mesedi's security detectors — prompt_injection, data_leakage, and sandbox_escape — accept your own regex rules in addition to Mesedi's built-in patterns. Your patterns are stored per-project, RE2-validated at save time, and run on every event alongside the built-ins.

Which detector scans what

prompt_injection — scans user_message and system_prompt on every llm_callevent. Use this for jailbreak-style phrases your customers' agents have seen before that Mesedi's 8 built-in patterns don't catch.

data_leakage — scans system_prompt, user_message, response_text, and tool call arguments + return_valueat event ingest. Use this for company-specific secret shapes — internal API key prefixes, customer ID formats, etc. — that aren't in the built-in DLP ruleset.

sandbox_escape — scans tool call arguments and return_valuefor code-execution-sandbox escape attempts. Use this for sandbox-specific patterns (e.g. your sandbox's socket library names, your container metadata endpoints).

How to add a pattern (dashboard)

Go to Settings, scroll to the per-detector Custom patterns sections, click + Add pattern, and provide:

  • Pattern — an RE2 regex (linear-time guaranteed; no PCRE features).
  • Severity — low, medium, or high. Affects dashboard chip color and, for data_leakage hits, whether a sibling dlp_scan_result event fires.
  • Description — optional note for future-you / your team.
  • Enabled — disable a noisy pattern without deleting the rule definition.

API endpoints

Prefer scripting over the UI? All four operations are available via REST:

# List your prompt_injection patterns.
curl -H "Authorization: Bearer $MESEDI_API_KEY" \
  https://api.mesedi.ai/me/pattern-config/prompt_injection

# Add one.
curl -X POST -H "Authorization: Bearer $MESEDI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"pattern":"(?i)force.+admin.+mode","severity":"high","description":"company-specific jailbreak shape"}' \
  https://api.mesedi.ai/me/pattern-config/prompt_injection

# Disable a pattern without deleting it.
curl -X PATCH -H "Authorization: Bearer $MESEDI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"pattern":"(?i)force.+admin.+mode","severity":"high","enabled":false}' \
  https://api.mesedi.ai/me/pattern-config/prompt_injection/ppat-xxxxxxxx

# Delete.
curl -X DELETE -H "Authorization: Bearer $MESEDI_API_KEY" \
  https://api.mesedi.ai/me/pattern-config/prompt_injection/ppat-xxxxxxxx

Substitute data_leakage or sandbox_escape for the detector path segment to manage those rule sets.

RE2 syntax notes

Mesedi uses Google's RE2 regex syntax. Most patterns work as you'd expect from PCRE, but a few features common in other engines are NOT supported:

  • No backreferences (\1, (?P=name)) — RE2's linear-time guarantee depends on this.
  • No lookaround ((?=...), (?!...)).
  • No catastrophic-backtracking constructs. (a+)+b is safe in RE2.
  • (?i) case-insensitive flag works as usual. Prefer it over manual character classes.

Invalid patterns are rejected at save time with a 400 naming the syntax error. You won't silently ship a broken pattern.

Ordering vs Mesedi's built-in patterns

For prompt_injection and sandbox_escape, Mesedi scans its built-in patterns first and your custom patterns after. This preserves clustering stability — failure groups customers built dashboards against keep their canonical signature when the canonical pattern matches. Custom matches cluster under custom:<pattern_id> signatures so you can see customer-defined rules separately in the dashboard. For data_leakage both rule sets run; hits from both surface in the same dlp_scan_result sibling event.

The 200-pattern cap

You can store up to 200 patterns per (project, detector) for a total of 600 across the three security detectors. The cap keeps the per-event scan time bounded; bump against it and Mesedi returns 429 with a clear message. Most customers settle around 10–50 custom rules per detector after a tuning pass; the dormant badge in the dashboard helps you prune ones that aren't firing.

Current limitations

  • Redaction on custom data_leakage patterns. Custom data_leakage rules detect hits and fire the sibling dlp_scan_resultevent, but they do NOT redact the matched bytes in place the way Mesedi's built-in rules do.
  • Tier-aware caps. The pattern-count cap is global (200), not tier-aware.

Design choices you should know

  • Custom patterns augment, never replace. There is no way to disable a Mesedi built-in pattern today. If a built-in is firing on something you want to allow, file a docs report and we'll consider tightening the canonical rule. By design.
  • No client-side regex preview. The dashboard does not test your regex against sample inputs before save — RE2 is the source of truth and lives on the backend. Save your rule, watch its match count climb on the table view. By design.