The one-sentence version
AI Agents put everything they "see" into the context window: files they have read, command outputs, and environment variables. As long as an API key or database password appears in these places even once, it might be repeated by the model, written into logs, sent to the model provider, or leaked via injection attacks. The principle is: Credentials should never appear anywhere the model can see. Let the system use the credentials on the Agent's behalf, rather than handing the credentials to the Agent itself.
This article has three layers:
- Layer 1: The Intuition: Don't write passwords on paper that will be photocopied
- Layer 2: Real-World Use: Common leakage paths
- Layer 3: Principles and Engineering details: Credential proxies, sanitization, log hygiene, and post-leakage response
Layer 1: The Intuition
1.1 Don't write passwords on paper that will be photocopied
Imagine the Agent's context window is a worksheet that will be repeatedly photocopied and circulated everywhere:
- Sent to the model provider for processing (one copy);
- Recorded in conversation history and logs (another copy);
- Possibly summarized, cited, or displayed in a UI (yet another copy);
- If subjected to injection, it might even be sent to an attacker (the worst copy).
You would never write a safe combination on such a piece of paper. But as soon as the Agent executes cat .env or printenv, the password is written down.
Layer 2: Real-World Use
| Leakage Path | How it happens |
|---|---|
| Reading configuration files | To understand a project, the Agent reads .env, config.yaml, or ~/.aws/credentials |
| Command output | Running printenv or env, or debugging scripts that print environment variables; connection strings included in error messages |
| Tool return results | A token is included in a response from a certain API |
| Writing to code | To make a test pass, the Agent hardcodes a secret into the source file and then commits it (see "Secret Scanning") |
| Logs and telemetry | Conversation history, debug logs, or error reports containing the context |
| Exfiltration via injection | An attacker tricks the Agent into sending environment variables to an external endpoint (see "Markdown Image Data Exfiltration") |
Community members frequently report AI coding tools displaying a user's API key verbatim in chat, or writing keys into commit histories. This is usually not "malicious"; the Agent is simply doing what it thinks is helpful.
Layer 3: Principles and Engineering
3.1 The best way: Credential Proxy
- The Agent's environment contains only a proxy address, no actual secrets;
- The proxy decides which credential to attach based on the target address, and only attaches credentials to allowlisted addresses;
- Even if the Agent is completely compromised, it cannot obtain the secret itself; it can only use it within the scope of the allowlist;
- The proxy can also log every usage and enforce rate limiting (see "Egress Control").
3.2 If you must put credentials in the environment
| Measure | Description |
|---|---|
| Short-lived, narrow scope | Expires after a few hours; can only access necessary resources (see "Agent Permission Design") |
| Files unreadable | Sensitive files (.env, cloud credentials, SSH private keys) are invisible in the sandbox or explicitly forbidden from being read by the Agent |
| Command filtering | Require confirmation for commands like printenv or cat .env |
| Output sanitization | Before command output enters the context, use regex to match known secret formats (sk-..., AKIA..., ghp_..., private key headers, etc.) and replace them with [REDACTED] |
| Dedicated test credentials | Use credentials from a test environment or sandbox account for the Agent; if leaked, there is no actual loss |
3.3 Log hygiene
- When recording tool calls, apply the same sanitization to parameters and results;
- Access permissions for logs should be stricter than for standard logs, and retention periods should be shorter;
- Error reporting services (such as crash collectors) should be configured with filtering rules to avoid uploading the full context.
3.4 Interception before commit
Since Agents can write and commit code, a Secret Scanning layer (see "Secret Scanning") must be added before the commit:
- Local pre-commit hooks;
- Push protection on code hosting platforms;
- Scanning in CI as the final line of defense.
3.5 After a leak
Once a secret is discovered in a conversation, log, or commit:
- Rotate immediately (revoke the old secret, generate a new one); this is the only reliable remedy. Deleting logs or commit history is insufficient, as copies may already exist elsewhere;
- Check the usage logs of that secret within the leakage window;
- Identify the leakage path and implement the corresponding protections.
Summary
| Layer | Key points |
|---|---|
| Intuition | The context window is a worksheet that will be repeatedly photocopied |
| Path | Reading config, command output, tool results, writing to code, logs, exfiltration via injection |
| Best Practice | Credential Proxy: The Agent can only use the secret, not obtain the secret itself |
| Remediation | Rotate immediately after a leak; deleting records is not enough |