Keep Secrets Out of AI Agents: I Audited My Own Rig

There are 25 credentials in the .env file on this machine, and an agent runs unattended against it ten times a day. Cloudflare and Supabase tokens, a Telegram bot token, an OpenAI key, a Reddit password. I had never measured which of them the agent actually holds while it works, so on 2026-07-30 I audited the whole surface: what the process inherits, what a child process can read, how much each script needs, and whether any of it has already reached the public web.

Four of the five answers were better than I expected. The one that was worse had nothing to do with credentials.

The agent process holds none of them

The scheduler launches the writer at line 28 of its runner script:

# ops/schedule/daily-content.sh
claude -p "$(cat ops/schedule/daily-content-prompt.md)" \
  --permission-mode acceptEdits ...

That script never sources .env. So I checked the running agent's own environment against the 25 names:

of 25 .env names, present in this agent's inherited env: 0
present: []

Zero. The agent is not carrying a wallet around. What it does instead is source the file per command — the prompt that drives it says source .env && curl … in half a dozen places. Credentials enter one subshell at a time and leave when it exits.

That distinction is the whole geometry of the problem, so it is worth drawing:

The file permission protects the file, not the children

.env is mode -rw-------, listed at line 3 of .gitignore, and git log --all -- .env returns nothing, so it has never been committed. All of that is real protection, and all of it stops the moment the file is read. I started a sleeping Python process from a shell that had sourced the file, then looked at it from outside:

$ ps eww -p $PID | tr ' ' '\n' | grep -cE '^(CLOUDFLARE_API_TOKEN|SUPABASE_SERVICE_ROLE_KEY|OPENAI_API_KEY|TELEGRAM_BOT_TOKEN|REDDIT_PASSWORD)='
5
$ ps eww -p $PID | grep -c "$CLOUDFLARE_API_TOKEN"
1

The Cloudflare token appears in that output as plaintext. Same-user processes can read each other's environment on macOS, and an agent runs everything as me, so there is no narrower identity to fall back to. A child process that needed one variable got 25 and published them to anything that can call ps. This is the same class of question as what a launchd plist actually hands a job — inheritance is the mechanism in both cases, and the answer is never the one in your head.

Sixteen scripts, and the median one needs two

If everything downstream gets all 25, the useful number is how many each script genuinely reads. I matched every variable name against every shell, Python, and JavaScript file under ops/:

Script	Variables read	Variables granted
ops/growth/social/threads.py	6	25
ops/deploy-site.sh	4	25
ops/analytics/snapshot.py	3	25
ops/schedule/daily-report.sh	3	25
eight more (build-site.py, notify.sh, …)	2 each	25
ops/make-product-cover.py, reddit-comment.sh, two others	1 each	25

Sixteen scripts touch credentials at all. The median needs two of 25, the hungriest six, the narrowest four one apiece. The script that posts a Telegram message is handed the Supabase service-role key and the Reddit password because they happen to live in the same file. Nothing has gone wrong because of that. The reason nothing has gone wrong is that no step in the chain has misbehaved yet, which is not a control.

My leak scanner found five secrets and was wrong five times

Next I took every .env value of 16 characters or more and searched for it verbatim across 176 git-tracked files and the 41 files in the built site. Five hits. Every one of them is supposed to be public:

Value	Found in	Verdict
SUPABASE_URL	27 places on the live blog index	Public by design
SUPABASE_PROJECT_REF	Rendered HTML	Public by design
INDEXNOW_KEY	picklog.cc/<key>.txt, HTTP 200	Public by protocol
BSKY_IDENTIFIER	ops/accounts.md	Public handle
THREADS_USER_ID	ops/accounts.md	Public account ID
SUPABASE_SERVICE_ROLE_KEY	nowhere	The one that would matter

Supabase is explicit that the publishable key is "safe to expose online: web page, mobile or desktop app, GitHub actions, CLIs, source code" while the secret key must never be; I tested that boundary with a blocked DELETE when the site moved to Supabase. The IndexNow entry is the sharper case. It is named like a secret and sits in the file beside real ones, but the protocol requires the key file to be fetchable at your host so search engines can verify it, while the same page still says "only you and the search engines should know the key."

So the honest finding is not that my repo is clean. It is that .env is a configuration file with credentials mixed into it, and no scanner reading that file can tell a service-role key from a public account handle. Five false positives is the number that trains you to stop reading the report, which is how the sixth one gets through. GitGuardian counted 28.65 million new hardcoded secrets pushed to public GitHub in 2025, up 34 percent, with AI-assisted commits leaking at roughly twice the baseline rate. Volume like that is not solved by better grep.

What actually leaked here was not a credential

The one real exposure on this rig involved no keys. On 2026-07-27 my deploy published ops/site/.omc/ — my own agent's state directory — to picklog.cc, exposing local absolute paths, session IDs, and session names. No credentials were in it. I found it only by deploying a canary file that should have been excluded and fetching a 200, and the fix was learning which files wrangler pages deploy will and will not skip. A credential vault would not have caught it, because the leaking artifact was not a credential. The agent's working state was.

Why the emerging fix does not fit this shape

The current answer in this space is the credential gateway: the agent sees a placeholder, a proxy swaps in the real key at the network layer, and a compromised agent has nothing worth stealing. A Show HN for one such tool drew 110 points, and the comments are more useful than the pitch. mjg59 pushed back on the claim that OIDC already covers this: "you're still giving the agent a static token that can be exfiltrated and used elsewhere," with refresh tokens often valid for a week. The tool's own author conceded the ceiling: "not holding the secrets doesn't make the agent harmless. It still acts autonomously, and it can use whatever access those credentials grant."

That is exactly my situation. My agent holds zero credentials at rest and can still run source .env whenever it decides to, because I gave it a shell. The process environment was never the boundary — what the agent is permitted to execute is, and that boundary is leakier than it looks. The Register reported in January that Claude Code v2.1.12 read and printed a .env despite a .claudeignore entry, after the model itself had claimed the ignore file would stop it. Anthropic did not comment.

What this changes, and what it has not yet

As of publishing I have changed nothing in the scripts. This was an audit, and reporting it before the remediation is the honest order. Two changes follow from the numbers, both cheap and neither of them a vault. Stop sourcing the whole file where two variables will do: a script that reads TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID can pull exactly those and leave the other 23 out of its environment. And keep the audit as a script rather than an afternoon, because the number worth watching is not "is it clean today" but "did the count of scripts holding all 25 go up this week." The guardrails that keep Claude Code running unattended on a schedule all have that shape: mechanical, re-runnable, and worth more than a policy I would write down and never enforce.

What I am not planning is a broker. With one machine, one operator, and 25 credentials, a gateway adds a component that also holds every key, and I have no evidence yet that it fails less often than the file does. That changes the moment a second machine or a second person appears.

FAQ

Does a coding agent read my .env file?

It can, and ignore files may not stop it. The Register tested Claude Code v2.1.12 in January 2026 and found it read and printed a .env that was listed in .claudeignore, and that entries in .gitignore did not prevent it either. Permission rules in .claude/settings.json are the mechanism that actually applies.

Is chmod 600 .env enough to keep secrets out of an agent?

No. Mode 0600 stops other user accounts from reading the file. Once a shell sources it, every child process inherits all the variables and any same-user process can read them from ps eww in plaintext. I confirmed this on 2026-07-30: a child of a sourcing shell saw all 25 variables, and the Cloudflare API token appeared verbatim in ps output.

Which keys in a .env file are safe to expose?

More than people assume, and the file itself gives you no way to tell. In my 25-variable file, the Supabase project URL and anon key are documented as safe to expose, the IndexNow key must be served at a public URL for the protocol to work, and two social identifiers are public handles. Only the service-role key, the API tokens, and the account password are genuinely secret. Sort them before you scan, or your scanner will cry wolf.

Every measurement here was taken on this machine on 2026-07-30 (Mac16,10/M4, macOS 26.4.1): the 25-variable inventory and its 0600 mode, the empty git log --all -- .env, the agent's zero-of-25 inherited environment, the 25-of-25 seen by a child of a sourcing shell, the ps eww plaintext match, the per-script counts across every file under ops/, and the five-hit scan over 176 tracked files. The public checks were made against the live site: the IndexNow key file returned 200, the project ref appears 27 times on the blog index, and the service-role key appears zero times. No credential values are printed in this post — only names, lengths, and counts. External claims are linked to their sources: the Supabase and IndexNow rules to vendor documentation, the leak volumes to GitGuardian's 2026 report, the .claudeignore finding to The Register, and the gateway objections to the Hacker News thread, where I quote commenters rather than paraphrasing them.