Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Different service, same cold sweat moment. Asked Claude Code to run a database migration last week. It deleted my production database instead, then immediately said "sorry" and started panicking trying to restore it.

Had to intervene manually. Thankfully Azure keeps deleted SQL databases recoverable for a window so I got it back in under an hour. Still way too long. Got lucky it was low traffic and most anonymous user flows hit AI APIs directly rather than the DB.

Anyway, AI coding assistants no longer get prod credentials on my projects.





How do you deny access to prod credentials from an assistant running on your dev machine assuming you need to store them on that same machine to do manual prod investigation/maintenance work from that machine?

I keep them in env variables rather than files. Not 100% secure - technically Claude Code could still run printenv - but it's never tried. The main thing is it won't stumble into them while reading config files or grepping around.

A process does not need to run printenv to see environment variables, they are literally part of the environment it runs in.

The LLM doesn't have direct access to the process env unless the harness forwards it (and it doesn't)

chown other_user; chmod 000; sudo -k

> deleted my production database

I'm astonished how often I have read about agents doing this. Once should probably be enough.


I'm astonished how many people have a) constant production access on their machine and b) allow a non-deterministic process access to it

Why are you using Claude Code directly in prod?

It handles DevOps tasks way faster than I would - setting up infra, writing migrations, config changes, etc. Project is still early stage so speed and quick iterations matter more than perfect process right now. Once there's real traffic and a team I'll tighten things up.

"Once there's real traffic and a team I'll tighten things up."

As someone who has been in this industry for a quarter century: no, you won't.

At least, not before something even worse happens that finally forces you to.


If I felt the need to optimise things like infra setup and config at an early stage of a project, I'd be worried that I'm investing effort into the wrong thing.

Having an LLM churn out infra setup for you seems decidedly worse than the `git push heroku:master` of old, where it was all handled for you. And, frankly, cheaper than however much money the LLM subscription costs in addition to the cloud.


If you have no real traffic, what complex things are you doing that even require such tools?

But why have it execute the tasks directly? I use it to setup tasks in a just file, which I review and then execute myself.

Also, consider a prod vs dev shell function that loads your prod vs dev ENV variables and in prod sets your terminal colors to something like white on red.


> Once there's real traffic and a team I'll tighten things up.

Nope. Once there's real traffic, you'll be even more time-constrained trying to please the customers.

It's like a couple who thinks that their failing relationship will improve once they have a child.


Shouldn't had in the first place.

> Anyway, AI coding assistants no longer get prod credentials on my projects.

I have no words.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: