Skip to content
,
Claude · Part 6

Memory, privacy, and what never to paste

13 min read
Memory, privacy, and what never to paste, with the official product logo. Editorial illustration for Analytics Made Simple.

Someone on your team pastes a customer export into a personal chatbot “just to draft the email.” Someone else pastes an HR spreadsheet “just to summarize headcount.” The draft comes back polished. But the risk does not go away just because the prose is good.

This post continues Learn Claude from scratch. The earlier post covered writing, summarizing, studying, and planning. Those same skills get dangerous the moment sensitive text rides along with them. Here we separate three easy-to-confuse layers, meaning chat history, memory, and project files, and walk a paste ladder from never to safer. We also build review habits you can actually keep without becoming a full-time compliance officer. For the wider workplace AI caution stack, pair this post with the Practical AI series and the paths on Learn.

Three layers people mix up

When people say “Claude remembers,” they might mean any of three different things. Mixing these up leads to bad safety choices. You might trust too much, thinking “it’s private forever.” Or you under-use the tool, thinking “I can never save anything.”

1. Chat history

This is the thread list in the product: past conversations you can reopen, rename, or delete. If you paste a spreadsheet into a normal chat, that content becomes part of that conversation record. Deleting a chat removes it from your history right away. Anthropic’s privacy center describes a backend deletion within a stated window after you delete it. That’s commonly within 30 days for consumer products, with separate rules for safety flags, feedback, and training opt-in. Always check the current Privacy Center text for your product type. Consumer and commercial plans differ.

2. Memory

Memory is not a full transcript of every word you ever typed. In Anthropic’s own framing, memory stores useful context. Think of things like your preferences, project details, and work patterns. That way you do not have to re-explain everything in a new chat. On plans where memory is available, it is optional, and you can view and edit what is stored. Memory can also be project-scoped. That means each Project can keep its own separate memory space, so client A does not bleed into client B. That boundary is both a convenience and a safety feature. It does not replace the rule “do not paste regulated data.”

Anthropic calls its private-chat mode Incognito chats. These are built so a chat does not save to memory. It also does not sit in your normal history the way regular chats do. They are useful for one-off sensitive brainstorming, when the alternative would be cluttering up memory. But it is still a conversation with a vendor’s system. Incognito does not mean “this never existed anywhere.” It is a narrower way of keeping a record, not the absence of one. Read the current help article before you rely on it for a real policy decision.

3. Project files, and other uploaded material

Projects can hold files you upload for ongoing reference. Think style guides, public specs, made-up sample data, or a syllabus. Those files are context you added on purpose. Treat them like a shared drive folder attached to the model. If you would not leave a file in a vendor-hosted folder under your company’s rules, do not drop it in a Project either.

LayerWhat it roughly isYou control it byCommon mistake
Chat historyIndividual threads and their messagesDelete, rename, avoid pasting secretsAssuming “old chat” is gone from all systems instantly
MemorySummarized facts and preferences (where enabled)Settings, view/edit, project boundaries, incognitoThinking memory is a full secret diary of every paste
Project filesDocs you attach for reuseWhat you upload and removeUploading live customer or HR extracts “for convenience”

Product labels move around often. Your job is not to quote last year’s blog post from memory. Your job is to open the current screens. Read the privacy docs for the account you actually use today.

  • Memory on or off, and whether you can view or edit the stored memory summaries.
  • Project separation: one project per sensitive workstream, whenever memory is turned on.
  • Incognito, or private chat, availability for one-off work that should not feed memory at all.
  • Model improvement and training controls on consumer plans. Anthropic documents opt-in style controls for using chats to improve models on consumer products. Commercial products such as Claude for Work and the API have different defaults.
  • Org admin controls, if you are on Team or Enterprise. Owners and admins may have export or retention powers that you do not have on your own.

A few official pages are worth checking for your own plan. That includes Anthropic’s memory announcement, the Privacy Center’s retention article, the consumer-versus-commercial “is my data used for model training” articles, and the help pages on chat search, memory, and Incognito chats. Links sit in Sources below.

Rule of thumb: product privacy settings are necessary, but they are not enough on their own. Your employer’s policy, and how sensitive the data actually is, still decide whether the paste is allowed at all.

The paste ladder

Think in rungs, not vibes. If a paste fails a lower rung, stop there. Do not “anonymize it in your head” while three real Social Security numbers are still sitting in the CSV.

Never paste

These are hard stops for personal accounts, and for most work accounts too. You need a written, company-approved path, and even then, approved tools may still ban them outright:

  • Social Security numbers and national ID numbers.
  • Passwords, API keys, private keys, session cookies, or MFA (multi-factor authentication) backup codes.
  • Full payment card numbers, bank account and routing pairs, or crypto seed phrases.
  • Patient details that can identify a person, since health privacy rules are strict for a real reason.
  • Unreleased earnings, embargoed financials, or other secret company information you are not cleared to share outside controlled systems.

If you need help with a form that contains these fields, redact them first or use made-up placeholders instead. “Just this once” is exactly how keys end up sitting in logs.

High risk: usually no on personal tools

  • Customer lists with emails, phones, addresses, or account IDs.
  • Raw HR data: pay grids, performance notes, disciplinary files.
  • Legal strategy, privileged counsel email, or unreleased filings.
  • Security incident details that reveal systems nobody has patched yet.
  • Full production database dumps. Even “just a few tables” counts.

High-risk data usually needs a company-managed setup: contracts, retention rules, and sometimes a flat ban on consumer AI entirely. How helpful the model feels does not create permission on its own.

Use caution

  • Internal strategy drafts that are sensitive, but not legally privileged.
  • Combined metrics that could still identify a small team or customer.
  • Code that embeds internal hostnames, tokens in comments, or customer-specific logic.
  • Meeting notes with real names and performance commentary.

Caution means a few things: strip identifying details, prefer company-approved accounts, and avoid personal free-tier tools for work content. Ask whether a plain summary without raw rows would actually be enough.

Safer defaults

  • Public documentation and already-published numbers.
  • Made-up samples and toy tables you built for demos.
  • Your own non-sensitive notes and learning materials.
  • Open-source code with no secrets in it.
  • Plain process questions, like “how do I structure a decision brief?”

Safer is not risk-free, but it is the zone where most personal learning and a lot of drafting work should actually live. The earlier post’s four everyday jobs work fine here, as long as the inputs are public or made up.

RungExample pasteDefault action
NeverPassword list, SSN, card PAN, patient MRNStop. Redact or use approved vaults, not chat.
High riskFull CRM export, salary sheet, counsel strategy memoNo personal AI. Follow employer channel or do not use AI.
CautionInternal roadmap with names, semi-sensitive metricsStrip IDs, use approved plan, minimize, prefer summaries.
SaferPublic RFC, fake orders CSV, blog outlineReasonable for learning and drafting with normal care.

Employer policy beats model quality

A personal Claude or ChatGPT account can be excellent at summarizing. It can still be the wrong place for work data. Many companies ban consumer AI for anything non-public. Others allow only contracted enterprise versions with admin controls, single sign-on, and retention settings. Some industries add strict legal rules on top of all that.

Here is a practical sequence to use when you are unsure:

  1. Find the written AI or data handling policy, or ask security or legal once, in writing.
  2. If policy is silent, treat non-public work data as off-limits on personal tools until someone with real authority says otherwise.
  3. Prefer company-provided accounts whenever they exist.
  4. Never “make it anonymous” by renaming one column while leaving email addresses sitting in another.

This is the same spirit as data stewardship elsewhere on AMS. Who owns the data, and who can access it, matters more than which clever tool you use. See the Data stewardship series when your day job is pipelines and access, not just chatbots.

Worked scenarios

Scenario A: “Help me write a customer apology”

Bad paste: the full ticket, with name, email, order ID, address, and card last-four digits, plus a free-text rant that includes a medical detail.

Better approach: paste a redacted problem statement instead. For example: “Customer received a damaged item, wants a refund, tone should be apologetic and clear about next steps within 5 business days. Do not invent policy.” Keep the real personal details in your ticketing system only.

Scenario B: “Summarize this headcount file”

Bad paste: a spreadsheet of names, salaries, and manager ratings.

Better approach: if policy allows any AI use at all, use combined numbers you already have permission to share. For example: “12 people in data, 3 open reqs, two backfills.” Or do the summary inside an approved HR system instead. This one is high risk on a personal account.

Scenario C: “Plan a dashboard for revenue by channel”

Bad paste: a production extract with real customer_id values in it.

Better approach: made-up sample rows, public metric definitions, and the earlier post’s planning prompt. When you actually need real validation, run queries in the warehouse under normal access controls, not in the chat window.

Scenario D: “Debug this config”

Bad paste: an .env file with live keys still in it.

Better approach: paste the structure with placeholders instead, such as API_KEY=REDACTED, describe the error messages, and share the non-secret config only. Rotate any key that ever hit a chat, even “by accident.”

# Safe pattern for asking about config shape
# (values are fake on purpose)

DATABASE_URL=postgres://USER:REDACTED@host:5432/app
FEATURE_FLAGS=true
LOG_LEVEL=info

# Question: connection fails with timeout after deploy.
# We use a private VPC. What checklist should I run?
# Do not ask me for the real password.

Review and delete habits that actually get done

Privacy is mostly hygiene. A big one-time cleanup helps, but small weekly habits help even more.

  • Before you paste: climb the ladder first. If it lands on never or high risk, stop right there.
  • After sensitive-ish work: delete the chat if you did not need a long-lived record of it. Deletion is not instant everywhere behind the scenes, but it removes your own ongoing access, and it’s still worth doing.
  • Monthly memory review: open what memory stores, where that’s available. Remove stale projects, wrong preferences, or anything you would not want carried into new chats.
  • Project file audit: remove old uploads you no longer need. A stale file is a forgotten risk.
  • Separate projects: one client or initiative per Project when you use memory, so the boundaries actually match reality.
  • Incognito for experiments: use Incognito if your plan offers it, for help that should not feed memory. Still follow the paste ladder anyway.
  • Shared machine caution: log out on shared devices, and do not leave threads with internal content sitting on a borrowed laptop.
  • Key rotation rule: if a secret was pasted anywhere, rotate it. Do not debate whether “the vendor is probably safe enough.”

A simple personal checklist

WhenActionDone?
Before any work pasteConfirm employer policy allows it
Before pasteRun paste ladder; redact
WeeklyDelete threads you no longer need
MonthlyReview memory summary + project files
After any secret accidentRotate credentials; notify security if required

Consumer versus work accounts, in plain language

Anthropic documents different defaults for consumer products, meaning Free, Pro, Max, and coding sessions under those accounts, versus commercial products such as Claude for Work and the API. The commercial docs generally state that inputs and outputs are not used to train models by default. A few exceptions exist, such as feedback you choose to send in. The consumer docs describe choices around model improvement and retention. Read those directly in the Privacy Center, because the controls and time windows are specific, and they do change.

None of that turns a personal Free or Pro account into an approved processor for your employer’s customer database. Contracts, data processing agreements, admin controls, and internal policy are the work layer. Model quality is a completely separate question.

Common mistakes

  • Equating encryption in transit with “I can paste anything.” Transport security is a baseline, not authorization.
  • Trusting “anonymous” files that still identify people. A small team plus one rare detail is often enough to identify someone.
  • Leaving live keys in screenshots. Images are uploads too.
  • Turning memory on for everything, then pasting client secrets into a general chat. Use project boundaries, or do not paste it at all.
  • Assuming Incognito means zero vendor processing. It changes how long something is kept; it does not rewrite the paste ladder.
  • Ignoring org admin reality. On team plans, owners may be able to access or export data under org rules.
  • Using personal AI for work because the enterprise waitlist is long. Inconvenience is not a policy exception.

How this connects to the rest of the series

The earlier post taught you to get better drafts. This one teaches you which drafts are actually allowed. Later posts cover work connectors and when Claude is the wrong tool for the job. Across AMS, the Practical AI series digs into workplace patterns: verification, realistic use, and not confusing demo polish with production safety. If models still feel fuzzy at the vocabulary level, read What are LLMs, ChatGPT, generative AI, and more. When AI writes SQL against real warehouses, keep How to check AI-written SQL in the loop too. That way privacy mistakes do not pair up with logic mistakes.

Practice drill, about 30 minutes

  1. Open your Claude settings. Note whether memory is on, whether you can view or edit it, and whether Incognito is available on your plan.
  2. Skim the current Privacy Center articles on retention and training for your product type, consumer or commercial.
  3. List three pastes you have made in any AI tool over the last month. Place each one on the paste ladder. If any land on never or high risk, delete the related threads if they still exist, and rotate any secrets if needed.
  4. Create or clean up a Project that only holds safer materials: public docs, made-up data, and personal learning notes.
  5. Write your own two-sentence rule for work: “I will not paste ___ into personal tools. For work data I will ___.” Keep it somewhere you will actually see it again.

Quick recap

  • History, memory, and project files are different layers, with different controls on each.
  • Memory can be project-scoped and editable where it’s offered; Incognito limits what saves to memory and history.
  • Never paste SSNs, passwords, cards, patient identifiers, or unreleased earnings material.
  • Treat customer lists, raw HR data, and legal strategy as high risk for personal tools.
  • Prefer public docs, made-up samples, and published numbers for learning and most drafting.
  • Employer policy can ban personal AI for work data even when the model itself is strong.
  • Review memory, prune projects, delete chats you no longer need, and rotate anything that leaked.

Series notes

This post continues Learn Claude from scratch. Next up is Claude for work and lighter Microsoft 365-style use, still with these same privacy rails in mind.

Sources

Written by

Jose S

Founder & Lead Analyst · Analytics Made Simple

Hands-on data strategist, analytics engineering lead, and educator. Writing practical, no-fluff guides to help everyday teams, analysts, and engineers master SQL, AI systems, and modern data architectures.

Keep going

Same lessons in your feed

Short diagrams, hooks, and weekly tutorials on Substack, Instagram, X, and Facebook.

Google Search Prefer our practical guides in Google Search & Top Stories: