How to Remove Sensitive Information Before Sharing AI Logs

Before you paste a production log into a chat window, a support ticket, or a public issue tracker, strip the values that identify people, systems, and credentials. The practical method has two stages: catalogue what in your logs is actually sensitive, then apply either a browser-based redaction tool for one-off pastes or a scripted masking step for structured log streams. Both keep the error message and stack trace readable while replacing emails, tokens, IP addresses, database URLs, and similar values with placeholders such as [EMAIL] or [JWT].

This guide is written for developers, support engineers, and technically curious practitioners who use AI assistants to debug. It covers what typically leaks, two concrete workflows you can reproduce, and the tradeoffs that make sanitisation a judgement call rather than a checkbox.

What actually leaks in a log line

Most people think of secrets as API keys. In practice, a single failed request can carry far more. The sample log used by the Log Sanitizer for AI Sharing is a checkout failure, and the tool reports 14 sensitive items in 26 lines — one per category it recognises:

• Customer identifiers: [EMAIL], [PHONE], [IP_ADDRESS], [PAYMENT_CARD]
• Request metadata: [ID], [URL], [LOCAL_PATH]
• Credentials: [JWT] from an Authorization header, [OPENAI_KEY], [COOKIES]
• Infrastructure: [DATABASE_URL], [BROKER], [RESOURCE], [AWS_ARN]

The last group is easy to overlook. A Kafka broker hostname or an AWS ARN does not identify a person, but it maps your private infrastructure, which is exactly the kind of detail a curious reader can use. Categories like these are also where automated pattern matching earns its keep, because nobody remembers to check the broker line by hand.

The same sample also reports one removal under a category the tool calls ‘Trace and log fields’. That is a reminder to inspect stack traces rather than assuming they are inert: frames frequently carry local paths, query strings, and argument values.

Choose the workflow that matches the job

Two situations dominate. If you are pasting one log into one conversation, use a browser-local redaction tool and review the output before copying. If you are sharing logs repeatedly — support rotations, bug reports, fixture generation — build masking into a pipeline so the decision is made once and applied consistently. The two approaches are complementary, and the kelora documentation describes the second one in detail.

Workflow A: sanitising a single log paste

1. Keep the original. Sanitisation removes information, so preserve an untampered copy in a protected location for security responders before you touch anything. The kelora guide makes this an explicit pre-requisite, and it applies equally to ad-hoc pastes.
2. Decide what question you are asking. If you need help interpreting a timeout, you need the error message, the status code, and the timing — not the customer’s email. Narrowing the question first reduces how much you have to redact.
3. Paste into a tool that processes locally. The Log Sanitizer page states that it processes input in the browser ‘whenever possible’ and that it does not store or collect tool input. Read that claim literally: ‘whenever possible’ is a hedge, and file uploads are the case most likely to behave differently from a direct paste.
4. Choose categories and inspect the summary. The sample run reports each removed type with a count, which is how you catch a category you forgot — for example, a Unix home path buried inside a stack trace.
5. Diff the before and after. Confirm the line you actually need survived. In the sample, the cleaned output still contains message: upstream timeout after 30000ms, status: 504, and retry_after_ms: 30000, while the input shrank from 901 to 491 characters.
6. Copy the cleaned version, not the file. It is easy to paste the original by mistake when both are open in adjacent panels.

Workflow B: masking structured logs at scale

The kelora documentation works through a JSONL audit log. The commands below are quoted from that guide; treat them as a documented example rather than a tested recipe, and check your own version’s help output for exact flag behaviour.

Step 1: catalogue the fields

Inspect a small sample before writing any rule. You cannot mask a field you have not noticed.

kelora -j examples/security_audit.jsonl --take 5

List the columns that need masking — user_email, ip_address, token — and note whether the data appears as discrete fields or embedded inside free-text messages. Embedded values need different treatment from structured ones.

Step 2: drop or whitelist

kelora -j examples/security_audit.jsonl -e 'e = e.drop(["password", "token", "session"])' -e 'e = e.keep(["timestamp", "service", "message"])' -F json

drop([...]) removes a batch of known-sensitive fields. keep([...]) rebuilds each record with only the approved shape. The documentation is explicit about why the second is safer: whitelisting the final output shape means unexpected fields cannot leak through. A blacklist only removes what you remembered to name. For flat records, --exclude-keys field1,field2 achieves something similar without an expression.

Step 3: mask direct identifiers

kelora -j examples/security_audit.jsonl -e 'if e.contains("ip_address") { e.ip_address = e.ip_address.mask_ip(2) }' -e 'if e.contains("email") { let parts = e.email.parse_email(); e.email_domain = parts.domain; e.email = () }'

Masking differs from deletion. The IP example keeps part of the address so you can still tell whether two requests came from the same client; the email example keeps the domain and discards the local part, which is often enough to distinguish a corporate tenant from a consumer address. The documentation does not spell out what the 2 in mask_ip(2) controls, so verify the semantics in your installed version before relying on it.

Preserve the debugging signal

Sanitisation reduces context — the kelora guide says so directly — and a log that has been over-redacted is useless. The workable rule is to keep anything that describes behaviour and remove anything that identifies a subject. Error messages, status codes, timings, retry hints, service names, timestamps, and stack frames describe behaviour. Credentials, session cookies, tokens, PII, and internal hostnames identify subjects.

When a value is needed for correlation, replace it consistently rather than deleting it. If the same request_id appears five times, mapping it to a single placeholder such as [ID] preserves the relationship between lines without exposing the real identifier. Deleting it destroys the thread you were trying to follow.

Where sanitised logs are useful beyond chat

Sharing with an AI assistant is only one destination. The kelora guide lists several others that follow the same pattern: preparing logs for customer support, vendors, or public issue trackers; creating test fixtures or reproductions without exposing production data; and complying with privacy regulations before storing logs long term. Each of these has a different tolerance for residual detail. A public issue tracker is effectively permanent and world-readable, while an internal vendor ticket may be governed by a contract. Decide the destination before you decide how aggressive to be.

Limits and failure modes

• Pattern matching misses novel formats. A redaction tool recognises the credential shapes it was built for. A newly issued key format, a bespoke session token, or a secret embedded in a serialised object can pass straight through.
• Field-level rules miss free text. Dropping a password column does nothing about a password that ended up inside an exception message.
• Local processing claims deserve scrutiny. ‘Processes locally whenever possible’ is not the same as ‘never transmits’. If your threat model is strict, test with a synthetic secret and observe network activity.
• Sanitising does not govern retention. Removing secrets from what you paste does not change how the receiving service stores or uses the conversation. That is a separate policy question.
• Sanitised logs are not forensic evidence. Keep the untampered copy; the cleaned version is for sharing.

A pre-send checklist

1. Search the text for known key prefixes and for the words Authorization, Cookie, and password.
2. Confirm the specific error line you want help with is still present and readable.
3. Check that repeated identifiers were replaced consistently, not deleted.
4. Confirm placeholders are obvious — [JWT] is clearer than a blank.
5. Verify you are copying the sanitised output, not the source file.

The next step is to run one real log through either workflow and compare the result against the checklist above. If you hit a value that neither approach catches, that gap is worth reporting: the distance between what tools pattern-match and what actually leaks is where most incidents live. Share your environment, the log shape, and the value that slipped through in the Ai-Forum.org community so others can compare notes.