Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/facunemi/evidence-sanitizer/llms.txt

Use this file to discover all available pages before exploring further.

The sanitize command creates a sanitized copy of a single evidence text file, replacing recognized sensitive values with deterministic redaction markers and printing a safe report of which rule families triggered. The original input file is never modified — all output lands in an explicitly provided destination path that must not already exist.

​
Usage

evidence-sanitizer sanitize INPUT --output OUTPUT [--dry-run]

​
Arguments and Options

​
INPUT
path
required
Path to the evidence text file to sanitize. Must be a readable regular file encoded in strict UTF-8 or UTF-8 with BOM. The file must not exceed 10 MiB and must not contain NUL bytes. This file is never modified.
​
--output
path
required
Path where the sanitized copy will be written. The parent directory must already exist. The path must not already exist (the command uses exclusive creation and will error if a file or symlink is present at this location). The resolved path must not refer to the same file as INPUT.
​
--dry-run
boolean
default:"false"
When set, the command performs all validation, reading, decoding, and detection steps but writes no output file and creates no temporary files. The report of triggered rule counts is printed to stdout exactly as it would be for a normal run, prefixed with Dry run: no output written. Use this flag to audit what will be redacted before committing to a sanitized copy.

​
Behavior and Safety Guarantees

The sanitize command enforces a strict safety model at every stage:
  • Input file is never modified. All changes are written exclusively to the --output path.
  • Output path must not already exist. The command uses exclusive file creation (open("xb")). If a file or symlink already exists at the output path, the command exits with an error before writing anything.
  • Output parent directory must already exist. The command does not create intermediate directories.
  • Output path must not resolve to the same file as input. Both paths are resolved before any I/O begins.
  • Maximum input size: 10 MiB. Files larger than 10,485,760 bytes are rejected before reading their contents.
  • Input must be strict UTF-8 or UTF-8 with BOM. Any other encoding causes an input error. UTF-8 BOM presence, line endings (LF/CRLF/mixed), and final-newline state are preserved in the output.
  • NUL bytes are rejected. Input containing \x00 bytes is refused with an input error.
The output file must not exist before you run the command. evidence-sanitizer sanitize will exit with an error and write nothing if a file or symlink is already present at --output. If you need to re-sanitize, remove or rename the previous output file first.

​
Output Format

A successful run prints the input and output paths, followed by a count of every rule ID that triggered, sorted alphabetically: 
Sanitized: evidence.txt -> evidence.sanitized.txt
Rules triggered:
authorization.bearer: 1
cookie.value: 3
header.secret: 1

​
When No Rules Trigger

If no sensitive values are detected in the input, the command still writes the output file (an identical copy of the input) and reports: 
Sanitized: evidence.txt -> evidence.sanitized.txt
Rules triggered: none
Reports contain only fixed rule IDs and counts. They never include detected values, source excerpts, header names, cookie names, or parameter names.

​
Before and After Example

The following synthetic HTTP request demonstrates several rule families triggering in a single file. Input (evidence.txt): 
POST /api/v1/sessions HTTP/1.1
Host: api.example.test
Authorization: Bearer synthetic-bearer-token
X-API-Key: synthetic-api-key
Cookie: session=synthetic-session-value; _ga=GA1.2.synthetic; theme=dark
Content-Type: application/x-www-form-urlencoded

client_secret=synthetic-client-secret&grant_type=authorization_code
Command: 
uv run evidence-sanitizer sanitize evidence.txt --output evidence.sanitized.txt
Output file (evidence.sanitized.txt): 
POST /api/v1/sessions HTTP/1.1
Host: api.example.test
Authorization: Bearer <REDACTED:authorization.bearer>
X-API-Key: <REDACTED:header.secret>
Cookie: session=<REDACTED:cookie.value>; _ga=<REDACTED:cookie.value>; theme=dark
Content-Type: application/x-www-form-urlencoded

client_secret=<REDACTED:form.value>&grant_type=authorization_code
Terminal output: 
Sanitized: evidence.txt -> evidence.sanitized.txt
Rules triggered:
authorization.bearer: 1
cookie.value: 2
form.value: 1
header.secret: 1
Note that theme=dark is left unchanged — theme is a known harmless cookie name. The Host header and grant_type form field are not in the sensitive name sets and are likewise left untouched.

Build docs developers (and LLMs) love

Get started for freeTalk to us