Keeping Secrets and Production Data Out of Coding Agent Prompts
Published August 21, 2026 · by the AQ team
When an AI coding agent runs, everything it puts into its context window (your instructions, the contents of every file it reads, and the output of every command it executes) is sent to the model provider as part of the prompt. If the agent reads a .env file or greps a log that contains a customer's email address, that material leaves your machine. The reliable defense is layered: keep secrets off the disk the agent works on, add the agent's own deny rules and sandboxes as a second line, keep production data out of the loop, and scan for what slips through. Pattern-based blocking alone is not enough: an agent has more than one way to read a file.
What actually leaves the machine
Coding agents like Claude Code and Codex CLI execute locally, but the reasoning happens at a hosted API. Anthropic's documentation is explicit that Claude Code sends all user prompts and model outputs over TLS, as of August 2026. In practice the prompt is much bigger than what you type: it accumulates the file contents the agent reads, directory listings, test output, and shell results: that is how the model sees your codebase at all.
Three consequences:
- Reads are sends. Any file the agent opens becomes model input. A database URL in a config file, real values in a committed .env.example, or personal data in a fixture all travel with the session.
- Command output counts too. An agent that runs printenv, cats a credentials file while debugging, or tails a production log has put that output into the prompt without ever using a read tool.
- Telemetry is usually separate. Anthropic states that Claude Code's operational metrics never include code, prompts, or file paths, as of August 2026. The sensitive channel is the conversation itself, not the analytics.
Where the copies go: retention, training, and transcripts
The realistic risk is rarely a provider misusing your key. It is the number of places a copy of the conversation can end up, each with its own lifetime.
For Claude Code, as of August 2026: consumer accounts (Free, Pro, and Max) choose whether sessions can be used to train future models, with retention of five years when that setting is on and 30 days when it is off. Commercial accounts (Team, Enterprise, and API) are not trained on by default and carry a 30-day standard retention, with zero-data-retention available to qualified enterprise accounts. Transcripts shared through the /feedback, /bug, or /share commands are retained for five years regardless. Locally, Claude Code keeps session transcripts in plaintext under ~/.claude/projects/ for 30 days by default, so a secret that entered a session also sits on disk afterward.
OpenAI's published policies draw a similar line, as of August 2026: consumer ChatGPT and Codex content may be used for training unless you opt out, while business products and the API are not trained on by default. The pattern to internalize is that account type, not tool choice, usually decides your data terms. Run work agents under work accounts.
Layer 1: keep secrets off the agent's disk
The strongest control is the boring one: a secret the agent's environment never holds cannot end up in a prompt. Concretely:
- Fetch secrets at runtime instead of storing them in the repo. A secret manager (AWS Secrets Manager, Vault, Doppler, 1Password CLI) injects credentials into the process that needs them, so no .env file with production values sits in the working tree.
- Scope what remains. Where the agent's environment does need credentials (a GitHub token to push, a test database URL), make them short-lived and least-privilege: a token scoped to one repo, a database user that can read only non-production data.
- Separate dev values from real values. A .env full of localhost URLs and dummy keys is harmless in a prompt. Keep it that way by policy: production values live in the deployment platform's secret store, never in files a development checkout can reach.
Layer 2: deny rules, hooks, and sandboxes in the agent
The agents ship real controls, worth using while understanding what they gate. Claude Code supports deny rules in settings.json that block its file tools from reading matched paths:
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)"
]
}
}Claude Code also supports hooks that run before a tool call and can block or rewrite it, which teams use to redact known secret patterns before file contents reach the context. Codex CLI approaches the same problem from the sandbox side: as of August 2026, OpenAI documents a default sandbox where writes are limited to the workspace and network access is off unless explicitly enabled, plus approval policies that control when the agent must stop and ask.
The honest caveat: these are pattern and path gates, and an agent has many paths to a file's contents. A deny rule on a read tool does not by itself stop a shell command from printing the same file, and a redaction hook only sees the tool calls it intercepts. Treat agent-level rules as a valuable second layer that catches accidents, not as the boundary that makes secrets on disk safe. The boundary is layer 1.
Layer 3: keep production data out of the loop
Secrets are half the problem. The other half is production data: the customer records, tokens, and personal information that show up when an agent debugs against real systems. An agent that queries a production database to reproduce a bug pastes rows into its context; one that reads production logs reads whatever your users typed.
- Give agents sandbox datasets. A seeded or synthetic database that mirrors the production schema lets the agent write and test real queries with nothing sensitive in the rows.
- Keep production credentials out of development environments entirely. If the agent's environment cannot connect to production, the failure mode disappears rather than needing to be caught.
- Scrub what you paste. The human is an egress path too: a stack trace or log excerpt pasted into a prompt should be redacted as you would before posting to a public issue tracker.
Layer 4: catch what slips through
Assume something eventually gets past the first three layers, and instrument for it:
- Pre-commit scanning. Agent-written commits deserve the same gate as human ones. Tools like gitleaks and TruffleHog run as pre-commit hooks and block a commit containing a key before it becomes history, with push protection and CI scanning as the backstop.
- Review the session, not just the diff. The transcript records what the agent actually read and ran. Making transcripts easy to inspect is how you notice a session touched a file it should not have, the same practice that makes verifying agent work tractable.
- Rotate on exposure. If a real credential entered a session, rotate it. Retention windows mean a copy exists somewhere for a while; a rotated key makes the copy worthless.
| Egress path | What travels | Primary control |
|---|---|---|
| Files the agent reads | Full file contents into the prompt | No real secrets on disk; deny rules as backup |
| Commands the agent runs | stdout and stderr into the prompt | Scoped credentials, sandbox datasets |
| Provider retention | Session copies for days to years | Work accounts under commercial terms |
| Local transcripts | Plaintext session logs on disk | Cleanup settings, disk encryption, rotation |
| Agent commits | Secrets written into git history | Pre-commit scanning and push protection |
Where AQ fits
AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. AQ does not change what a CLI sends to its model provider, and you should not believe any harness that claims otherwise. What it changes is where the agent's environment lives and who can see what happens in it.
Agents in AQ run as real CLIs in persistent tmux sessions on your team's VM, in your own cloud or on a dedicated AQ-managed machine, with no shared multi-tenant execution tier. That makes layer 1 concrete: the disk the agent works on is a machine you provision, so what credentials exist there is a decision you make once, centrally, not once per laptop. Each workspace gets its own isolated git worktree, agents push with per-user GitHub auth, and everyone signs into the CLIs with their own Claude or OpenAI account, so the data terms that apply are the ones your organization already chose with those vendors (AQ never marks up model usage, and your own keys and accounts stay yours).
The visibility half matters just as much. Every session streams live to the browser, and teammates can open the same workspace and watch the same terminal, so what an agent read and ran is inspectable by the team rather than trapped on one person's machine. That turns transcript review from a forensic exercise into a normal working habit, which is the fourth layer operating continuously. For the broader custody picture, the security and isolation docs and the guide to running agents safely on your own repos cover the details.
Frequently asked questions
Does Claude Code send my .env file to the model provider?
If the agent reads it, yes: any file contents that enter the context window are sent as part of the prompt. As of August 2026, Claude Code supports deny rules (for example Read(./.env) in settings.json) that block its file tools from matched paths, and hooks that can redact content before it is read. Treat those as a safety net; the stronger fix is keeping real values out of the files a development checkout holds.
Is code sent by coding agents used to train models?
It depends on the account, not the tool, as of August 2026. Anthropic lets consumer accounts choose whether Claude Code sessions can be used for training, while commercial accounts are not trained on by default. OpenAI's published policy is similar: consumer content may be used for training unless you opt out, while business and API traffic is not trained on by default. The practical rule is to run work agents under work accounts.
Are deny rules and ignore files enough to protect secrets?
No. Deny rules gate specific tool calls against specific path patterns, but an agent can encounter the same content through other routes: a shell command that prints a file, command output that echoes an environment variable, or a log line that contains a token. Use deny rules as one layer, and put the real boundary earlier by never placing production secrets on the disk the agent works from.
Can I let a coding agent debug with production data?
Assume anything the agent queries or reads becomes model input under your provider's retention terms. The safer pattern is a sandbox dataset: a seeded or synthetic database with the production schema but harmless rows, so queries and fixes are real while the data is not. If a session genuinely requires production access, scope the credentials tightly, redact what you paste, and rotate anything sensitive that entered the transcript.
How do I find out what an agent actually read during a session?
The session transcript is the record: it shows every file read, every command run, and the output that came back. Claude Code stores transcripts locally under ~/.claude/projects/ (plaintext, 30 days by default as of August 2026), and a shared harness can make the same sessions reviewable by the whole team. Reviewing the session rather than only the diff is how you catch an agent touching files it should not have.