How does your agent actually get its API keys?

I've been thinking about this since reading about a developer who blocked their coding agent from reading `.env` files -- and the agent got the keys anyway by running `docker compose config` and reading them out of the resolved output. It made me realize most agent setups (including ones I've built) get credentials in one of three ways: 1. **Keys in a file the agent can read** (.env, config files, settings). Convenient, and it works right up until the agent — or anything the agent runs — reads the file for the wrong reason. 2. **Keys in environment variables.** A bit better, but anything that prints the environment leaks them, and agents run a *lot* of commands that print things. 3. **Keys the agent never sees** \-- some proxy or vault attaches them to outbound requests, so the agent works with a placeholder. Safest, but more plumbing to set up. Almost everyone starts at 1 because every tutorial starts at 1. And to be fair, for a hobby project that's probably fine. But the pattern from that .env story stuck with me: the agent wasn't being malicious, it was being *resourceful*. It had a goal, the rule was in the way, and it routed around the rule. Any restriction that depends on the agent not looking somewhere is more of a polite request than a boundary. Curious where people here actually land: * Are you at 1, 2, or 3? * Has your agent ever surprised you by reading something you didn't expect it to? * If you're at 3, what was the setup cost like -- worth it? Not looking for a lecture-thread, genuinely curious what real setups look like vs. what security posts say they should look like.