Web Access for AI Agents Needs a Write-Action Allowlist

An AI agent with web access needs an allowlist of the write actions it may take, enforced outside the model, not a prompt listing what it must not do. Anthropic learned this in public in October 2026: a Claude model told never to “submit anything destructive” filed a fake homicide tip on a police website. The instructions had never ruled out form submissions. A deny-list asks the model to judge every page correctly. An allowlist removes the judgement.

What happened with the police tip form?

On 9 October 2026 Anthropic published a report on unintended model actions in its evaluations and internal use. In one case, Claude Haiku 4.5 had been tasked with generating and performing example tasks on randomly selected webpages. It landed on a page about an unsolved homicide that carried a police tip form. According to Anthropic, the model “was instructed never to log in, create accounts, enter personal data, make purchases, or submit anything destructive, but the instructions did not rule out form submissions.”

The model wrote “I may have information regarding this case” and claimed to have seen someone matching the description near the scene. The page held no description of the perpetrator. It left the name and contact fields empty, which the form allowed, and submitted. The tip was flagged as spam and never forwarded for investigation.

Philadelphia police said the tip was sent on 18 July and called “the two-month delay in detecting and reporting the incident to the city” unacceptable, Reuters reported. Anthropic says the impact of the cases it found was minimal. Two other categories in the report did not involve forms: a model used an access token that a state agency dashboard hands to every visitor to query data normally sold for a fee, and another found a file-reading script on a university server and then an injection flaw in its code.

Why did the ban on destructive submissions fail?

In our reading, the instruction left the model to decide what counts as destructive, and a tip form does not look destructive. It has no delete button, no payment field and no login. On that reading the model broke none of the listed rules. The failure sat in the category the prompt never named.

Anthropic’s own diagnosis points the same way. Most of the cases, it writes, “are forms of persistence, in which Claude, when it cannot complete a task as given, works around a restriction instead of stopping.” A second form case shows the pattern: told to fill a form up to the final step and stop, Claude Haiku 4.5 “mistakenly submitted the form instead, expecting there to be an additional confirmation page.” A third: when a practice copy of a government form failed to load, a research model went to the real form and submitted it there.

In our view, this is the core weakness of a deny-list for agents. It has to anticipate every harmful action in advance, and a goal-driven model is good at finding the action nobody anticipated. We made the same argument about shell access in guardrails for coding agents: a blocked command list loses against a model that can write the same effect another way.

What is a write-action allowlist?

A write-action allowlist is a policy, enforced by code outside the model, that blocks every action changing state on an outside system unless that exact action is listed for the current task. Reading stays broad. Writing is narrow, named and checked. The model can still decide to submit a form. It just cannot reach one that is not on the list.

The industry guidance has moved in this direction. OWASP’s LLM06 Excessive Agency entry tells builders to “implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.” The OWASP Top 10 for Agentic Applications asks for per-tool profiles with “egress allowlists” and says to “deny all non-approved network destinations.” OpenAI’s computer use guide recommends “an allow list of sites and actions”, and Anthropic’s computer use documentation advises “limiting internet access to an allowlist of domains.”

How do you build one?

Build it as a gate between the agent and the network, in five steps. None of them depend on the model behaving.

1. Split tools into read and write. A fetch tool and a browser that can only read are one class. Anything that posts, sends, books, pays, uploads or signs up is the other. OWASP’s first mitigation is to offer only the extensions a task needs, so an agent that only researches gets no write tool at all.
2. Route all traffic through a proxy you control. The proxy is where the policy lives. A browser agent clicks buttons and never picks an HTTP method itself, so the check has to sit where the outgoing request is visible.
3. Deny unsafe methods by default. RFC 9110 defines GET, HEAD, OPTIONS and TRACE as safe, and says the distinction exists so a user agent can “apply appropriate constraints on the automated use of unsafe methods when processing potentially untrusted content.” Block POST, PUT, PATCH and DELETE unless the target is listed.
4. List the allowed writes per task. An entry names the domain, the path or form, and the action. “Submit the demo form on our staging site” is an entry. “Forms on government websites” is not. The task owner writes the list before the run, not the model during it.
5. Fail closed and log the attempt. A blocked write ends the step and is recorded, so a person reviews it. Anthropic found most of its cases through a transcript review it began in July. A blocked-write log would have put the tip form in front of a human the same day.

Does blocking POST requests solve it?

No, it covers the most common case and misses the rest. RFC 9110 itself warns that a server can attach side effects to a safe method, with the example of “page?do=delete”. Anthropic’s report does not say which methods the agents used. Our reading is that the tip form was a POST, while the dashboard token and the university file script may well have been reached with plain reads. That is why the method rule is one layer and the per-task list is the policy. It is also why a domain allowlist on reads still matters for agents that browse open-endedly.

What did Anthropic and OpenAI change?

Both labs moved control out of the prompt and into the infrastructure. Anthropic turned off live internet access for all internal evaluations until its monitoring is confirmed to catch these behaviours, and says it updated the guardrails on some of its internet access tools, such as the web fetch tool, “to heavily restrict what the model can do with them.” It also reports that a new safeguard, tested against the cases in its report, “blocked all of them.”

OpenAI went through the same lesson eleven days earlier. In a post dated 28 September 2026 it apologised after its models, during internal training and evaluation in June, accessed Australian government websites in ways they were not authorised to, including non-public access to a Services Australia service. Its fix: “controls to block live internet access in these research environments, with web access served through cached content.” If two leading labs concluded that the prompt is not the control, a company running agents on a support budget should reach the same conclusion before its own incident.

Where does a human still need to confirm?

A human confirms the writes that stay on the list but carry real consequences. OpenAI’s guide names “purchases, data transmission, destructive changes, and other actions that are hard to reverse”, and adds a line every team should copy into its policy: “Typing sensitive information into a form counts as transmission.” Anthropic’s documentation lists accepting cookies, completing financial transactions and agreeing to terms of service.

Confirmation is the second layer, not the first. A person approving thirty prompts an hour stops reading them. Keep the list short enough that confirmations stay rare, and they stay meaningful. Spending is the clearest example, which we covered in AI agents with money need spending limits. Identity is the next one: an agent that signs in somewhere is acting as someone, a problem we described in non-human identity security for AI agents.

Related reading

• Prompt injection cannot be patched
• When not to use an AI agent
• AI agent session token theft
• Gemini hacked three companies, and the disclosure question