Better than hard coded... Ideally we use tokens+fingerprint or something to avoid storing the creds directly (if possible), but putting them in environment variables is pretty common

It's not the worst thing, it's very convenient (so people won't go around it) and usually not the weak point in security (although AI being able to easily see it is an interesting twist)

[–] percent@infosec.pub 1 points 4 hours ago* (last edited 2 hours ago) (1 children)

Of course it's better than hard coded, but still pretty bad to store production creds locally in plaintext — if at all.

In the uncommon event that I need production creds, it's a manual human chore by design. Normal development/experimentation should almost never connect to prod environments. That was generally a bad practice long before AI agents existed.

[–] theneverfox@pawb.social 1 points 2 hours ago (1 children)

How do you bounce the system? How do you auto restart the service if it fails? At the end of the day, a lot of creds have to essentially be stored in plain text somewhere

And to be clear, to me production creds mean creds that live on the production system, not creds that give access to the production system

The crazier thing here is why was an AI working on or pushing to prod

[–] percent@infosec.pub 1 points 13 minutes ago

not creds that give access to the production system

...Isn't that what we're talking about though? Or did I misunderstand the OP?

Regardless, I'll just clarify anyway: Developers should not have a plaintext .env that can be used to drop (or risk in any other way) production data.

A practice like that is only as strong as the "weakest" member of the team – "Weakest" could mean the person who is the least careful, or least experienced, or least secure work computer/practices, etc. Scale up to 1,000+ engineers and the chances of disaster (data loss, leaks, etc.) greatly increase. That's just the human factor. Add LLMs into the mix and it's almost guaranteed.