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
| Field | Type | Default | Notes |
|---|---|---|---|
enabled | boolean | true | Disables scanning entirely when false. |
block_on_match | boolean | false | When true, matched content blocks; otherwise the verdict is redact. |
additional_patterns | string[] | [] | 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 -rfdrop table169.254.169.254curl http(s)://localhostchmod 777aws s3 cp ... --recursive
How it works
- The gateway joins the messages available at the active execution stage.
- It runs the built-in regex set plus
additional_patterns. - Every matched snippet is replaced with
[redacted code pattern]. - If anything matched:
block_on_match: true→ verdictblockblock_on_match: false→ verdictredact
- 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, notcode-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: truewhen matched code or commands must never continue through the active stage. - Add
additional_patternsonly for patterns you have tested on representative traffic. - Pair
code-sanitizerwith broader review controls when code quality, logic safety, or architecture concerns matter.
Next steps
- Agent Firewall policy — control agent tool behavior around code execution
- PII Detector policy — catch sensitive data outside code-like patterns
- Policies overview — policy chain architecture