Skip to main content

Code Sanitizer

The code-sanitizer policy uses the pre-request stage by default. It examines one string made from the stage messages against constant and custom regex patterns. The policy name is code-sanitizer.

The evaluator records a sanitized copy in policy details. It does not replace the stage messages or the forwarded request with that copy.

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
enabledbooleantrueA value of false stops all checks.
block_on_matchbooleanfalseA value of true blocks matched content. A value of false returns a redact verdict without forwarding the helper's sanitized copy.
additional_patternsstring[][]More regexes that run with the built-in pattern set. Invalid regexes are skipped.

Built-in patterns​

The active 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 makes one string from the messages available at the active execution stage.
  2. It runs the built-in regex set plus additional_patterns.
  3. It makes a result copy that replaces matches with [redacted code pattern].
  4. It records that copy and the findings in policy details.
  5. If a pattern matches, the config selects the verdict:
    • block_on_match: true → verdict block
    • block_on_match: false → verdict redact
  6. Content with no matches returns allow.

Behavior notes​

  • The policy examines all 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 small. It is not a full vulnerability scanner.
  • A redact verdict does not prove that the forwarded request omits the matched code.

Example scenarios​

Record matched content without a hard block​

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 not continue through the active stage.
  • Do not use block_on_match: false when the caller must have content removal.
  • Add only additional_patterns that you tested with typical traffic.
  • Pair code-sanitizer with broader review controls for code quality, logic safety, or architecture.

Next steps​