Report sanitization

The strongest privacy measure is not putting sensitive data in reports in the first place. Redaction is a second line of defence.

At generation time (CLI)

1. Fixture content is represented as sha256:<12 hex> fingerprints in evidence unless privacy.include_raw_content: true.
2. Unexpected exceptions are recorded by type only (for example RuntimeError), never with their message, unless raw content is enabled.
3. With privacy.redact_secrets: true (default), every string in the report is scanned and common credential formats are replaced with [REDACTED:<kind>]. The number of redactions is recorded in privacy.redactions.

Recognized formats: private key blocks, AWS access key ids, GitHub tokens, Slack tokens, Memtru tokens, sk- style API keys, JWTs, bearer tokens, and password=/secret:/api_key=/access_token=-style assignments.

At upload time (CLI)

memtru upload builds a new payload from the saved report:

1. If the run recorded raw content, every evidence detail is replaced with [omitted before upload].
2. internal_error messages are reduced to the code.
3. Redaction runs again over every string.
4. privacy.raw_content_included is set to false; the payload is re-validated against schema 1.0.
5. Payloads over 1,000,000 bytes are refused locally.

memtru upload --dry-run shows what would be sent without contacting the server.

At ingestion (server)

The server does not trust the CLI. It rejects reports that declare raw content, reports containing any string that still matches a secret pattern (the response names the JSON path, not the value), and reports that fail strict validation.

Limits

Pattern matching cannot recognise every secret, and it can flag harmless strings that look like credentials. If your adapter returns sensitive data in error messages or metadata, fix the adapter rather than relying on redaction.