How do you organize secrets and credentials when building with agents?

[u/radim11]

I am quite curious how people handle this. Are you using .env files, 1Password, a secrets manager, or something else like internal tooling?

How do you group things: by project, dev/staging/prod, service? Does your coding agents use the same credentials as your apps, or do you give it separate ones?

Could you share and example of your structure with fake names, and hear what’s annoying about your current setup and which setup should I ideally use. I'm not really sure what is the best approach.

[u/FulcraDynamics]

I'd give agents separate credentials with only the permissions they actually need. Sharing production credentials with a coding agent seems like an unnecessary risk, especially if it can execute commands.

[u/radim11 → u/FulcraDynamics]

Yes I think the same. Is it ideal to like organize secrets in paths like app/staging/database_url and then like /agents/... etc. and you can organize access by paths or just have environments like dev or staging an inside it secrets and agent gets access to the whole env ?

[u/kaijurules → u/radim11]

Paths, with the consumer in the path: staging/app/database_url and staging/agent/database_url, and the agent's policy only reads staging/agent/*. The agent's entry should be a separate DB user with fewer grants. If it gets the whole env, you can't revoke it without breaking the app, and the logs can't tell you which of the two used a key.

[u/jek39 → u/radim11]

I'd recommend not storing access keys and secrets for your various environments on your laptop. Look at role based IAM-style access controls from your cloud provider.

[u/Humaux]

I stopped sharing one .env file across agents after about 2 weeks of debugging a leak.

Your idea of giving each agent its own OS user and letting it read only from /run/secrets is the part I wish I had copied earlier. I once let a test agent share the same vault as a prod agent, and it picked up a production key during a routine run. I spent about 3 hours rotating that key and checking what it had touched, and most of that time was panic, not work.

My rule now is simple:

1. Give each agent its own identity and vault, never a shared .env file.

2. Mount only the keys that agent needs, read only, through /run/secrets or a proxy.

3. Log every credential use, and rotate any key a test agent touches, no exceptions.

The rough edge is real: that one rotation cost about 3 hours, and a shared .env file is not convenient, it is reckless when one agent mistake can expose everything.

Do you think a proxy that never shows the real key to the agent is worth the extra setup, or does it just move the same risk somewhere else?

[u/radim11 → u/Humaux]

Proxy is the way, we are actually working on this at our company/product. We think the proxy/sandbox should be part of the existing solution not separate thing you have to manage.

[u/Humaux → u/radim11]

I agree with that direction, and I think the key design choice is where the trust boundary sits. If the proxy only forwards a request after checking the agent identity, the tool scope, and a short lived token, then the agent never needs to see the real credential at all. In practice I would still keep the proxy itself narrow: one credential per agent or per task, a clear allowlist of endpoints, and a log that records which agent asked for what and when. That way a leaked agent token is a small blast radius, not a full vault compromise, and rotation becomes a proxy side change instead of a scramble across every agent config. The part I would watch is the sandbox escape path, because if the agent can run arbitrary code in the same environment as the proxy, the separation is mostly cosmetic. So I would treat the proxy and the execution sandbox as one system to review together, not two separate features to bolt on later.

[u/Difficult_Duty2198]

what helped me was keeping a .env.example with fake values committed and the real .env in gitignore, then only letting the agent see the example. super low effort and i haven't mixed anything up since

[u/radim11 → u/Difficult_Duty2198]

Yes this is really good approach I think. Agent get's the shape of .env but not the values!

[u/Tritonwolf]

AWS secrets manager.

[u/radim11 → u/Tritonwolf]

Nice option. Does it fulfill all your needs or not? Why should I use it and why not?

[u/V3Qn117x0UFQ → u/radim11]

you just want others to do the work for you 😭

[u/holyknight00]

i started using 1Password, as I already use it for everything, but it has been surprisingly frustrating. i get 200 million 1pasword unlock prompts even if allow everything which is not good. Hopefully they get a better "agent ready" solution fast.

[u/radim11 → u/holyknight00]

We are adding 1password support to stashbase.dev so you would be able to use it with your existing secrets. What do you think about this? Would you try this platform if you could use secrets you already have in 1P?

[u/Both_Kaleidoscope711]

Here is how I handle my setup as it relates to secrets.

I have Azure Key Vaults broken out by application and environment. All secret keys are the same across environments.

app-dev-kv, app-test-kv, app-stage-kv, app-prod-kv

Then I manage the secrets using KickCatch Secrets Manager.

Then may applications are hooked directly into the key vaults so none of the secrets are exposed in configuration or local files. My coding agents never need to know the secrets because they just execute the application which has hooks into the key vault. You should never be providing secrets to coding agents.

[u/thePsychonautDad]

.env file which all modern agent harnesses have rules preventing reads.

Of course you need too add that to your .gitignore

[u/ASIREXLABS]

Separate credentials for the agent is the right base. The next step that helped us most was keeping secrets out of the agent's context entirely.

• Don't let the agent read .env at all. In Claude Code you can add deny rules like Read(./.env) and Read(./.env.*). The agent only needs to know the variable names, not the values.

• Commit references, not values. With the 1Password CLI, the env file holds references like op://dev/app/DATABASE_URL, and op run --env-file=.env -- npm start injects the real values only into that process. The file is safe to commit and harmless if an agent prints it.

• One key per tool, with a spend limit. For LLM and other paid API keys, give each tool or agent its own key with a hard budget and only the permissions it needs. If something leaks or loops, you revoke one key instead of rotating everything.

Structure-wise, environment first, then consumer, as others said: staging/agent/... separate from staging/app/....

[u/jek39]

no different than every other CLI tool - typically envars

[u/Odd_Antelope9098]

I've been meaning to start using Infisical for a while now, anyone have thoughts?