Skip to main content

Code Sanitizer

This page remains at code-sanitation.md for continuity, but the supported policy_kind is code-sanitizer.

The code-sanitizer policy defaults to the pre-request stage and scans the joined active-stage messages for a small set of dangerous patterns plus any configured custom regexes. Set a chain entry's stage explicitly when the policy must inspect a different stage.

Phase and verdicts

  • Default phase: pre_request
  • Possible verdicts: allow, redact, block

Configuration

pack:
name: code-sanitizer-example
version: 1.0.0
enabled: true
policies:
chain:
- code-sanitizer
policy:
code-sanitizer:
enabled: true
block_on_match: false
additional_patterns:
- AKIA[0-9A-Z]{16}

Supported fields

FieldTypeDefaultNotes
enabledbooleantrueDisables scanning entirely when false.
block_on_matchbooleanfalseWhen true, matched content blocks; otherwise the verdict is redact.
additional_patternsstring[][]Extra regexes compiled alongside the built-in pattern set. Invalid regexes are skipped.

Built-in patterns

The current built-in detector looks for these regexes:

  • rm -rf
  • drop table
  • 169.254.169.254
  • curl http(s)://localhost
  • chmod 777
  • aws s3 cp ... --recursive

How it works

  1. The gateway joins the messages available at the active execution stage.
  2. It runs the built-in regex set plus additional_patterns.
  3. Every matched snippet is replaced with [redacted code pattern].
  4. If anything matched:
    • block_on_match: true → verdict block
    • block_on_match: false → verdict redact
  5. Content with no matches returns allow.

Behavior notes

  • The policy scans all joined message text available at its active stage, not only fenced code blocks.
  • The canonical policy name is code-sanitizer, not code-sanitation.
  • The built-in rule set is intentionally small and concrete; it is not a full vulnerability scanner.

Example scenarios

Redact matched content

policy:
code-sanitizer:
block_on_match: false

Block matched content

policy:
code-sanitizer:
block_on_match: true

Best practices

  • Use block_on_match: true when matched code or commands must never continue through the active stage.
  • Add additional_patterns only for patterns you have tested on representative traffic.
  • Pair code-sanitizer with broader review controls when code quality, logic safety, or architecture concerns matter.

Next steps