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.
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
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.
…Isn’t that what we’re talking about though? Or did I misunderstand the OP?
The post said they were neon database creds, so I would think those would live on the production system in .env
Rereading it, it seems that they probably set their local build to point at the prod database… Which is like halfway developing (with AI) in prod (which I think we’d agree is not ideal)
I do absolutely agree with what you’re saying though, not everyone should have access to the prod system for sure… Especially not an AI on a loose leash
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.
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
…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
.envthat 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.
The post said they were neon database creds, so I would think those would live on the production system in .env
Rereading it, it seems that they probably set their local build to point at the prod database… Which is like halfway developing (with AI) in prod (which I think we’d agree is not ideal)
I do absolutely agree with what you’re saying though, not everyone should have access to the prod system for sure… Especially not an AI on a loose leash
I’d split the difference and say we’re both right