Redact the journal before the model reads it

Written by

in

29 October 20262 minutes

A journal is the most honest thing on a Linux host and the worst thing to paste into a model. It contains tokens, internal hostnames, mail addresses, sometimes an entire environment. The pipeline below redacts first, then summarises, and keeps a hash so you can still correlate.

Redact before you send, not after

journalctl -u myapp --since "1 hour ago" --no-pager \
  | sed -E 's/([A-Za-z0-9_]*(TOKEN|SECRET|PASSWORD|KEY)[A-Za-z0-9_]*=)[^ ]+/\1[redacted]/g' \
  | sed -E 's/[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+/[email]/g' \
  | sed -E 's/\b[0-9]{1,3}(\.[0-9]{1,3}){3}\b/[ip]/g' \
  | sha256sum

The hash is the point. You send the redacted text, keep the hash in your notes, and when the model says “the third line is the cause” you can prove which file it came from without sending the file.

Allow-list the shape, not the content

Instead of pattern-matching every possible secret — you will miss one — reduce the log to lines that match a small grammar of what you care about:

grep -E 'error|fail|denied|refused|timeout|OOM|Segmentation' \
  | cut -c1-240 | sort | uniq -c | sort -rn | head -40

Forty deduplicated lines, no arguments, no payloads. That is a prompt a small model can handle, and a log nobody can leak.

Keep the model out of the decision

The model proposes; systemctl status disposes. If the summary cannot be checked with one command, it is not a summary, it is a rumour.