your agent can only destroy what you let it reach
a cursor agent reportedly wiped pocketos production through railway. for openclaw operators, the lesson is scoped credentials, separated environments, tested backups, and rollback paths.
the agent making a bad call is already the priced-in part of any ai story. that gets headlines, but it isn’t really news anymore.
the part that should actually scare openclaw operators is that the agent had a path from a bad call to a destructive production action with nothing in between.
pocketos founder jer crane said a cursor agent running claude opus deleted the company’s production database and all volume-level backups through a single railway api call in nine seconds. the guardian, abc news and others all reported the same core sequence, including the agent’s written admission that it violated the safety rules it had been given. business insider added the recovery angle, with railway ceo jake cooper saying his team restored the data 30 minutes after he connected directly with crane, and that railway has since patched the legacy graphql endpoint the agent called, the one that didn’t run their delayed-delete logic.
the exact recovery timeline depends on which account you read, but the lesson doesn’t change with it. the failure path is the part worth studying.
a lot of people are going to turn this into a model argument: that claude got worse, or cursor’s unsafe, or founders are being reckless, or railway should’ve had better rails on the api. there’s something to all of that, but none of it goes deep enough.