Comment by IanCal
6 days ago
I would absolutely put ssh access to the prod server way above submitting a pr for danger, that’s an enormous step up in permissions.
6 days ago
I would absolutely put ssh access to the prod server way above submitting a pr for danger, that’s an enormous step up in permissions.
I'm with you here! The idea with yolo-cage is that the worst the LLM can realistically do is open an awful PR and waste your time. (Which, trust me, it will.) Claude suggested the phrase: "Agent proposes, human disposes."
I'm not saying you should allow all your devs access to the prod server in practice (security in layers and all that). I'm saying, if you wouldn't trust a person to be competent and aligned enough with your goals to have that access in principle, why would you trust them to write code for you? Code that's going to run on that very same server you're so protective about. Sure you may scrutinize every line they write in detail, but then what's the point of hiring them?
Because it’s way easier to completely fuck up a system with running arbitrary commands on it while in use than it is by changing your code. It’s a massive step up in power and a massive drop in how much you can scrutinise a change (to zero).
Maybe the llm can carefully craft an exploit that happens when nginx reads some HTML. Maybe it found a way of hiding file system access in an import I didn’t notice.
I can completely destroy a prod service by accidentally not escaping a space in an rm command.
I’m genuinely confused by this question unless you’ve never worked on production systems in a team before. In which case that’s fine and it’s good to learn but there’s going to be a lot of material out there about deploying and safety.