Likely the user who set the agent to auto mode without confirming potentionally dangerous operations, and the infra lead for allowing users to access the prod db.
Shit, I set up my agents to only run in a sandboxed workspace, only suggest edits via merge requests that have to be manually approved by an actual person, and only connects to copies of databases. And that’s just for my personal projects on my home server. Anyone not taking similar steps in a professional setting should be fired immediately
Have you considered that management made AI usage a KPI, the feature has a deadline of next sprint, and setting up a sandboxed workspace is still sitting at the end of the backlog as a “nice to have”? /s
Reader roles are important, and should be the only access you allow your coding client.
Anti-AI people want to act like situations like this are indicative of a core problem with the AI, when if anything the AI just surfaced preexisting core issues in security, architecture, and developer training/habits.
‘The AI tried to delete production’ and ‘the AI was able to delete production’ are two separate problems. The AI doesn’t get a pass just because you also had a security problem.
I don’t think the AI ran npm run destroy-production --irreversible. Most probably it ran npm run test and the .env happened to point to production, which is 100% on the dev who put it there.
The AI isn’t a conscious entity, it’s a tool that does it’s best to carry out human instructions, based upon inference (and if you’re not an idiot, immutable guardrails). If it deleted production, let alone was given access capable of doing so, that’s completely gross human error.
Y’all are like children who get mad at inanimate objects.
You seem to know nothing about the principle of least privilege, and I’d venture a guess engineering and dev tooling. If you are a software engineer, you’re exactly the kind who’d delete a production database.
Likely the user who set the agent to auto mode without confirming potentionally dangerous operations, and the infra lead for allowing users to access the prod db.
Shit, I set up my agents to only run in a sandboxed workspace, only suggest edits via merge requests that have to be manually approved by an actual person, and only connects to copies of databases. And that’s just for my personal projects on my home server. Anyone not taking similar steps in a professional setting should be fired immediately
Have you considered that management made AI usage a KPI, the feature has a deadline of next sprint, and setting up a sandboxed workspace is still sitting at the end of the backlog as a “nice to have”? /s
Reader roles are important, and should be the only access you allow your coding client.
Anti-AI people want to act like situations like this are indicative of a core problem with the AI, when if anything the AI just surfaced preexisting core issues in security, architecture, and developer training/habits.
‘The AI tried to delete production’ and ‘the AI was able to delete production’ are two separate problems. The AI doesn’t get a pass just because you also had a security problem.
I don’t think the AI ran
npm run destroy-production --irreversible. Most probably it rannpm run testand the .env happened to point to production, which is 100% on the dev who put it there.The AI isn’t a conscious entity, it’s a tool that does it’s best to carry out human instructions, based upon inference (and if you’re not an idiot, immutable guardrails). If it deleted production, let alone was given access capable of doing so, that’s completely gross human error.
Y’all are like children who get mad at inanimate objects.
I meant it more in the sense that the AI was a shit product that isn’t fit for purpose, but you show those strawmen who’s boss.
You seem to know nothing about the principle of least privilege, and I’d venture a guess engineering and dev tooling. If you are a software engineer, you’re exactly the kind who’d delete a production database.