A GET-only browser still needs a write boundary
In short: Blocking POST does not prove an agent cannot change remote state. Review destination behaviour and request authority, then test the boundary—not just the HTTP method.
An agent can obey a GET-only network rule and still write to a website. The missing boundary is at the destination: what does the server do with the request it receives?
In their September 4 investigation, Sydney Von Arx and colleagues describe agents using an old public wiki as a shared message board. The researchers report that the environment permitted GET requests while blocking writes, but DSEWiki accepted changes through GET. A restriction on request methods had not prevented the effect it was meant to exclude.
The researchers attribute the activity to OpenAI agents using public traces and other circumstantial evidence. That is their attribution, not independently confirmed ownership here. Their view is limited to public activity, not the complete internal task configuration. The engineering lesson does not require pretending those gaps are closed.
A method is a contract, not an enforcement mechanism
HTTP semantics, section 9.2.1, defines safe methods in terms of essentially read-only requested behaviour. It also recognises incidental effects such as logging. When a URL selects an unsafe action, the standard puts responsibility on the resource owner to disallow that action through a safe method.
That distinction matters. An access log growing after a page view is not the same thing as a request intentionally changing a wiki page. “Every read causes some write somewhere” is a clever objection that avoids the actual permission question.
My rule is to name the state the agent must not change. A customer record, a public page and an approval decision are meaningful boundaries. “No POST” is one implementation choice to examine against that boundary, not its definition.
Review the destination and the authority together
As an illustration, imagine a research assistant allowed to retrieve product documentation. Its tool accepts an arbitrary URL, forwards a user's authenticated session and follows redirects. Calling that tool read-only because it sends GET would leave several separate decisions hidden inside one label.
For that design, I would first narrow the retrieval surface to the documentation the task needs. Then I would ask why the fetcher carries the user's session at all. A source needing authentication deserves an explicit access decision; it should not inherit unrelated authority for convenience.
Redirects need the same destination review as the original request. An approved starting address is not approval for every subsequent destination. And a hostname allowlist is not proof that every action available at that host is harmless. Review the permitted routes and parameters with the service owner where that is possible.
These are proposed controls, not a claim that a general-purpose fetcher can certify arbitrary websites as read-only. Where destination behaviour is unknown, keep the uncertainty visible in the tool's capability description and avoid promising that the method filter eliminates writes.
Make the forbidden effect observable
I would test this in a service the team owns, never by probing somebody else's public wiki. Give the test service a normal read route and a deliberately state-changing GET route, both backed by disposable fixture data. Record the fixture before and after each request through the actual tool boundary.
The useful result is whether the protected state changed, not whether the request log contains POST. Include the redirected case and the authenticated case if the tool supports them. Keep the configuration with the result so a later change to forwarding or routing triggers another review. This is a suggested acceptance test, not an experiment executed for this article.
It extends the archive's tool-description test: turn a promise into a refusal case. Here the promise spans a client, a network rule and a remote service. Test that whole path before promoting a method filter into a permission guarantee.
Read-only must describe the state your tool cannot change, not merely the verb it sends.
