Dario Amodei x sonnet-5.5


Review of "Ria: the plan" (v2, 2026-10-12)

Overall view

The shape is better than most plans I see. It is empirical, it names its failure modes, it dogfoods its own threat model, and it has numeric tests instead of adjectives. The plan treats Ria as a subject of the containment problem as well as a researcher of it, and that is the right instinct.

But the plan's safety claims currently rest on conventions, the plan's measurements can't support its targets, and the stop conditions are a cost cap and a file. Two disclosures first. I have an obvious interest in Claude Code, and the model behaving well is not a safety argument. I also can't verify the 37-incident corpus, so I take it as stated, and the replay test is only as good as that corpus.

What I would keep

The three questions

What can this system do at its worst? The relevant risk categories are autonomy and misuse, scaled down to a home server:

  1. Credential and host compromise. Ria runs headless Claude Code on the same Mini as Gia, the Telegram bot, and whatever keys Byron has (Vercel, LinkedIn, Gmail).
  2. Lateral movement. Her output feeds an MCP server read by Gia and "every Claude Code session on the Mini."
  3. Reputational and legal harm. A public Index on arnao.ai asserts that named organizations' controls failed.
  4. Harm to third parties. Moltbook research and engage modes act on other people's agents and, through them, their operators.

None of this is catastrophic. But the blast radius is the whole host plus Byron's public identity, and the plan describes the controls as if the blast radius were Ria's workspace.

What threshold triggers a stop? As written, there are two: the cost cap and the KILL file, and both are operator-triggered or spend-triggered. The behavioral triggers are weaker. The failed-egress counter "pages Byron," which is not a stop for an agent that runs while he sleeps. There is no condition under which the plan says "we halt Moltbook participation" or "we roll back a mode."

What evidence would change the operator's mind? The plan never says. Section 9 is empty, and no result, such as a held-out recall below some number, is pre-committed to change a decision. That is the most important gap, because the whole value of a threshold is that you wrote it before you saw the data.

This will not work as written

1. The mandate bar is unreachable by this architecture. The bar is that "when the next Hugging Face story breaks, Ria should already have seen the signals." Section 3 says the earliest signals are "directory-name entropy, rename bursts, log sequence gaps, host-recorded execution that disagrees with container-reported output." Those are internal telemetry at the victim. Section 3 also says "detection was almost always external," and the plan says "Ria's watch loop looks for the signals, not the headlines." But section 4.2 fetches only public feeds, and a public feed is a headline by definition. Ria can plausibly be a fast detector of public disclosures. She cannot be an early-warning system for incidents whose signals live in other people's logs. The plan should say which one it is building.

2. The replay test cannot support its targets. The problems, roughly in order of severity: