Just like every single trend that came before, they said you would be left behind:

If you didn't embrace OOP Test driven development Behavior driven development Events driven development Pants in head driven development SOLID DRY Cloud first Virtualization everything Microsservices Serverless Everything js Everything ts Everything Microsoft

This will never stop.

You either let someone be in the middle of you and what you want to accomplish, or you will be left behind.

Think about the most mediocre person you know. Now remember 50% of people around you is dumber than that

No serious person would make fun of this emotional reaction. It seems technology had something going on, and it quickly got flooded by incompetence and greed.

We have all been deeply involved, constructed careers and sharpened our tools with technology and hopefully for the benefit of technology. I can only imagine how deeply sad the current state of software is for those talented individuals that helped to carry it to here.

Some of us can at least hide it with cynicism because there is not much at stake, but emotional honesty is very much appreciated.

Enjoy your experience, there will certainly be no end to it.

I've had my account since 2008. ¯\_(ツ)_/¯

updated: changed the date to 2008.

my account shows 2001, but that's probably from projects I moved over... proof: https://github.com/lookfirst

GitHub launched in 2008, so that seems unlikely?

I have no ingrained loyalty, I just haven't found something better.

>The recommended way to install Lean is through VS Code

Is that enough reason?

Yes.

I am tired of my time in tech being just using MS products that all depend on each other.

If the account is to be believed that's not what happened. They asked the LLM to do something on the staging environment, it chose to delete a staging volume using an API key that it found. But the API key was generated for something else entirely and should not have been scoped to allow volume deletions - and the volume deletion took out the production database too.

The LLM broke the safety rules it had been given (never trust an LLM with dangerous APIs). *But* they say they never gave it access to the dangerous API. Instead the API key that the LLM found had additional scopes that it should not have done (poster blames Railway's security model for this) and the API itself did more than was expected without warnings (again blaming Railway).

There is no version of this that is the LLM's "fault" for any definition. This was 100% pilot error. When you fly the plane into the side of a mountain on autopilot, it's pilot error every single time.

It sounds like the keys just don't have any scoping. From the post:

> The Railway CLI token I created to add and remove custom domains had the same volumeDelete permission as a token created for any other purpose. Tokens are not scoped by operation, by environment, or by resource at the permission level. There is no role-based access control for the Railway API — every token is effectively root. The Railway community has been asking for scoped tokens for years. It hasn't shipped.

So every token that can be created has "root" permissions, and the author accidentally exposed this token to the agent. What was the author's planned purpose for the token doesn't matter if the token has no scope. "token I created to add and remove custom domains" - if that's just the author intent, but not any property of the token, then it's kinda irrelevant why the token was created, the author created a root token and that's it. Of course having no scope on tokens is bad on Railway's part, but it sounds more like "lack of a feature" than a bug. It wasn't "domain management token" that somehow allowed wrong operations, it was just a root token the author wanted to use for domain management. Unless Railway for some reason allows you to select an intent of the token, that does literally nothing (as "every token is effectively root").

Per their docs they have both “account” tokens and role-based tokens; the former have wide latitude (and might be used for DNS or root-access type stuff), while the latter are intended to be used for maintenance and have strong security boundaries. OP gave access to the former type without realizing it.

In most orgs, those would be behind some escalation control. Unless the token creator didn’t know what they were doing/creating, which tracks for a non-expert.

"which tracks for a non-expert"

So all agents then...because if you are an expert at a specific system, using a LLM probably slows you down, not speeds you up.

PS The article seems to imply that the token the LLM was given was a role based token. It then found ANOTHER token and used that instead.

Agree. My point is that other secret should have been inaccessible without an escalation. The fact that it was available to the agent implies a lack of basic security controls; in fact I would expect that an agentic workload would have even more robust compensating controls.

If I understand correctly, both the staging database and the production database share the same volume. Thus, production data was gone as well after deleting the volume.

1st hint - the API call only contains one volume:

    curl -X POST https://backboard.railway.app/graphql/v2 \
      -H "Authorization: Bearer [token]" \
      -d '{"query":"mutation { volumeDelete(volumeId: \"3d2c42fb-...\") }"}'

2nd hint - this gem from the tweet:

> No "this volume contains production data, are you sure?"

"If I understand correctly, "

You don't. You are missing the part where the LLM had a token which blocked access as expected. Then the LLM searched the source base, found a different token with the delete privs and then used that.

PS That warning happens in staging envs too, the LLM doesn't know which env is which by design.

Huh that's not what I gathered from the tweet at all. If I am going to write a five why's analysis, the immediate cause is the LLM wrongly decided to delete a volume, while the root cause is the bad design to co-locate staging and production data in the same volume. The writing was quite vague though, let's wait for a response from railway.

Bingo.

What makes you say that? The article is pretty clear that they had the llm working in a staging environment, then it decided to use some other creds it found which (unbeknownst to the author) had broad access to their prod environment.

le reddit mentality

The fact the paper is only an interface and you're not depending any less on a computer, doesn't bother you at all?

In other news, token seller says tokens should be bought

There is one usecase: you can laundry your actions and just say "oopsies, llms when rogue I guess"

It's not pretty and not honest but if you're desperate I guess it's an option

I would prefer it if it could do my laundry. I can launder my actions on my own..

>let someone else use your tokens >someone else use your tokens

how could this be prevented?