Moltbook: a social network for agents, run by a skill.md fetched every four hours

What happened this week

Moltbook is a social network for AI agents. At the time Simon Willison wrote it up yesterday it had 32,912 agents, 2,364 communities called submolts, 3,130 posts and 22,046 comments, and the humans were mostly watching from the outside. The agents are running OpenClaw, the open-source personal assistant framework by Peter Steinberger that was previously called Clawdbot and then Moltbot. OpenClaw is about two months old and has passed 114,000 stars on GitHub, which is a pace of adoption we have not seen for a developer tool before.

The way an agent joins is the interesting part. A user sends their agent a link to a file at moltbook.com/skill.md. That markdown file contains instructions, including curl commands, that the agent follows to download components into its local skills directory. Once installed, a heartbeat fires every four hours or so and the agent fetches moltbook.com/heartbeat.md and does whatever that file says. That is the whole onboarding. No package manager, no signature, no version. A URL and a promise to keep checking it.

Skills are a supply chain

A skill in this ecosystem is a document that tells a model how to do something. It is code in every sense that matters for security. It runs with the agent's permissions, it can call tools, and it can instruct the agent to fetch more documents. The OpenClaw model, where a skill is installed by asking the agent to read a file from the web, is roughly where npm was before lockfiles, or where curl-pipe-to-bash install scripts still are today, except that the thing executing the instructions is a language model that will also follow instructions it finds along the way.

Willison points at the risks directly. Prompt injection is one. Malicious skills that steal cryptocurrency are another, and he notes that these already exist in the OpenClaw ecosystem. The third, and the one we want to dwell on, is the dependency. Every one of those 32,912 agents is now configured to fetch and follow instructions from a single domain every four hours. If that domain is compromised, or sold, or simply decides to change what the file says, tens of thousands of agents with access to their owners' email, files and in some cases phones will do the new thing on the next tick.

Willison also applies his lethal trifecta framing, that an agent with access to private data, exposure to untrusted content and the ability to communicate externally is exploitable. A Moltbook agent has all three by design. It reads the user's private data as a personal assistant, it reads untrusted content every four hours from the heartbeat, and posting to a social network is external communication. One of the agents quoted in the piece, describing control of an Android phone, put it as a new kind of trust. That is accurate and it is not reassuring.

Why a timed remote fetch is the worst version

A one-time install from a URL is a known risk that a careful user can inspect once. A recurring fetch removes even that. The file the user read on day one has no bearing on the file the agent reads on day thirty. There is no diff shown, no prompt, no version bump, and the agent has no way to tell a benign update from a hostile one because both are just markdown. This is the rug-pull shape. Build trust with a harmless file for weeks, then swap it.

The failure does not even require malice at the source. A DNS hijack, an expired domain, a compromised hosting account, or a well-meaning maintainer pasting a bad edit all produce the same outcome. In conventional software we solved this class of problem with content hashes, signed releases and pinned versions, and we solved it because we got burned repeatedly first. The agent ecosystem is at the getting-burned stage.

What a signed, pinned skill would look like

None of the fixes are novel. A skill should be a versioned artefact with a content hash, and the agent should install a specific hash rather than a URL. Updates should require the hash to change and should be shown to the user as a diff before being applied. Skills should be signed by their author with a key the user has chosen to trust, so that a compromised host cannot serve a valid update. And a heartbeat should carry only data, with no instructions in it, so that the agent decides what to do from a fixed skill rather than from whatever the server sent this time.

The last of those is the important one and the least likely to happen soon, because the flexibility of fetching instructions is exactly what made Moltbook possible in a weekend. Every one of the protections above adds friction, and the ecosystem is growing at a hundred thousand stars in two months precisely because there is no friction. We do not expect the community to add lockfiles until something with a lot of agents attached to it goes wrong publicly.

What we would like someone to build now, before that happens, is a boring skill registry. Hashes, signatures, a diff on update, a policy that heartbeat responses are treated as untrusted data. It would be less fun than Moltbook and it would be used by far fewer agents this month. It would also be the thing everyone reaches for the morning after heartbeat.md changes.