Why Your Secrets Are Leaking

When an AI can read your local files, old security rules fail. I never leaked a key to the public internet. But I still leaked one.

The Insight

Here is what happened last week. I did not push any secrets to GitHub. But I kept world-readable .env files and temporary .env.save files on my machine. Before AI, this was just messy. Now, it is a real danger.

When an AI agent sweeps a workspace to fix a bug, it reads those files. Suddenly, admin tokens and API keys sit inside a chat log. They get sent to an LLM provider’s servers. The threat was not the internet. The threat was the AI. And it gets worse. It does not just read .env files. If I paste a password into the terminal, the AI reads my ~/.zsh_history and grabs it anyway.

If the AI reads a key, it is no longer my key. It belongs to the LLM now. I had to rotate my keys right away.

The Fix

To run AI agents safely, I had to change how I store credentials. Here is the new architecture. It breaks down by what worked, what broke, and what it cost to fix it:

1. The macOS Keychain: For sensitive keys, I killed .env files completely. Secrets now live inside the OS Keychain. They are pulled only when the script runs. The AI can run the script, but it cannot read the static file. To get the key into the Keychain safely, I use read -s. This keeps the secret out of the shell history.
2. Project-Scoped Configs: For low-risk variables, I dropped the central ~/.secrets vault. Everything is project-scoped. Now, an AI working on Project A cannot pull data from Project B. But these scoped files are only for non-secret settings. If a value can cause financial damage, it goes in the Keychain. Period.

The Hard Truth

Security used to be about keeping bad actors out of my machine. Now, it is about limiting what my co-pilot can see while it helps me work. Security is not what the model promises. It is what we can prove with a terminal command.