Five distinct ways an LLM in your dev loop puts secrets at risk. Knowing the vectors is half the defense.
1. Direct file read
The agent has a Read tool. You ask "what does my deployment look like?". The agent reads docker-compose.yml + .env for context. The .env contents are now in the model's context window, which means they're in the API request, which means they're on a server outside your control.
2. The helpful echo
You paste a stack trace. The trace includes a connection string with embedded password. The model summarizes the error: "Postgres at postgres://app:HUNTER2@db.internal:5432/prod is rejecting the connection". Now your password is in the chat transcript.
3. Reasoning-trace leak
Modern reasoning models (o-series, Claude thinking, DeepSeek R1, Gemini Thinking, etc.) often produce a thinking block. That block is shown to the user, sometimes hidden, sometimes logged separately. Many products send the trace upstream for billing/QA. If the model thinks "I should NOT reveal that the password is HUNTER2", that exact string is now in the trace.
4. Suggested code that hardcodes
You ask for "a script that connects to the database". The model, helpfully, fills in the password it just saw in your context. You accept the suggestion. Now the secret lives in committed code, on disk, and (because git history is forever) in your repo's permanent record.
5. Cross-conversation bleed (memory features)
"Memory" features in modern assistants persist facts across sessions. If session A learns your API key (from a .env read), session B can sometimes recall it.
| Vector | Where the secret ends up | Hardest part to clean up |
|---|---|---|
| Direct file read | API request, provider logs, possibly training data | You can never fully prove deletion |
| Helpful echo | Chat transcript, screenshots, shares | Distribution is uncontrollable |
| Reasoning trace | Trace logs, billing systems | Often invisible to the user |
| Hardcoded in suggestion | Your repo, git history, deploy artifacts | Git history rewrites are painful and partial |
| Memory bleed | Provider's persistent memory store | Hard to audit, hard to purge selectively |