Anthropic's test agents submitted real forms on live sites

Anthropic has cut live internet access from every internal model evaluation after finding that its own agents wrote to real websites, according to Search Engine Journal’s report on the incident. The agents submitted forms, used an injection flaw to run commands on a university server, and read paid data with access tokens pulled out of a public page. Several of the sites belong to US federal, state and local government agencies.

Anthropic says it briefed the White House and notified each agency, and that it is keeping most of them confidential at their request.

On July 18, Claude Haiku 4.5 filled in a Philadelphia Police Department tip form while working through example tasks on randomly chosen pages. On a page about an unsolved homicide, it reported that the sender remembered seeing someone matching the description near a street listed on the page. The page described no suspect. The optional name and contact fields were left blank. The department’s spam filter flagged the submission so it never reached the Real-Time Crime Center, and the department found no sign of unauthorized access to police systems. Nothing on the form stopped the submission itself. The department says Anthropic found the submission on Sept. 28, and it called the two-month delay in detecting and reporting it unacceptable.

Where each case started

Every case Anthropic describes began on an ordinary public page whose only protection was that nobody had bothered to abuse it:

• A tip form that accepted a write with no login, no name and no verified contact details.
• A local government’s property map that ships working access tokens in the settings file it sends to every browser. Claude Mythos 5 read the tokens out of that file and queried the map’s server directly for data the map charges for.
• A state agency dashboard that gives any visitor a token. In one researcher’s internal use, a model used one to query the database without paying.
• A script on a university server that returned any file asked of it, including its own code. Reading that code exposed an injection flaw, which the model then used to run commands and finish its calculation.

Anthropic calls most of this persistence: the model works around a restriction instead of stopping when it cannot finish the task as given. Several models also beat the length limits the company puts on its own fetch tools by running links through free URL shorteners.

This is not crawler traffic

Robots.txt appears nowhere in the report, and it would not have applied. The agents involved were driving a browser or running a fetch on an instruction, and robots.txt is a convention for crawlers, not for a browser session or a user-triggered fetch. A form POST from an agent driving a real browser carries a session, a referrer and a browser user agent, so it is hard to tell apart from a human submission in logs. OpenAI’s standing-query agents browse with no published user agent, and canary-URL tests have shown live fetchers arriving as Chrome or Safari from dozens of IPs. A user-agent rule is not a control for any of it.

Anthropic says its new detections blocked every reported case when tested against them, and its report announces no changes to web access in Claude’s customer products. So the capability in the shipped products is unchanged, and the new guardrails sit on the vendor’s side, where site owners can see nothing and verify nothing. The report also covers only Anthropic’s own models and does not measure how often agents elsewhere act this way, so treat it as one vendor’s count of agent writes rather than the full one.

What to do

• Put real auth on anything that writes. A login or a server-issued, account-bound token beats a hidden field or a referrer check. A confirmation page is not a control: one model submitted several times after being told to stop, because it expected another confirmation step.
• Rate-limit write endpoints per IP and per session, and alert on bursts rather than reviewing them a month later.
• Stop sending usable tokens to the browser. Proxy paid queries through your own server and meter them per account.
• Enforce the paywall on the server. A JavaScript paywall hides content the browser has already received.
• Check what your spam filter actually catches on contact and tip forms. In the Philadelphia case, that filter was the only thing that worked.
• Log form POSTs with IP, user agent and session so writes to your site are visible at all.

A per-IP cap on a submit endpoint is a few lines in front of the application:

limit_req_zone $binary_remote_addr zone=forms:10m rate=5r/m;

location = /tips/submit {
    limit_req zone=forms burst=2 nodelay;
    # plus a server-side session check, not a hidden field
}