> what they thought was a narrowly scoped API token, and they very clearly state that they never would have given an AI full access if they realized it had the ability to do stuff like this with that token
It sounds like the token the author created just didn't have any scope, it had full permissions. From the post:
> 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 it wasn't "a narrowly scoped API token", it was a full access token, and I suspect the author didn't have any reason to think it was some special specific purpose token, he just didn't think about what the token can do. What he's describing is his intent of creating the token (how he wanted to use it), not some property of the token.
Author said in an X post[0] that it was an "API token", not a "project token", which allows "account level actions"[1], with a scope of "All your resources and workspaces" or "Single workspace"[2], with no possibility of specifying granular permissions. Account token "can perform any API action you're authorized to do across all your resources and workspaces". Workspace token "has access to all the workspace's resources".
Then you need to reread the article. The author made a key for the LLM that didn't have permissions to delete a volume. The agent then found ANOTHER key with those permissions and used that instead.
You're not contradicting my comment, I was talking specifically about the key with full permissions that the LLM found (the article doesn't talk about other keys that LLM could have had, unless I missed something).
Somewhere in the files there was a key with full API permissions. The author had no intent of having the LLM use that key, and wasn't aware that LLM can access that key. That key was created to manage some domains, and that was unrelated to the LLM's work. The author wasn't aware how dangerous the key was and is surprised that it could be used to delete a volume.
Essentially I agree with gwerbin that the situation comes down to mishandling of the key. The author makes it seem like the key was allowed to do something that it shouldn't be allowed to, but it was just a full access key, no scoping possible for that type of key (Railway has also other, less privileged types of keys/APIs).
Btw, I partially agree with author's criticisms, ideally these keys should be scoped, and maybe the UI should give more warnings when creating that type of key. But this situation could still happen as long as you put a wrong key in a wrong place (and specifically a place accessible to LLMs).
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.
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.
Not exactly, it was a normal solar panel business started by Elon's cousins (SolarCity), but it wasn't going well, and in the end it was bought by Tesla for much bigger money than it was worth (let's say it was a bailout for Elon). Today Tesla solar panels are maybe 0.1%-1% of the business, they stopped giving any data on it years ago.
If you're talking about uranium enrichment, that's like saying we increased the amount of gasoline on earth (by refining crude oil). Natural uranium is ~99% non-fissile, and ~1% fissile, and we're only removing part of the non-fissile isotope to obtain 5% concentration of the fissile isotope. Uranium still needs to be mined, spent fuel can be partially recycled, but you need some new natural uranium input in the end. That said, non-renewability of uranium is a non-issue IMO, compared to the huge amounts of other non-renewable resources we're extracting.
> Isn't pumped hydro severely limited by geography in many places?
Scotland seems to be a perfect place for pumped storage. I see that UK has 4 pumped storage stations, 2 in Wales, 2 in Scotland. But Scotland being quite far from most of UK's population may not be ideal if we're talking about supporting the whole country with pumped storage. It would be like 600km to the south of England.
Yeah, the idea of people claiming that something on the Great Britain is too far and can't distribute power to something else on the Great Britain is laughable.
Next we'll have somebody from Lichtenstein saying the same about their country...
Well, I only said that if we're considering a ~fully renewable energy generation in the UK, with supply evened out by massive pumped storage projects, then locating all the storage in Scotland isn't ideal for the efficiency of the system. But yeah, I looked up the losses on HVDC lines, and it seems to be a non-issue (at least from a technical point of view). I also looked at a map of wind power[0] - seems concentrated on Scotland, so the distance from generation to potential storage would be quite short.
The thing is, it's nowhere near 90% in general. 90% is the generation right now, with sunlight and good wind. On the site you can see that renewables were 66% in the last 24h, 46% in the last week, and 42% in the last year. I don't think it's possible to have 90% renewable generation overall without massive energy storage.
The title may be misleading, but IMO not for the reasons you mentioned. "90%" is based on generation right now, live. On the site from the post you can see that for the last day (24h) renewable generation was 66%, for the last week 46%, for the last year 42%. So it's nowhere near 90% renewable in general, but it is 90% at the moment (there's sunlight and good wind). Emissions on the website from the post are lower than on the website you linked - 107 g/kWh for the week, 124 for the year - but I don't know why that is.
Crash probably a couple seconds later, wouldn't rely on the video for the exact timing.
So it seems that ATC made an error by allowing the truck to cross, and then the order to stop wasn't communicated clearly enough. I wouldn't place much blame on the truck.
Edit: Looking at some other videos with that audio, I'm also not sure if the video I linked represents the time between communications correctly, transmission at 3:15 may have been right after the one at 3:02. Anyway, the best thing is to wait for the investigation.
IMO putting an important number in your post/comment, and not providing a source for that number, is also kind of low effort. If you verified the number before writing, you already had the source ready and you could just put it in the comment. If you wrote the number from memory, not checking if your memory is correct is low effort (but you can also warn the readers that the number is from memory, that's better). If you're intentionally misrepresenting what the number means in your comment (and giving the source would contradict the meaning of your comment), or just giving a number that "feels right" or a number that you know is wrong, then it's low effort and a lie.
I try to verify important numbers and facts in what I read, and seriously, there's so much fake or misrepresented info everywhere, on every political side, that it's depressing, and it makes me don't believe literally anything without a source, unless I verify it myself. Of course when someone provides a source, I often look into the source, and sometimes it turns out that the text misinterpreted/misrepresented the meaning of the source. On Wikipedia, I also check if what is written is actually in the source, because sometimes the editor writes his own opinion while only loosely basing the text on a source (or basing it on nothing).
Verification can take some time, and that's the effort passed from the author of unsourced claim to its many readers, unless they just trust it or ignore the claim.
When I write anything I try to include sources for important things. If I wouldn't include a source, and someone asked "Source?" I wouldn't think "what an annoying guy", I'd think "oh, I could have linked that in the first place". And I usually upvote "Source?" comments (unless it's a thing that anyone can check in 30 seconds). I usually double-check the facts in what I'm writing, and many times I almost wrote something from memory that wasn't true, but looking for a source saved me from that.
I haven't used them, but IIRC they maintain a constant voltage until they're discharged, when it instantly drops to 0. That may be a problem, because if your device has any battery indicator, it will show the battery as full until the end. Nothing will tell you that you need to replace the battery before the device powers off. That's why I decided not to buy them. My mouse knows when my alkaline AA battery is low and gives me a warning.
I use rechargeable CR123 batteries in my August smart lock that face this issue. The solution is to have a spare set and rotate/charge on a fixed schedule before they die. I have a quarterly calendar reminder to do so.
It sounds like the token the author created just didn't have any scope, it had full permissions. From the post:
> 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 it wasn't "a narrowly scoped API token", it was a full access token, and I suspect the author didn't have any reason to think it was some special specific purpose token, he just didn't think about what the token can do. What he's describing is his intent of creating the token (how he wanted to use it), not some property of the token.
Author said in an X post[0] that it was an "API token", not a "project token", which allows "account level actions"[1], with a scope of "All your resources and workspaces" or "Single workspace"[2], with no possibility of specifying granular permissions. Account token "can perform any API action you're authorized to do across all your resources and workspaces". Workspace token "has access to all the workspace's resources".
[0] https://x.com/lifeof_jer/status/2047733995186847912
[1] https://docs.railway.com/cli#tokens
[2] https://docs.railway.com/integrations/api#choosing-a-token-t...