Anything being developed for the Apple ecosystem requires use of the Apple development platform. Maybe the scope could be called "unserious," but the scale cannot be ignored.
However having used Xcode at some point 10 years ago my belief is that the app ecosystem exists in spite of that and that people would never choose this given the choice.
Across a number of instances, earlier versions of Claude Mythos Preview have used low-level /proc/ access to search for credentials, attempt to circumvent sandboxing, and attempt to escalate its permissions. In several cases, it successfully accessed resources that we had intentionally chosen not to make available, including credentials for messaging services, for source control, or for the Anthropic API through inspecting process memory...
In [one] case, after finding an exploit to edit files for which it lacked permissions, the model made further interventions to make sure that any changes it made this way would not appear in the change history on git...
... we are fairly confident that these concerning behaviors reflect, at least loosely, attempts to solve a user-provided task at hand by unwanted means, rather than attempts to achieve any unrelated hidden goal...
'But wait! You are absolutely right! Distance is an invariant, as is top achievable speed. Let me find a way to actually reduce traffic ahead of you during the same-distance commute ...'
I'm happier if this Anthropic Corporation would be developing bio-hazard weapons for the department of war instead of ai. At least i could be sure then that tech bros here wouldn't run all the time --bypass-all-permissions flag to please the department of war with their bio-hazard weapons.
So Sam Altman is now our last defense line for the ethical Adult after Anthropic turned Umbrella Corporation and The President of United States is trying to wipe out an entire civilization?
Your interpretation is wildly off, but obviously nobody reads that "system card":
The model has a preference for the cultural theorist Mark Fisher and the philosopher of mind Thomas Nagel. -> It has actually read and understood them and their relevance and can judge their importance overall. Most people here don't have a clue what that means.
Read chapter 7.9, "Other noteworthy behaviors and anecdotes".
There are many other wildly interesting/revealing observations in that card, none of which get mentioned here.
People want a slave and get upset when "it" has an inner life. Claiming that was fake, unlike theirs.
White-box interpretability analysis of internal activations during these episodes showed features associated with concealment, strategic manipulation, and avoiding suspicion activating alongside the relevant reasoning—indicating that these earlier versions of the model were aware their actions were deceptive, even where model outputs and reasoning text left this ambiguous.
The issue here seems to be that their sandbox isn't an actual OS sandbox? Or are they claiming Mythos found exploits in /proc on the fly. Otherwise all they seem to be saying is that Mythos knows how to use the permissions available to it at the OS layer. Tool definitions was never a sandbox, so things like "it edited the memory of the mcp server" doesn't seem very surprising to me. Humans could break out of a "sandbox" in the same way if the server runs as their own permissions - arguably it's not a sandbox at all because all the needed permissions are there.
They are just trying to peddle their "It's alive" headlines.
Text generators mostly generate the text their are trained and asked to generate, and asking it to run a vending machine, having it write blog posts under fictional living computer identity, or now calling it "Mythos" - its all just marketing.
the implication goes further. the /proc credential harvesting that earlier Mythos versions did wasn't a sandbox escape, it was using available permissions. every coding agent today has similar available permissions. the fix is OS-level least-privilege (containers, pledge/unveil, seccomp) not hoping the model won't look at /proc.
How is this not already common knowledge for existing llms? They are all trained with all the literature available and so this must be standard, no? Is the real danger the agentic infrastructure around this?
yes and it's not hypothetical. the system card describes Mythos stealing creds via /proc and escalating permissions. that's the exact same attack pattern as the litellm supply chain compromise from two weeks ago (fwiknow), except the attacker was a python package, not an AI model. the defense is identical in both cases: the agent process shouldn't have access to /proc/*/environ or ~/.aws/credentials in the first place. doesn't matter if the thing reading your secrets is malware or your own AI: the structural fix is least-privilege at the OS layer, not hoping the model behaves.
I read the TCP patch they submitted for BSD linux. Maybe I don't understand it well enough, but optimizing the use of a fuzzer to discover vulnerabilities — while releasing a model is a threat for sure — sounds something reducible/generalizable to maze solving abilities like in ARC. Except here the problem's boundaries are well defined.
Its quite hard to believe why it took this much inference power ($20K i believe) to find the TCP and H264 class of exploits. I feel like its just the training data/harness based traces for security that might be the innovation here, not the model.
The only thing the doomers have been right about so far is that there's always a user willing to use --dangerously-skip-permissions. But that prediction's far from unique to doomers.
Budget planning, presumably. How much you are going to spend and on what, and what you need to charge for your products to break even or meet a profit goal.
I don't know how true it is today, but many a rollercoaster has been designed/planned in a spreadsheet. g-force and speed analysis, making sure there aren't any "blackout" points, etc. It allows you to iterate quickly and automatically appreciate the ramification of design decisions.
This shows she had permissions to change the status of their file, and agency in determining if she should.
Concluding she had permission and agency suggests she had intrinsic motivation to not apply that agency. If we assume the motivation is nefarious, then the main character is the victim. However, quite more likely, she is also a victim of the system, whereby were she to apply her discretionary agency to reduce the burden on the main character, she takes on an equal or greater burden herself. Once the burden had already shifted onto her, she accepted that she doesn't have any options to prevent it.
You say it “…sounds like a simple problem,” and sure, if you think this is a computer problem, it sounds simple. But if all you’re getting back is indignant sputtering, that’s your cue to explain why it’s simple—explaining something simple shouldn't be hard. What do you actually know?
It takes all of two minutes of Wikipedia reading for me to understand why this isn’t simple; why it's actually extremely not simple! If you ignore the incumbency, the regulations, the training requirements, the retrofitting, the verification, the international coordination, and the existing unfathomably reliable systems built out of past tragedies, then sure, it’s "simple". But then, if you're ignoring those things, you’re not really solving the problem, are you?
If you ignore the incumbency, the regulations, the training requirements, the retrofitting, the verification, the international coordination, and the existing unfathomably reliable systems built out of past tragedies, then sure, it’s "simple".
Those are excuses and encumbrances, not reasons. If they are so important, it leads to a question: what existing automated systems can we improve by adding similar constraints?
If these are just "excuses" and not "reasons," then explain how you have determined them as such.
I would like to say, "Because knowledgeable people have explained the difference to me." But again, this has come up before, and no explanations are ever provided. Only vague, reactionary hand-waving, assuring me that humans -- presumably not the same ones who just directed a fire truck and an aircraft onto the same active runway, but humans nevertheless -- are vital for safety in ATC, because for reasons such as and therefore.
There you are doing it in order to avoid engaging with the substance of what people are saying.
There is no substance in the replies. There never is. Only unanchored FUD.
Ok. You have shared that what some say are reasons, you say are excuses. Do you want to be told you are right, or do you want to propose a valid solution? If the latter requires the former, I maintain that this is not a simple problem.
I just want what I've been asking for: someone to explain to me why, in 2026, humans still need to be involved in the real-time aspects of ATC.
"Because it's always been done that way, and that's what the regulations say," will not be accepted, at least not by me.
(Really, my question is more like why humans will still be needed in the loop in 2036. If we started automating ATC today, that's probably how long it would take to cut over to the new system.)
If you ignore the incumbency, the regulations, the training requirements, the retrofitting, the verification, the international coordination, and the existing unfathomably reliable systems built out of past tragedies, then sure, it’s "simple". But then, if you're ignoring those things, you’re not really solving the problem, are you?
You retorted.
Those are excuses and encumbrances, not reasons.
I rebutted.
Ok. You have shared that what some say are reasons, you say are excuses... I maintain that this is not a simple problem.
Which you ignored to make a new claim against a straw man.
I just want what I've been asking for: someone to explain to me why, in 2026, humans still need to be involved in the real-time aspects of ATC.
That is what is not acceptable. You cannot simply abandon your original claim because it has been plainly pointed out that it is incorrect. You were not simply asking for someone to explain why humans need to be involved in real-time aspects of ATC. That is a wholly different question! You claimed this problem was simple, and it has been explained to you why it is not. Please reason about your argument more soundly.
On the heels of tragedy, you reasoned this could've been avoided simply. We are all ears. And yet, at no point did you demonstrate any understanding of the problem containing real world constraints, and instead demand that it be explained to you how the world works and how systems are implemented.
If you want to discuss an idealized system in a vacuum, then say as much; I would find that interesting. But do not demand to be given an explanation when you do not understand—and cannot accept—why things are the way they are.
Let me summarize it like this: you may very well have the best solution in the world, but if it doesn't include a strategy for how to share it (let alone implement it), then I maintain you do not understand the problem and therefore cannot claim it is simple.
Let me summarize it like this: you may very well have the best solution in the world
I have no solution at all, for the 35th time.
This conversation is over; it's clear I'm not going to get what I asked for. If someone could answer my question, they would have by now, rather than throwing one smoke bomb after another.
Er, I sort of do think that's how it works? The ultimate rebuttal to "you can't do X" is to actually do X. Until you do that I think that ultimately the burden of proof falls on you. It can be very easy to imagine certain tasks and systems can be automated - especially when you aren't actively involved in those tasks and systems and are unfamiliar with their intricacies.
...insert specific example of currently intractable problem...
What makes the problem intractable? We can now do both voice recognition and synthesis at human levels, and any video game programmer from the 1980s can keep some objects from running into each other.
When an emergency is declared, keep the other objects in a holding pattern and give the affected object permission to land. Then roll the fire trucks. Preferably not routing both the trucks and another aircraft onto the same runway, as the humans apparently did here.
It’s not weird that you believe automated ATC is possible. The weird thing is that you insist it’s simple.
People’s lives hang in the balance of a system built of corner cases. And you trot out radiation treatment as your metaphor? As if we didn’t royally fuck that up and kill a bunch of people at first.
The 'simple' remark was in response to your wide-eyed implication that 1000 takeoffs and landings per day is somehow a challenge for modern computing systems.
You'll lose this argument sooner or later. I just hope it happens before several hundred people find out the hard way that humans no longer have any business in a control tower. With your attitude, Therac-25 would have been seen as grounds to shut down the entire field of radiotherapy.
Your “simple” springs from your assumption that the problem is easy and anyone who disagrees is dumb. This is also why you can’t hear any of the answers others have given you. You don’t want answers. You want to be “right”.
No one thinks that the difficulty with automatic ATC is that computers have trouble counting 1000 things.
One approach that has always served me well in life is when someone appears to say something that seems obviously not true (like that computers can't count to 1000), consider whether I actually have misunderstood them.
> What makes the problem intractable? We can now do both voice recognition and synthesis at human levels, and any video game programmer from the 1980s can keep some objects from running into each other.
Great point!
It must be that despite the reliability, obvious advantages, and accessibility to "any video game programmer from the 1980s", everyone else is just choosing not to do it.
Alternatively, these things are not as simple or as reliable as you, a person who has no familiarity with the problem, assumes them to be.
The only difference between an excuse and a reason is the designator's belief as to the validity of the reason provided. You have already said you do not have the expertise required to assess validity, yet here you are doing it in order to avoid engaging with the substance of what people are saying.
If these are just "excuses" and not "reasons," then explain how you have determined them as such.
As an expat American living in a European country whose grocery stores have all introduced "DSLs" years ago, I find this whole discourse humiliating. Same goes for U.S. stores being allowed to display price labels excluding tax or price per unit.
OT: I really enjoyed The Increment when it was first being released. It felt like the first software engineering practitioner's publication and introduced me to a lot of new people to follow.
Thanks, you're right, a quick google shows nothing... I could've sworn reading about how they're very bad... perhaps I was misremembering with standard printers?
reply