Managing secrets for AI agents, especially when they need to interact with external services via API keys, is a common challenge we've seen. The issues you're describing with `env` variables, `.env` files, and even the operational overhead of proxy processes are exactly what teams run into when trying to secure these workflows. There are typically two or three things causing this, often related to the agent's execution environment and the need for dynamic, secure credential access without exposing them directly. We've helped teams navigate these exact scenarios.

Built a solution for this last night: credwrap (https://github.com/akropp/credwrap)

TCP client-server model. Server holds credentials (encrypted at rest with age), injects them into a pre-approved allowlist of commands. Agent calls credwrap gog gmail search ... — server injects the API key and executes, agent never sees the credential.

Features:

Tool allowlist with argument validation Token / IP whitelist / Tailscale auth Full audit logging Works on Linux and macOS Two deployment modes: run as your own user with encryption (simple), or run as a separate system user for full privilege separation (more secure).

Had the thought that this was needed, and then saw this thread, so I figured I'd share.

We built our own harness from the ground up to account for this

Secrets come from aws secret manager and never injected into env directly.

Each part of the agentic workflow only gets the secrets it needs injected. Agent can see env var names but not the values (our harness masks them) . We also mask any attempts to output to stdout/files.

This keeps the agent architecture simple with env vars that all agents can operate on as it locally. Prompt injection attempts will only yield masked values

Has been working well for us so far

Curious if anyone has experimented with dotenvx - https://dotenvx.com/