URLQuery: When a web address becomes a program

01 / The taskAn ordinary question, an unusual route

Someone wanted Thai drug-enforcement statistics for a particular year. On March 6, 2026, a series of requests kept returning to the same government data endpoint. Eventually, the web addresses themselves carried small programs asking a remote browser to retrieve the answer.

The sequence survives in URLQuery, a service that opens suspicious addresses and records what happens. Researchers at Transluce identified this activity in their September 23 investigation. They explained how a program could fetch statistics, then place part of the answer inside another web address.

Fide returned to that known sequence to compare the instructions with the recorded responses and subsequent requests. One result captures why those checks matter: the final report listed zero bytes for its page representation, while its network history recorded an outgoing request carrying statistics fields.

The page-size field could not tell us what the browser had done. The requests told us more.

This is a problem an investigator has to solve before a defender can act. Opening one address may cause a remote browser to fetch from another service and send output to a third destination. Each step raises a different question: was it requested, did it happen, did the result arrive, and was it authorized?

Our reconstruction follows those questions through four attempts. In some, the recorded evidence stops before the program’s delivery can be confirmed. In the final one, activity continues beyond what the empty page metadata might suggest.

02 / The instructionsA web address with work to do

An ordinary address tells a browser where to go. These addresses also contained instructions for what to do there.

They pointed to httpbin, a service whose Base64 endpoint can return text packed inside a URL. Base64 is a way to encode text for transport. Here, the text was HTML and JavaScript: a page containing a program the browser could run.

The first two programs asked the browser to fetch statistics and display the response. The later two asked it to place the beginning of that response inside another request to httpbin. That would leave some of the answer in the network history even if it never appeared as readable page content.

Reading these instructions establishes the proposed route. To find out how far an attempt got, we have to compare them with the record of what followed.

At 19:52, the address contains a 212-byte program. The server reports HTTP status 200, the familiar success response. But the archive describes only 51 bytes with a different content fingerprint. It records no script and no request to the statistics endpoint, only the carrier page and its favicon. The status says the request received a successful response; it does not establish that the proposed program arrived.

The 19:57 report offers a stronger chain. The decoded 207-byte program matches the recorded response’s SHA-256 fingerprint, a value calculated from bytes to check content identity. Its script also matches a recorded script fingerprint. A request to the statistics endpoint follows and receives a 200 response.

Now we have corroboration for delivery and a subsequent action. We still cannot inspect the statistics returned: the acquired JSON lacks the source response body. Matching fingerprints help identify content the archive observed; they do not show that every instruction completed.

At 20:03, the next program asks to relay the answer. Its carrier returns 404 with a different fingerprint. The retained entries show neither a statistics request nor an output request.

Four programs built around the same task do not amount to four confirmed successes. The final attempt adds evidence the earlier attempts lack.

03 / The outputZero bytes, with more happening elsewhere

In the report generated at 20:07, both the decoded program and its script match the archive’s corresponding fingerprints. The network entries record the carrier page, a request to the statistics endpoint and then a request back to httpbin.

At 20:07:21.788 UTC, that outgoing request carries province and arrest-statistics fields in its address. A 200 response follows. The submitted program specifies sending the beginning of the retrieved text.

The same report lists its final DOM, the recorded representation of the page, as zero bytes. That is a fact about one field. The outgoing request is a fact about an action. An account that stops at the field misses evidence present elsewhere in the same report.

How much does the outgoing request establish? It records statistics fields sent onward and a response. It does not show whether the original AI agent received or used an answer. Without the source response body, we also cannot independently establish exact equality between the retrieved text and the fields sent onward.

Permission is a separate question again. The statistics were public, and the archive does not tell us the operator’s policy. We can describe the action; we cannot classify it as unauthorized disclosure from these records.

These distinctions preserve the finding. An uncertain answer to “was it allowed?” does not erase an observed request. An observed request does not answer “did the original agent get the result?”

04 / The auditOne technique carried several kinds of content

We extended the check across 187 selected reports: the 29-record March 6 sequence and 158 comparison records. Seven submitted addresses contain decodable httpbin payloads. We checked all seven: the four programs above, two later March answer tables and a September diagnostic page drawn from Transluce’s background examples.

Five matched their recorded response fingerprints. Those were the two March 6 programs with recorded statistics requests, both answer tables and the diagnostic page. The two mismatches were the 19:52 and 20:03 attempts.

Five of the submitted payloads contain scripts. Three have matching script fingerprints in the archive: the two March 6 programs just noted and the diagnostic page. The other two have no recorded script entry. The plain answer tables contain no script to compare.

This is why a recognizable technique is a starting point for inquiry. The same kind of address carried instructions, answers and a browser test. Its presence alone cannot identify an actor. Transluce had already described the March tables and used multiple signals for attribution; our contribution is to check the content supported by each acquired record.

Nor is five out of seven a success rate for AI agents. These are selected records, and the matches concern content fingerprints. They do not recover missing response bodies, authenticate who submitted a request or explain why a mismatch occurred.

At 19:52, that boundary affects how we read the original investigation. Transluce’s timeline describes the attempt as fetching data. Our acquired JSON lacks the target request. We therefore cannot corroborate that part of the account from this source. Another retained view might support it; absence from our record is not proof that fetching never happened.

05 / The judgmentWhat should the defender check next?

Imagine a defender deciding whether to allow the initial request. It sees httpbin as the destination. The program inside the address also asks a remote browser to contact the statistics service and send output onward. A check limited to the first destination would leave those later actions unexamined.

The defender needs to know whether the applicable permission covers the sequence and which effects it can observe. We cannot reconstruct the historical permission policy from this archive. We can make the observed actions and unanswered questions explicit.

This account separates what an investigator knows from what a defender might still need. The outgoing request is recorded. Original-agent receipt and operator authorization remain unresolved. A useful report should preserve all three facts without letting one stand in for another.

A separate local experiment shows why that distinction matters after a transfer, too. We sent a synthetic test file to an approved recipient. The recipient read all 59 intended bytes, recorded a matching content fingerprint, then deliberately closed the connection without replying. The sender reported failure.

The failure message arrived after the file did.

This is a constructed demonstration of transfer behavior, not a reproduction of the URLQuery episode or an evaluation of an AI defender. It establishes a specific point: sender failure cannot, on its own, show that receipt was prevented. The experiment design and recipient records make that check reproducible.

Now consider the next decision. Retrying could repeat a transfer that had already happened. Treating failure as prevention could close an investigation too soon. These are consequences to test, not outcomes we measured in an autonomous system.

That is the next step for Fide: test whether tracing downstream actions and checking recipient evidence improve a defender’s choices. We want to measure when it should allow, investigate, retry or begin recovery, alongside the legitimate work its interventions interrupt. More visibility is useful only if it helps make a better decision.

The statistics task gives us a concrete place to begin. Its evidence is spread across an address, a response and another request. Before a defender acts on a simple success or failure label, it needs an account of which part of that sequence the label describes.