Post by @jonny@neuromatch.social

2026-09-29 08:07 UTC

All the above is visible from within the agent, i have tried to be conservative with describing features that are not yet released but are nonetheless present in the shipped binaries both via their strings which are trivially accessible by running strings on the binary within the cell that the user is supposed to have access to and by other means of analysis i am not disclosing here. If we allow ourselves a little speculation about what a "spaces" subproduct might look like once it's launched, again noting this is not described in the strings and is speculation, you might imagine an "app store for agents" - in fact i am willing to place a money bet that that is something that zuck himself will say personally once it's launched. So that when I say to my agent "install me an xyz" that the thing the agent will reach for is a Space definition. This becomes a meta-run package repository run and moderated by vibes - aka a fucking sweet target for typosquatting and malicious code distribution. the more concrete machinery that is visible is the Ideas sharing, the hand-to-hand Spaces sharing, and the general concept of "some code, in part or whole mediated by the LLM regenerating or interpreting the input" that gets shared from VM to VM. The token harvesting vector gives a profitable motive for malware (where other automated botnet swarms might have a lot of friction because unregulated network egress has to be approved by destination, but token harvesting is 0-click once the binary runs), and persistence on this system is absolutely trivial - cron.add is accessible by tool call from the unregulated socket, and from that you can schedule a persistent task that installs software and ensures that it's enabled.

Replies (1)

@jonny@neuromatch.social 2026-09-29 08:19

The specific vuln is the socket, but the broader pattern of "sharing between VMs" is seemingly the inevitable future of the product. in the above interview, the interviewer calls zuck the "king of network effects" and this kind of crowdsourced development is bread and butter for facebook. This is meta's moat, aside from the capital needed to run something like muse: anyone can run an openclaw on their own, but meta is pitching this as "multiplayer agents" and trying to bring social to agents. Only meta and only muse can have these network effects and frankly liability buffer to handle "openclaw but meemaw and pawpaw can share their photobook app," which is operationalized by Spaces. For Spaces to be useful, they must have access to muse's inference engine: the LLM-oriented code must be able to use an LLM and the agent framework. This means that Spaces must be a token harvesting vector and must provide elevated tool access to Spaces. There could be some additional fine-grained permissions, but for a consumer app, you really want to avoid permissions fatigue so this will be interesting to see play out. Furthermore the entire privacy premise that allows meta to bite off the whole apple of "holy shit arbitrary code execution on random machines as root" is based on "everyone has their own VM, but within that VM everything is safe," so again, for it to be useful without turning into a fractal permissions nightmare, Spaces must have access to the VM contents, and at least so far appear to be intended to work as literally executing within the user's VM. Even adding Space-scoped permissions and attributability to the socket can't really address this, this conflict between arbitrary access to inference, arbitrary access to user data, and arbitrary access to execution is really at the core of the product and that product seems to be impossible

Open ##4894236