A debugging prompt can contain two things at once: useful evidence and identifiers the recipient does not need. Removing everything makes the problem impossible to diagnose. Removing only the obvious email address can leave a credential behind.
Before choosing a redaction tool, define what a useful result should preserve. Here is a small, repeatable review exercise. It uses made-up data and does not require an account, a scanner or a real client document.
1. Seed a fictional example
Start with a deliberately invented support log:
Please explain why this request returned 401.
User: person@example.com
Authorization: Bearer DEMO_NOT_A_REAL_TOKEN
POST /v1/orders
Response: 401 Unauthorized
Timestamp: 2026-10-20T08:00:00Z
example.com and the token marker are test data. This is not an incident record, a working credential or output captured from a scanner.
For this exercise, the method, route and response are the useful context. The email and bearer value are unnecessary for explaining a 401. A manually prepared target might be:
Please explain why this request returned 401.
User: [email]
Authorization: Bearer [token]
POST /v1/orders
Response: 401 Unauthorized
Timestamp: [time]
This is an intended example, not a claim that a particular tool produced it. In a real log, the route, timestamp or identifier might also be confidential. Decide from the task and your organization's handling rules, rather than treating this field list as universally safe.
2. Test both misses and unnecessary changes
One successful substitution says little about coverage. Keep a small set of cases with an expected review decision:
| Fictional case | What to check |
|---|---|
| A repeated email in a heading and a quoted reply | Did you inspect both occurrences? |
| An authorization header beside a 401 response | Was the credential removed while the error remained understandable? |
| A stack trace with a local profile directory | Could the path identify a person or reveal an internal project? |
A harmless placeholder such as [email]
|
Was useful placeholder structure needlessly destroyed? |
| A client-specific project name | Do you need a protected term beyond generic email or token patterns? |
Record the input, the proposed result and your decision. Count a missed value separately from an unnecessary replacement. These are review cases, not a benchmark, and they do not establish a detection rate.
3. Trace the processing boundary first
A check performed before an AI model receives a prompt may itself send that prompt to a service. Ask three questions before entering sensitive text:
- Where does this particular mode run?
- What is retained, and what does the policy actually cover?
- Is the destination permitted for this material?
Encryption in transit and a retention policy address different questions. A server-side check still sends text to a server. If your rules prohibit that transfer, do not use a confidential document to test it.
I build Redaxa, so its current modes provide a concrete example of why the distinction matters:
| Mode | Processing path |
|---|---|
| Free Chrome extension prompt checks | In the browser, on supported chat sites; the checked text stays on the device. |
| Web or Windows prompt checks, and extension checks with an active plan | Redaxa's servers; the published policy says text is analyzed and discarded. |
| Public repository checks on the web | Server-side, on the default branch, with detected values hidden in results. |
| Extended repository reviews in Windows | Local review with accessible Git history and supported archives; downloads and vulnerability lookups require networking. |
Repository review is a separate workflow. Private repositories are not supported. Local extended reviews require Pro or Business; they should not be described as part of the free prompt check.
4. Inspect the result before sharing
Read both versions. Search for repeated identifiers, quoted history and attached fragments. Check that the remaining question is still answerable. An empty finding list is not evidence that every sensitive value was removed, and a replacement does not establish anonymity.
OWASP's guidance on sensitive information disclosure includes sanitization and user education among mitigations. A redaction preview is one review step, not a complete security control.
If a real credential was already exposed, changing a later copy does not revoke it. Follow the issuing service's revocation or rotation process and your incident procedure.
To inspect the product example, compare Redaxa's processing paths and open its fictional preview. The web example uses made-up data; it is not a live detection test. Free live web prompt checks have a daily allowance shared across the network. Detection can miss information and flag harmless text.
Which case would you add to this review set before using a redaction workflow with real work?
Top comments (0)