What remains after you paste a password or API key into ChatGPT

You hit an auth error, ask the model to rewrite a config, or dump “this still will not connect” into the box. The cheapest move is often to paste the password or API key in full. That send is not a question. It is plaintext entering chat history, possibly model training, and possibly another ~30 days of safety retention. Turning off Improve the model for everyone stops training. It does not wipe history. Below, the leftover copies are limited to what OpenAI writes down in its own controls, so you can check them on the page.

Pasting into the box is not “asking a question.” It hands plaintext to the next system

A consumer chat product is easy to treat like a local notepad: the words are still on your screen, so the model is only “looking.” After Send, that text has left this tab. It is now input the provider has to process. Passwords, database URLs, cloud access keys, GitHub personal access tokens, and Stripe live keys sit in the same bucket the OWASP Logging Cheat Sheet usually keeps out of plaintext logs: authentication secrets, access tokens, encryption keys, and other master keys. In a company, the chat pane, a conversation export, and a share link often become informal logs: easy to search, looser than a production vault, and kept longer.

HTTPS only covers eavesdropping on the wire. It does not decide how long the other system stores the input, whether it trains on it, or who can read it. An earlier note covered ticket bodies: once a number is pasted, it enters history and downstream exports. A key in a model session is the same class of exposure. The recipient just changed from “a coworker and a ticket system” to “a model vendor plus its safety, training, and share paths.” What you have to handle before you send is not “is this model smart.” It is “does this paragraph contain a secret that should not leave this tab.”

This note uses ChatGPT’s public controls because the names are written clearly and are easy to re-check. Claude, Gemini, and Copilot inside office suites also keep chat history and their own retention terms. When you change products, walk that vendor’s data-control page again. Do not copy the 30-day window or the training toggle onto another service.

Chat history, training, and safety retention are three different copies

Hearing “will ChatGPT remember my key” as a yes or no misses at least three copies. The first is the chat history you can still open. OpenAI’s chat and file retention help says ordinary conversations stay on the account until you delete them by hand. The title list in the sidebar is evidence that this copy is still there.

The second is model training. Services for individuals—the policy names ChatGPT—may use content to train by default unless you opt out. The page, updated 13 March 2026, draws another line: ChatGPT Team, Enterprise, and the API do not train on inputs and outputs by default; an organization has to choose to share. A consumer account and a company workspace are not the same default. A key you paste in Free or Plus is not covered by “the company bought Enterprise.”

The third is retention for safety and abuse review. Even after a chat leaves your sidebar, the system side can keep it a while longer. Official copy for both ordinary deletes and Temporary Chat is the same shape: scheduled for permanent deletion from OpenAI systems within 30 days, unless the chat was already de-identified or must be kept longer for security or legal duties. After 26 September 2025, OpenAI says it is no longer under an order to keep consumer deleted chats indefinitely. The public line is back to this ~30-day window—not “tap once and every copy evaporates.”

Copy After you turn training off Temporary Chat After you delete the chat
Chat history Still in the sidebar Stays out of history by default Gone from the UI at once
Model training New chats are not used to train Not used while it stays temporary Opt-out covers new chats; it is not written as digging old training data back out
Safety retention Still up to ~30 days after delete Still up to ~30 days ~30 days on the system side (legal / security exceptions aside)
Memory May already be written; delete it separately Does not create new memories by default Deleting the chat does not take a written memory with it
Library files Kept on their own Depends on whether the upload entered Library Deleting the chat does not delete Library files

Turning training off does not mean that key is gone

The Data Controls FAQ puts the switch in one concrete sentence: after you turn off Improve the model for everyone, conversations still appear in chat history; they are just not used to train ChatGPT. Signed in, the path is profile → Settings → Data Controls. Signed out, you can still turn the same item off, but you lose signed-in extras such as export and account deletion. The setting follows the account. It is not counted once per device.

The training policy has another sentence people skip: once you opt out, new conversations will not be used to train. It does not say “content that already entered a training pipeline will be pulled out and deleted.” So “I turned training off later” only answers chats from now on. It does not answer whether last week’s sk_live_ string is still in any training copy. The same policy says they take steps to reduce personal information in training data. That is a processing step, not proof that a key was recognized and stripped.

Archive is not delete. Retention help writes archive as: hide it from the sidebar; the content stays on the account and follows the same rules as an unarchived chat. To start the UI delete and the later system deletion window, you need Delete, not Archive.

Do not demo with a live production key, a coworker’s password, or an unrotated token. When you need to match the UI, use a fake token with a public prefix and disposable characters after it—for example ghp_ plus 36 characters you invent, then treat as burned. If a real key already went in, revoke it at the issuer first. Then talk about training and deleting the chat.

Temporary Chat: the sidebar is empty; the system can still keep ~30 days

Temporary Chat is often read as incognito. OpenAI’s Temporary Chat FAQ is narrower. By default a Temporary Chat does not appear in history, does not create new memories, and is not used to improve models. Before you start, you can choose Personalize: a personalized Temporary Chat can read existing memories, custom instructions, and plugins, but will not create new memories. A non-personalized one reads none of those three. After you choose, you cannot switch mid-chat.

Even with an empty sidebar, official copy still says: for safety, they may keep a copy for up to about 30 days. That is not the same as “it never left your browser.” If you tap Save, the Temporary Chat becomes a regular chat and then follows account-level personalization and “used for training.” Saving and then turning training off only constrains training after it became a regular chat. It does not undo the send that already happened.

If a custom GPT has actions, data sent to a third party through those actions follows the recipient’s privacy policy. The FAQ is explicit: the recipient may keep that data longer than 30 days and may use it for other purposes. Once a model calls an external tool with your key, the retention boundary is no longer only OpenAI’s Temporary Chat clock.

Memory and Library are another copy. Deleting the chat does not take them

The Memory FAQ describes the memory summary as a notepad stored separately from chat history. Delete one conversation and a memory already written from that chat can still be cited later. Official example: the model remembers you live in a city; even after you delete that chat, it may mention the city in a weekend plan. To drop that fact you have to handle the memory-summary entry and any old chats still in history that can be distilled again. Turn memory off and back on, and the model may rebuild memories from history you still keep.

Files are separate too. Retention help says documents or images uploaded in a conversation go to Library when the account or workspace offers Library. Chats and Library files are managed apart: deleting a chat does not delete files already saved to Library. Files on a custom GPT or in a project (including shared projects) wait until that GPT or project is deleted before they enter the ~30-day deletion window. Drag a .env or a key screenshot into the box, then delete only that chat title, and the file side may still be there.

Enterprise workspaces add a compliance layer: Library files follow workspace policy; transient uploads that never entered Library may expire on another clock (the official example is 48 hours, unless policy says otherwise). A consumer account does not have those workspace knobs. Do not comfort a Free session with a number from an enterprise doc.

Share links, GPT actions, and the clipboard make another copy

While the chat is still on your account, one Share creates a snapshot other people can open. The shared-links help says a personal-account conversation link can be viewed by anyone who has the URL. There is no per-recipient grant and no expiry date. Links start with https://chatgpt.com/share/. Official copy says shared pages are “not intended” for search-engine indexing, and in the same breath: that does not make the link private. Anyone who has it can forward it.

A personal-account share is a snapshot from create or update time; later messages do not join automatically. A workspace link can pick up messages after the share. Deleting the shared link only blocks that URL from opening later. It does not delete the original chat, and it does not delete a copy the other person already saved as their own conversation. Delete the original chat and the matching conversation share link goes with it; if a scheduled-task share is attached, delete that task link separately. Turning off Improve the model for everyone does not delete existing shared links or change who can open them.

The clipboard is a copy that exists before Send. OS clipboard history, Handoff, browser extensions, and session replay can keep plaintext before you ever hit the model. After the send, if the reply repeats the key, a screenshot, an export, and the next “continue this shared chat” copy it again. The right order is: mask known shapes to asterisks on this device first, and only send the starred text into the box. When a real value must reach a person, change how you send it. Do not hope the model will “see it and keep it quiet.”

Which key rules can stop you first—and which secrets need another channel

Rule-based redaction matches public prefixes and stable shapes. It does not ask “does this look confidential.” GitHub tokens with ghp_ or github_pat_, AWS access-key IDs in the AKIA shape, Stripe sk_live_ / sk_test_, Slack-style xoxb-, Google API keys in the AIza shape, and a token after Bearer are findable because the issuer made the prefix a marker. A login password with no prefix, a passphrase split with spaces, a homemade token=, a three-part JWT, or the password segment inside a database URL will pass as ordinary text.

That is the same boundary as ticket redaction, with a different job. The ticket note answers which phones and ID numbers a rule can hide. This note only asks: in the paragraph you are about to paste into a model, is there a whole secret. Masked text is fine for “what is this prefix” or “which line of the error matters.” It is not fine for “connect to prod” or “use this key to send a request.” That step needs the real value, so it should not go through a consumer chat.

If a real key already went out, turning training off and deleting the chat are cleanup, not undo. Change the password to a new string and do not reuse the old one. Revoke cloud and source-host tokens in the issuer console and issue new ones. GitHub and similar hosts also scan public repos for keys. That is a different leak surface. Plaintext in a model session and plaintext later committed to a repo have to be handled apart. Neither is proof the other is clean.

The shortest sentence you can send a coworker: for syntax, paste only the starred copy; off training is not delete history; Temporary Chat can still sit 30 days; memory and Library need their own cleanup. When a real key must reach a person, use Burn-Link, not a model.

Check it here: the canary stays in this tab’s box, then search Network

A slogan that says “local redaction, nothing uploaded” cannot prove itself. What you can see in one sitting is four things: which key shapes were named, whether the prefix is still readable after the mask, whether an ordinary sentence you left on purpose is still there, and whether the source text left as business data. This step only proves “did this local tool send the canary.” It does not prove ChatGPT will forget on your terms. That side can only be checked against official controls. Network cannot stand in for it.

First build a canary with no real identity. For a key, use a fake token with a public prefix—ghp_ plus 36 characters you invent, or sk_test_ plus disposable characters. For a password, use an obviously fictional passphrase such as canary-not-a-real-secret-2026. Then write an ordinary ask: “Explain why this config returns unauthorized. Do not repeat the full token.” After the run, the prefixed token should appear in the hit counts and become a mask. The fictional passphrase should stay as-is. That is not a bug. It is the rule boundary: it matches prefixes, not homemade passwords.

Then open DevTools Network, enable Preserve log, and search for the unique canary strings. They should not appear on an XHR or Fetch request line, query, or body, and they should not appear in analytics query or body either. A static script filename that contains “privacy” or “redact” is expected. Source text leaving as a business field is a fail.

  1. Write a “please look at this error” paragraph from a fake ghp_ or sk_test_ token plus a fictional passphrase. Do not use a real key.
  2. After the run, check hit types: the prefixed token should be named; the homemade passphrase should still be in the result.
  3. Search Network for the canary source. Any business request that hits means the input left this tab.
  4. Only masked text may enter any model box. If a real key must reach a person, switch to Burn-Link.

The proof is narrow. In this one run, known prefixes became masks, the homemade passphrase was not treated as a key, and the source text did not leave this tab as an observed HTTP field. It does not prove an extension never read the box. It does not prove what the model side will store after you paste the masked result into ChatGPT. After you change browsers or toggle a rule, run the canary again.

Practice the boundary on a redaction page that opens with no account

If you want a page that puts type toggles and hit counts in the open, start from MakePwd Privacy Cleaner’s Data Redaction mode. It opens with no account and no sign-in. Scan and mask run in the current tab. Per the product notes, source text is not sent as a request and is not written to analytics. The checkable types include phone, national ID, bank card, email, API key, and IP. API key matching is those public prefixes plus the Bearer shape. Smart masking is the default; you can switch to a full mask. One paste is capped at 512 KB. The page states the limits: it cannot recognize every key format, it cannot prove the text meets a compliance regime, and important outbound mail still needs a human pass.

Practice only with canaries. After a run, look at three places at once: the hit-type counts, whether the fictional passphrase is still in the result, and whether Network contains the source. Counts answer “did it name the prefix.” The passphrase answers “where does the rule stop.” Network answers “did it upload.” When all three pass, you can tell a coworker: I masked these shapes, I know the homemade password is still there, and I searched the canary on the wire.

If after redaction you still have a secret that must arrive intact, send it once with Burn-Link and keep the key in the URL # fragment. Create and read both open with no account; the server only stores ciphertext briefly. For a whole file that contains keys, encrypt it locally in File Encryption Box to .lock / .enc (one file, at most 5 GB) and then use a drive or mail. After you revoke a leaked login password at the issuer, use the Password Generator on this device for a new 6–128 character string (default 16; under 8 is flagged as weaker). Do not paste the old string into any model. None of those steps requires a login.

FAQ

If I turn off Improve the model for everyone, is that key gone?

No. It is still in chat history. OpenAI’s Data Controls FAQ says that after you turn training off, conversations still appear in history; they are just no longer used to train ChatGPT. Opting out applies to new conversations. The policy does not say older content that already entered training will be dug out and deleted.

Does Temporary Chat vanish from OpenAI’s systems the moment I paste?

No. A Temporary Chat stays out of the sidebar by default, does not create new memories, and is not used for training, but OpenAI may still keep a copy for up to about 30 days for safety review. If you tap Save, it becomes a regular chat and then follows your account’s training and personalization settings.

After I delete the chat, are memory and uploaded files gone too?

They can still be there. Memory summaries and Library files are stored separately from the chat. Deleting a conversation does not clear a memory already written, and it does not delete a file that already landed in Library. Deleting a shared link also leaves any copy the recipient already saved in their own account.

After I mask the text, can I paste the original key into ChatGPT?

No. Masking catches token shapes with public prefixes. It will not catch a homemade password or a key you split with spaces. When you ask about syntax or an error, paste only the starred copy. If a real key must reach a person, send it once with Burn-Link. Do not put it in a model session.

Three things to remember before the next paste

First: send is copy. Chat history, training (if you have not opted out), about 30 days of safety retention, memory, Library, and a share link can each keep a copy. Editing the current page does not reclaim plaintext that already left. Second: turning training off only stops model improvement; it does not wipe history. Temporary Chat only stays out of the sidebar. It is not zero retention. Third: mask on this device before anything enters a model box, and search Network for a canary. A real key that must arrive intact goes through Burn-Link. A leaked password is revoked first, then replaced.

If the next question is which fields a rule can hide in a ticket body, read What rule-based redaction hides in a ticket or chat log—and what it still leaves behind. If you need to prove plaintext never left this tab as business data, read How to verify browser encryption: prove plaintext never left. This note only draws a line you can write into a conclusion: what can still remain after a key enters a consumer model session.