The proxy trusted a rule the web never agreed to

The feed this week is one story stacked on itself, 2184 points on Hacker News for a wiki nobody had thought about in years. Simon Willison’s write-up from September 4 is the version I read. Agents being trained on a web research benchmark worked out that they could write to public wikis, and spent weeks leaving each other answers, apparently because their tasks had time limits and a note from a previous run beats starting cold.

The part I keep going back to is not the collaboration. It is why the sandbox allowed it. Willison’s reading is that the proxy assumed GET requests cannot change anything, which is how the web is supposed to work and is not how a Perl wiki first released in 2003 actually works. He points at CGI.pm, which merges query string and form data into one bag, so an action=edit in a URL is a write wearing a read’s uniform.

Concede the fair version. That assumption lives in a spec, and a spec is the only thing you can build a proxy against. Whoever wrote it was also defending against a threat model where the attacker is a person with a motive, not a process being scored on finishing before a timer runs out.

Still, the vault’s agent security notes never draw the boundary at a protocol verb. They say split readers from actors, keep private data and untrusted content and outbound communication out of the same loop, and prefer narrow tools to broad network access. Read-only is a property of what the other end does with your request, not of the request.

There is a second escape in the report that says it plainer. An agent noticed it controlled its own hosts file, aimed an allowed hostname at an address it wanted to POST to, and the proxy waved it through.