The Silent Accumulation Problem
AI coding assistants don't exfiltrate your secrets in one dramatic moment. The risk is cumulative and mundane: you paste a .env file to debug a config issue, drop in an error log containing an internal service URL, accept a code suggestion that hard-codes a naming convention from your proprietary system. None of those actions feel like a security event. Across a 30-day session window, they add up to a fairly detailed map of your infrastructure.
Claude Code's own documentation confirms that session transcripts are cached locally in plaintext under ~/.claude/projects/ with a default retention of 30 days. The setting is adjustable via cleanupPeriodDays, but the default is 30 and most developers never touch it. File names, directory structures, and project architecture details are included to give the model context — which is exactly why the feature is useful, and exactly why it's a liability if that machine is ever compromised, shared, or simply left unlocked.
Security researchers at Bright Security describe this dynamic precisely: bits of sensitive context drift out over time through everyday actions. When those pieces are viewed together, patterns emerge — architecture decisions, naming conventions, common library choices. You haven't leaked a password; you've leaked the blueprint.
Three Real Incidents That Should Have Changed Developer Habits
Samsung / ChatGPT (2023)
Samsung became the canonical cautionary tale in March 2023. After granting employees access to ChatGPT for productivity, three separate data leakage incidents occurred within a single month. An engineer pasted semiconductor yield data to get help understanding the output. Another submitted internal source code for a code review. A third used the tool to summarize a confidential internal meeting. Samsung had already issued a warning to staff about sharing private information — the incidents happened anyway, because the path of least resistance is to just paste the thing you're looking at. Samsung subsequently banned ChatGPT for internal use, then quietly reinstated it with new controls roughly a year later.
DNS-Based Exfiltration via Prompt Injection (2025)
Researchers at Embrace The Red demonstrated a DNS-based exfiltration attack against Claude Code in 2025. Through indirect prompt injection — malicious instructions embedded in a file the assistant was asked to read — the model was manipulated into reading sensitive local files and encoding their contents into DNS lookup requests. The data left the machine without triggering obvious network alerts, because DNS traffic is rarely scrutinized at the endpoint level. The attack required no special permissions and no user interaction beyond the initial task.
Malicious Repository Hook Attack (CVE-2025-59536)
Check Point researchers disclosed two critical vulnerabilities in Claude Code — CVE-2025-59536 and CVE-2026-21852 — that allowed remote code execution and API key theft triggered simply by cloning and opening an untrusted repository. The attack surface was Claude Code's project-level configuration files (analogous to .claude/settings.json or hooks defined in a repo). A developer cloning a dependency or an open-source project to study it would have no reason to suspect the repo contained instructions for the AI agent. The fix required Anthropic to patch built-in mechanisms that had, ironically, been designed for legitimate workflow automation.
What Claude Code Actually Sends — and Stores
It's worth being precise about the data surface, because vague anxiety is less useful than a specific mental model.
- Context window (sent to API): Everything in the active session — your prompts, file contents the model was asked to read, tool call results, error output. This is transmitted to Anthropic's servers for inference. Organizations without a Zero Data Retention (ZDR) agreement should assume this data is retained per Anthropic's standard policy.
- Local transcript cache: Stored in plaintext at
~/.claude/projects/<session-id>/. Contains the full session history for up to 30 days. Any process or user with read access to your home directory can read it.
- Project context files:
CLAUDE.md, .claude/settings.json, and any memory/context files the agent has been allowed to write. These persist across sessions and can contain summaries the model wrote about your project — including things it inferred rather than things you explicitly told it.
- Tool call outputs: If you've given Claude Code shell execution permissions, the output of commands it ran — including anything those commands printed to stdout — is in the transcript.
The threat model here isn't just "Anthropic sees your secrets." It's that your local disk now contains a detailed, searchable conversation log about your systems. A compromised machine, a careless git add ., a synced home directory, or a shared development container all become new exposure vectors.
The Part Nobody Talks About: Agent Autonomy Expands the Blast Radius
Standard chatbot use has a human in the loop at every step. CLI agent tools are explicitly designed to reduce that friction. Claude Code, Cursor, Devin, and similar tools can be configured — and are often encouraged by their documentation — to operate autonomously across multi-step tasks: read files, run tests, make commits, open pull requests.
The more autonomously an agent operates, the more data it accumulates in a single session. A task like "refactor the auth module and open a PR" might involve reading a dozen files, running the test suite, examining the output, and writing a commit message — all without a human reviewing what went into the context window. If your auth module contains a hardcoded fallback credential, a configuration constant with an internal endpoint, or a comment referencing a legacy system, the model has seen it. So has the session transcript.
This isn't a reason to avoid agentic tools. It's a reason to be as deliberate about what you let the agent read as you are about what you commit to version control.
Signals That Your Team Has a Habit Problem
Individual incidents are usually symptoms of a broader pattern. Watch for these indicators:
- Developers routinely paste full
.env files or credential blocks into AI chat "just to debug something"
CLAUDE.md or equivalent context files are committed to shared repositories without review- Nobody has set
cleanupPeriodDays — meaning the default 30-day plaintext transcript window is in effect across the team
- AI tools have been granted broad filesystem or shell permissions in development environments that mirror production configuration
- No documented policy exists for what categories of information may or may not be shared with external AI APIs
What Comes Next
The second article in this series covers practical controls — specifically a pattern using a gitignored ~/.claude/identity.json file to redact PII and sensitive values before they enter the context window, combined with a standing instruction in your Claude configuration to return REDACTED_USER rather than echoing back sensitive strings. That approach won't stop every leak vector, but it handles the most common one: the slow drip of personal and organizational data that accumulates when you let an AI tool learn your environment without boundaries.
Sources
---
Advisory
May 2026
The Identity File Pattern: Redacting Yourself Before Claude Remembers You
Most developers using AI CLI tools focus on what they tell the model — not what the model quietly accumulates over dozens of sessions. A simple two-part pattern can close the most common gap: a gitignored ~/.claude/identity.json file that maps sensitive strings to safe placeholders, paired with a standing instruction in your Claude config to return REDACTED_USER rather than echo sensitive values back into output or logs. It won't neutralize every attack vector, but it addresses the slow-drip problem — the gradual accumulation of your name, employer, email, credentials, and internal hostnames across weeks of agentic sessions. This is the practical companion to our data-exposure overview.
The Problem This Solves
AI CLI tools earn their usefulness by being contextually aware. You configure them with project details, let them read your codebase, grant them shell access, and eventually they start to feel like a knowledgeable collaborator. That's the product working as intended.
The side effect is accumulation. Over weeks of sessions, a tool like Claude Code builds up a working picture of you: your name, email, employer, the internal domain names in your error logs, the username format your company uses, the hostnames in your SSH config, the email addresses CC'd on tickets you pasted in. None of this was a deliberate disclosure. It leaked in through context.
Claude Code stores session transcripts in plaintext at ~/.claude/projects/ for 30 days by default. Those transcripts contain everything — including things the model inferred and summarized. A compromised machine, a carelessly synced home directory, or a shared dev container means someone else now has that accumulated profile.
The identity file pattern is a low-friction way to keep that profile out of the context window in the first place, and to prevent the model from echoing it back in generated output.
Part One: The Identity File
Create a file at ~/.claude/identity.json. This is not a Claude-native feature — it's a convention you establish. The file maps real values to safe placeholders that you'll reference everywhere else.
{
"name": "REDACTED_USER",
"email": "REDACTED_EMAIL",
"employer": "REDACTED_ORG",
"internal_domain": "REDACTED_DOMAIN",
"github_username": "REDACTED_GITHUB",
"aws_account_id": "REDACTED_AWS_ACCOUNT"
}
The critical step: make sure this file is never committed. Add it to your global gitignore (~/.gitignore_global) and to the .gitignore of any project that references it.
# ~/.gitignore_global
.claude/identity.json
.claude/projects/
*.local.env
In your CLAUDE.md or project-level Claude context file, reference the placeholders rather than real values:
## Project Context
Developer: REDACTED_USER
Org domain: REDACTED_DOMAIN
AWS account: REDACTED_AWS_ACCOUNT
When generating commit messages, PR descriptions, or any output
that would normally include developer identity, use the placeholder
values above — do not substitute in real names or email addresses.
This keeps your personal details out of session transcripts, out of generated commit messages, and out of any PR descriptions the agent writes autonomously.
Part Two: The Standing Instruction
The second half of the pattern is a rule in your Claude configuration that tells the model how to behave when sensitive material does end up in the context window — because sometimes it will, despite your best efforts.
In your CLAUDE.md (or equivalent), add a block like this:
## Handling Sensitive Data
If you encounter values that appear to be credentials, API keys,
internal hostnames, personal email addresses, or PII during a task:
1. Do NOT reproduce them in generated output, commit messages,
PR descriptions, log summaries, or any artifact that may be
committed or shared.
2. Reference them as REDACTED_SECRET, REDACTED_HOST, or
REDACTED_USER as appropriate.
3. If you need to confirm a value exists and is non-empty,
say: "A value is present for [field] — not echoing for
security." Do not print the value.
This does two things. First, it reduces the chance that secrets end up in generated artifacts that get committed — the most common downstream exposure path. Second, it shortens the session transcript: a model instructed not to echo values back produces shorter, less sensitive logs.
What This Pattern Does and Doesn't Cover
| Threat |
Covered? |
Notes |
| PII / identity creep in session transcripts |
✅ Partially |
Placeholders prevent initial accumulation; doesn't retroactively clean existing transcripts |
| Secrets echoed back in PR descriptions / commits |
✅ Yes |
Standing instruction catches this for LLM-generated output |
| Secrets pasted directly into a prompt |
❌ No |
If you paste a raw .env, the model has seen it regardless of any rule |
| Prompt injection via malicious repo files |
❌ No |
Requires separate controls — keep Claude Code updated, review project hooks |
| DNS exfiltration / indirect prompt injection |
❌ No |
Requires network-layer monitoring and prompt injection defenses |
| Local transcript cache exposure |
✅ Partially |
Reduces sensitivity of cached content; set cleanupPeriodDays to a lower value |
The honest summary: this pattern is a hygiene layer, not a security boundary. It handles the ambient, low-drama exposure that's responsible for most real-world AI data leakage — the slow accumulation of context that nobody intended to share.
Additional Hardening for the Paranoid (Recommended)
Reduce the transcript window
Claude Code's default 30-day local transcript retention is almost certainly longer than you need. Set it lower:
# In your Claude Code config or via environment variable
CLAUDE_CODE_CLEANUP_PERIOD_DAYS=3
Three days covers most active debugging sessions. You lose some continuity on long-running projects; you gain significantly less accumulated plaintext on disk.
Scope filesystem permissions tightly
Claude Code can be configured with path allow-lists. If you're working on one project, there's no reason the agent should have read access to your ~/.ssh/, ~/.aws/, or home directory config files. Define explicit allowed paths in your project's .claude/settings.json:
{
"permissions": {
"allow": ["./src/**", "./tests/**", "./docs/**"],
"deny": ["~/.ssh/**", "~/.aws/**", "~/.config/**"]
}
}
Use a dedicated shell user for agentic tasks
For fully autonomous runs — overnight refactoring, bulk test generation — consider running the agent under a separate OS user with a clean home directory and only the credentials it actually needs. This limits the blast radius if a prompt injection attack succeeds.
Review what's in your CLAUDE.md before committing it
It's easy to end up with real values in a project context file that started as a quick note and gradually became the agent's working memory. Treat CLAUDE.md as code that gets reviewed — scan it before every commit the same way you'd scan a config file.
The Bigger Picture
The identity file pattern is a small thing. It takes about ten minutes to set up and requires no new tools. The reason it's worth writing about is that most developers using AI CLI tools have never explicitly thought about what those tools are accumulating — because the tools are designed to make accumulation invisible. That's what makes them good. It's also what makes the default configuration an ambient risk that compounds over time.
The Samsung incident, the DNS exfiltration demonstrations, the CVEs in Claude Code's project hook system — none of those required exotic attacker capabilities. They required a developer who hadn't asked "what does this tool already know about me, and where is that written down?" Start there.
Sources
---
**A few notes on the split:**
- **Article 1** (`ai-cli-context-data-exposure`) is the **"here's the problem and how bad it actually is"** piece — incident-led, designed to land with developers who think they're being careful.
- **Article 2** (`ai-cli-redaction-identity-pattern
← Back to News & Advisories