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.