Hold this first: what you need to check before you paste into AI is whether this outbound string still contains plaintext sensitive fields. Turning off a training toggle, or switching to a temporary chat, only changes how the other side retains and learns. It does not change the fact that the fields already left. The steps below are a comparison you can repeat—not a new adjective.
Answer the search intent in one sentence
Redacting tickets and logs before you paste them into AI means: before the text leaves the tab you are looking at, mask phones, ID numbers, emails, common API keys, and IPs with rules, then scan by hand for prefix-free passwords and connection strings. The object of the check is the copy you will paste—not a “processed” badge on the page.
This note is for developers, ops, and support staff who drop material into an AI box. It is not a substitute for the privacy cleaner how-to, and it does not repeat the broader Network walkthrough of “did local encryption upload anything.” What you should take away is which fields usually hide in logs, what rules can cover, and when a leftover secret should become a placeholder or go through Burn-Link instead.
Pasting into AI is a different outbound boundary than sending to a coworker
When you send a ticket to a coworker, the recipient is usually a known person, and the material lands in a ticket system or a chat history. When you paste into a consumer AI product, the same characters also enter that product’s servers, its conversation history, and whatever data-processing terms are in force that day. OpenAI’s Data Controls FAQ is explicit: a personal account can turn off “Improve the model for everyone”; chats still appear in history, they just are not used to train the model. Temporary Chat skips history and training, but may still be kept for up to about 30 days for abuse monitoring.
Terms change, and products differ. The judgment you can finish right now is narrower: once you paste and send, those characters have left this machine. The training toggle answers “will they use it to improve the model.” It does not answer “did they receive it.”
So ask “should this block leave this machine” first, then “how will the other side retain it.” The second question belongs in that product’s help center. The first one you can finish with a comparison table before you hit send.
Do not experiment with a real ID number, an unrotated API key, or a production database password. Prepare a throwaway fake ticket. Write the phone and the key as canaries that exist only for this run. You are checking masks and the outbound boundary—not exposing a secret again.
Fields that most often hide in tickets and logs
What leaks is rarely a whole contract. It is a short field sitting in the middle of a sentence: an email in a stack trace, a phone number in a screenshot caption, a copied Authorization: Bearer … header, an IPv4 from an internal login page. Any of those is enough to turn the next chat into a plaintext copy.
Sorting by where the field appears is more useful than sorting by how “sensitive” it feels.
| Where it shows up | Typical fields | What to do before you send |
|---|---|---|
| Support tickets, chat transcripts | US and international phones, emails, last digits of an ID | Mask with rules, then scan informal phrasing by hand |
| App logs, stack traces | Emails, IPv4 / IPv6, the occasional token | Mask IPs and emails; check whether the token has a fixed prefix |
| Config snippets, curl examples | sk-, AKIA, ghp_, Bearer |
Rules hit common prefixes; anything they miss becomes a placeholder |
| Handoff notes, recovery steps | Database passwords, recovery codes, full connection strings | Do not paste into AI; use Burn-Link or leave a placeholder only |
| Shared links | utm_*, fbclid, gclid |
Strip tracking first, then decide whether the URL belongs in the prompt |
Fields that “do not look like a secret” still deserve a look. An internal IP marks a subnet. The last four digits of an ID, stacked with a name already in the ticket, can identify one person. Rules keep a little of the start and end by default so you can confirm “this is the same row I just pasted.” That leftover is for your check, not proof of anonymization.
What rule-based redaction covers—and what it does not
In-browser rule-based redaction is pattern matching: regular expressions find spans that look like phones, ID numbers, emails, key prefixes, and IPs, then replace them with a mask. It does not understand meaning, and it does not read your ticket system.
Take the Data Redaction Tool on FastPwd’s privacy cleaner as an example. The current tab can detect international phones and Chinese mainland mobiles; ID numbers (including a Chinese mainland ID checksum and a US SSN); 13–19 digit bank cards that pass Luhn; emails; common API key / token prefixes (for example sk-, sk-proj-, AKIA, ghp_, github_pat_, glpat-, Bearer); plus IPv4 and common IPv6. A little of the start and end stays by default so you can check the hit; you can also star the whole value. Text over 512 KB needs to be split. The page is ready to use—no account.
What it misses is equally concrete. A prefix-free password, a key split with spaces, text that only exists in a screenshot, or a “1 written as l” dodge will slip through. Street addresses, employee IDs, and internal project names are not on this list. A zero-hit result means “these patterns did not match.” It does not mean “this block is safe to send to anyone.”
That is also how this article differs from the cleaner tool page. The tool page answers how to mask right now. This note answers whether you should still press send after the mask. The result pane shows a character-count comparison and hit types, and it does not post the source text to an API—even so, look at the cell you are about to paste before you send it.
Run a canary comparison before you send
Prepare a throwaway fake ticket. Write a phone number that exists only for this run, an email such as canary-fp-20260901@example.com, a fake key with a common prefix such as sk-proj-canaryfp20260901xxxx, and one prefix-free fake password such as canary-plain-pass-20260901. The canary is for search. It is not a demo that “the tool is clever.”
- Paste the fake ticket into the redaction box and run the mask. Compare the result: prefixed keys, emails, and phones should be starred; the prefix-free password will usually still be there.
- Replace any leftover plaintext password with a placeholder such as
[DB_PASSWORD]. Do not expect a rule to notice informal wording like “the password is xxx.” - Copy only the result text. Before you paste it into the AI box, search the system find dialog for the canary: the full plaintext of the fake email and the fake key should be gone.
- If you also want to confirm that the redaction page itself did not send the source, open DevTools Network, check Preserve log, and search the same canary in request lines, bodies, and analytics payloads.
Read the result pane, not the button label
“Redacted 4 spans” only means the rules hit four stretches. It does not tell you a fifth password is still sitting there. The comparison belongs on the result text: search each canary you planted, then scan for long high-entropy strings that do not look like a known pattern.
Read the cell you are about to send
When you copy from the result pane a second time, an extension may rewrite the clipboard, or the browser may still hold the original selection. Searching the canary again inside the AI input is closer to the real outbound content than glancing at the redaction page once.
Also check the redaction page’s own traffic
FastPwd analytics uses the site’s own tracker. On localhost it does not send by default. Event names look like “redaction ran”; per the notes they do not carry source text. That is still a claim. Searching Network for the canary turns “source text is not uploaded and is not written to analytics” into an observation for this run. A fuller traffic check is in How to check if browser encryption never uploaded plaintext.
Always prepare two fake passwords: one with sk- or Bearer, so you can see the rule working, and one long random phrase, so you remember that whatever was not masked is what will actually leak.
When to mask, when to use a placeholder, when to use Burn-Link
The three treatments fit three kinds of material. Mixing them is how people get hurt.
Phones, emails, ID numbers, and prefixed tokens scattered through a sentence are a fit for rule-based masking. You want “this log is still usable for a stack-trace question,” not “hand the whole secret to the model.”
When the question can change but the material must stay complete, use a placeholder. Swap a connection string for postgres://USER:[DB_PASSWORD]@HOST:5432/DB and ask about syntax. The model does not need the real password to explain an error format.
When a complete secret must reach another person, do not route it through an AI box. FastPwd Burn-Link encrypts in this browser with AES-256-GCM, stores ciphertext only on the server, and appends the key after the hash in s.html?id={id}#{key}, so the key is not in the HTTP request by default. Create and read need no signup. One note is capped at 32 KB; larger files go to File Encryption Box, one file up to 5 GB. If you paste the full link into chat, the protection after the hash is gone. The details are in Why a URL hash can hold a key, and when that protection fails.
| Material | Better treatment | What “pass” looks like |
|---|---|---|
| Phones / emails / ID numbers in a ticket | Rule-based redaction | No full plaintext in the result; hit types match what you planted |
Tokens with sk- or ghp_ |
Rule-based redaction or a placeholder | The prefix may stay; the middle must be starred |
| Prefix-free passwords, recovery codes | Placeholder; Burn-Link if someone must receive the real value | The AI box contains none of those characters |
| A whole key file | File Encryption Box; do not paste into a chat box | Download a .lock; the chat box has only a file name |
What this check can prove, and what it cannot
The conclusion this comparison supports is narrow. Writing it down is what lets you align with a coworker.
It can support: in this browser, on this run, the text you are about to send no longer shows the plaintext canaries you planted; the redaction page’s request lines, bodies, and analytics payloads do not contain that canary either.
It cannot support: the rules covered every name, address, and employee ID; the other product will not keep the chat for a safety review; an extension did not rewrite the clipboard; a redacted result equals legal anonymization. FastPwd’s privacy cleaner states this is an assistive review. It does not claim GDPR or HIPAA certification.
Do not treat “the model did not echo the password” as proof that send failed. Content the server already received does not return to your tab because the UI later draws stars.
FAQ
If I turn off “Improve the model for everyone,” does pasted ticket text stay on this machine?
No. Turning off training only changes whether the model learns from that chat. The conversation still reaches that product’s servers and can appear in your history. Temporary Chat usually skips history and training, but it may still be kept for up to about 30 days for abuse monitoring—this follows OpenAI’s Data Controls notes that were still current in September 2026; other products follow their own terms. Redaction targets the outbound text, not the training toggle.
Can a redacted result serve as a compliance certificate or anonymization report?
No. Rule-based redaction is pattern matching: it can mask phones, ID numbers, emails, common API keys, and IPs, and it will miss informal phrasing or prefix-free passwords. It does not claim GDPR, HIPAA, or any other certification. Review the text you are about to paste before you send it.
After redaction, can I paste a full database password or recovery code into AI?
Usually no. Prefix-free passwords, connection strings, and recovery codes often do not match a rule. Send that material through Burn-Link instead: encrypt locally with AES-256-GCM, store ciphertext only on the server, and keep the key after the hash in the link. Leave a placeholder such as [DB_PASSWORD] in the AI box.
When I redact on FastPwd, is the source text uploaded or written to analytics?
Per the product notes, parsing and masking finish in the current tab. Source text is not sent as HTTP business data and is not written to analytics. Analytics records event names such as “redaction ran.” To check this run, search Network for a canary: it should not appear in request lines, bodies, or analytics payloads. After you close the tab, that input is not left on a FastPwd server—because it never arrived there as business data.
Walk the steps with a fake ticket
If you want a page that states the compute boundary in writing, open FastPwd Data Redaction. Ready to use; no signup. Paste the fake ticket above, leave Phone, ID number, Bank card, Email, API Key, and IP checked, read the hit types under the default mask, then turn on full mask and compare once more.
Use the same material for a second drill: only after leftover fake passwords become placeholders may the text enter any AI box. When a complete secret must reach a coworker, switch to Burn-Link. Do not paste the full burn address and the key back into AI. If the ticket still carries a campaign short link, strip utm_*, fbclid, and gclid with Clean Link on the same page before you decide whether that URL belongs in the prompt.
These drills do not prove that any one site is “absolutely safe.” They leave you, before you press send, with a comparison a coworker can read: canaries, hit types, placeholders, and a Network pass when you need one. Swap in any “smart mask” or “enterprise AI gateway” and the same steps still apply.
Remember three things the next time you send. First, read the text you will send, not the button label. Second, rules cover scattered fields; they do not cover a whole password. Third, a training toggle changes how the other side uses the text; it does not change the fact that the fields already left this machine. A comparison you can repeat is the one worth writing into your own ticket policy.
Further reading
To confirm that the redaction page itself did not send the source, run the same canary through Network: How to check if browser encryption never uploaded plaintext. When a complete secret must reach a person rather than a model, see why a key can sit after the hash: Why a URL hash can hold a key, and when that protection fails.