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.
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...