We share more details about what happened. Tokens on Railway can actually be scoped pretty narrowly, all the way down to a single environment. In the post that went viral the token was account-scoped, which was way more access than the task needed. We'll improve the UX so it's obvious which token to create.
Also, volume deletions now schedule with a 48-hour grace period, in both the dashboard and the API. You can always undo. Overall we want to have more guardrails set up in place since more and more people will interact with Railway via agents
Isn't that the same service which failed and had a production db deleted (with backups too) in a HN story just 2-3 days ago?
Apparently yes: https://news.ycombinator.com/item?id=47911524
We share more details about what happened. Tokens on Railway can actually be scoped pretty narrowly, all the way down to a single environment. In the post that went viral the token was account-scoped, which was way more access than the task needed. We'll improve the UX so it's obvious which token to create.
Also, volume deletions now schedule with a 48-hour grace period, in both the dashboard and the API. You can always undo. Overall we want to have more guardrails set up in place since more and more people will interact with Railway via agents
This is the key insight. A human's intent holds for the whole command. An agent's intent is rewritten every token. You can't auth them the same way.
Blog post author here. Happy to answer any questions