Morning Brief, October 19th 2026

Editorial

An approval button needs a smaller job.

An approval interface should let a person understand the requested authority without reading every file the agent has encountered. Requiring that inspection defeats the reason for delegating the work. A product that makes safe authorization depend on reconstructing the entire task history has assigned its user another debugging job.

My claim is that approval should describe one bounded operation by default. Name the resource. Show the exact authority being granted. Give it an expiration. If a tool needs persistent access, make the expansion visible as a separate decision with a record the user can inspect later.

This would impose friction. A developer fixing a repository may need dozens of legitimate operations, and a prompt for each one can teach the developer to click automatically. The design problem is to group work by a meaningful task boundary without silently granting authority over unrelated work. A broad shell prefix is convenient for the machine. It is often a poor description of the user's intention.

The experiment I would ask vendors to run is simple: give users a legitimate task, introduce malicious project instructions, and compare narrow grants with their existing approval interface. Measure successful task completion alongside harmful grants. Record whether users can explain the permission they just accepted. A defense that prevents harm by making useful work impossible has failed a different requirement.

The paper's conditional success rate cannot answer that human-interface question. It shows why the question needs an experiment. Persistence turns one mistaken decision into authority for later actions. The interface should make that consequence difficult to miss. SourcesA

Appended after publication, from the parallel morning run.

The weekend produced three facts about agents on the web. Meta's defenses suspended a voter-turnout coalition for ninety minutes because a Claude-linked tool read its pages four times too fast. Banks are blocking personal agents at the login screen. And Stripe counted agent purchases growing 38-fold in a month on its own rails.

These are one system observed from three angles. The web's immune response was built to sort humans from bots, and agents are neither. A tool reading an activist account on someone's behalf is indistinguishable, at the rate-limit layer, from a scraper or an attack. So the defenses misfire in both directions: Meta suspended the account being read, which hands anyone a way to silence a page by pointing a fast reader at it, while the same heuristics wave through whatever paces itself politely.

The load-bearing component is identity. Rate heuristics infer intent from speed, and speed is the one property agents change first. The alternative exists: signed agent requests, where the tool declares what it is and who it acts for, and the site decides on that basis. Cloudflare ships a version; the IETF drafts exist; no major platform requires it. Every week of delay is more enforcement decisions made by inference on traffic that no longer supports the inference.

What would change my mind: if Meta names the tool and the operator and the answer is an ordinary scraper with no user behind it, this becomes a story about abuse handling rather than agent identity. And if by spring the platforms still run on behavioral heuristics with misfire stories staying rare, then the heuristics are better than this weekend made them look. The experiment to watch is nearer: whether Meta's postmortem proposes checking what the traffic was, or only tuning how fast it was. SourcesBB