[_pdp_]

> Secret Management via .gitignore

> Agent tools that need API keys or credentials read from a local .env file — kept out of version control via .gitignore. Agent config is shareable, secrets stay local.

Amazing! Welcome to 2026, where the only thing standing between your plaintext secrets and the rest of the world is a .gitignore rule.

This is hope-based security.

[danielbln]

dotenv came out 2012, the .env convention predates LLMs and agents by quite some time.

[_pdp_]

.env was designed for local development ... not for storing production secrets, and user credentials are exactly that

[Shreyaskapale]

Hey, maintainer of GitAgent here.

Fair criticism, and I want to address it directly rather than dodge it.

The `.env` pattern is intentionally scoped to local development — a developer running their own agent with their own keys on their own machine. For that use case, the threat model is 'don't accidentally commit secrets,' which `.gitignore` does solve.

_pdp_ is right that this breaks down the moment you're handling credentials that belong to someone else — OAuth tokens, multi-tenant keys, anything production-adjacent. That's a real gap in the current spec.

What we're planning: a `secrets:` block in `agent.yaml` supporting pluggable backends — OS keychain, 1Password CLI, Vault, AWS SSM — so the spec has a first-class path for production secret management instead of implicitly blessing `.env` for all contexts.

But I'd genuinely love more input from this thread — if you were designing secret management for a git-native agent spec, what would you want it to look like? What patterns have worked well in your setups? This is an open spec and the best ideas should win.

[theozero]

Check out https://varlock.dev for a modern take on .env that gets your secrets out of plaintext. Free and open source - works with tons of tools. Adds validation, type safety, lots of nice features.

[cdecker]

But but but this is just a fig leaf. The agent will usually have file level access, and even if by some miracle you manage to feed the envvars into your program without LLMs looking over your shoulder, they can edit the files to add print statements.

If you want LLMs to work on your code, and be sure not to have them leak your secrets, you need a testing or staging environment to which they get credentials instead of prod. Now, if only that had been best practice before... Oh wait it was...