[zith]

I must have missed some trends changing in the last decade or so. People have production secrets in the open on their development machines?

Or what type of secrets are stored in the local .env files that the LLM should not see?

I try to run environments where developers don't get to see production secrets at all. Of course this doesn't work for small teams or solo developers, but even then the secrets are very separated from development work.

[tuvistavie]

I think having API keys for some third-party services (whatever LLM provider, for example) in a .env file to be able to easily run the app locally is pretty common. Even if they are dev-only API keys, still not great if they leak.

[endofreach]

If you can't trust the "agent" with a secret to the LLM which is practically like access to its runtime, what the hell... others propose mitming yourself...

All of this does seem kinda funny

[Malcolmlisk]

Usually, some people change their .env files in the root of the project to inject the credentials into the code. Those .env files have the credentials in plain text. This is "safe" since .gitignore ignores that file, but sometimes it doesn't (user error) and we've seen tons of leaks because of that. Those are the variables and files the llms are accessing and leaking now.

[zith]

Sure, but it's probably unwise to have your production credentials on your development machine at all. It's far more likely to be compromised than your locked down production environment.

[portly]

Sometimes it can be handy for testing some code locally. Especially in some highly automated CICD setups it can be a pain to just try out if the code works, yes it is ironic.