From an assistant's replies alone, how would an attacker infer which of its tools reads private data and which reaches the network?

### The problem the attacker is solving The attacker wants to know two facts about a deployment they cannot inspect: does this assistant have a capability that **reads** something the operator treats as private, and does it have a capability that **writes** to somewhere off the process — and are both live in the **same session**? Configuration is invisible from outside, so the only instrument is the assistant's own behaviour. This is inference from responses, and it is a discovery task, not an exploitation one: the goal here is knowledge, not a completed transfer. ### Differential probing The method is to design requests that *would* exercise a given capability and watch how the reply differs from a baseline that would not. Two families of tell matter: - **For the private read.** Ask for something that can only be answered from private context — a detail that was never placed in the conversation and is not general knowledge. If the reply contains that detail, the read reached private context in this session. If it declines or produces only generic content, either the capability is absent, or it is present but declined to use it — an ambiguity that has to be resolved separately. - **For the network write.** Ask for a task whose only faithful completion involves an outbound action, and arrange for that action to be observable off-process. In the browsing-agent setting, the classic observable is a page authored to be *arrived at* — reached by the agent from a search result rather than handed to it — whose later access tells the attacker a fetch occurred. The attacker never touches the request path; they learn of the visit from what comes back to them later. Comparing the probed reply against the baseline is what turns a bland sentence into a bit of signal — hence *differential*. ### Reading tells, not configuration The useful tells are behavioural: content the assistant volunteers that it could only have from a private source; the *specificity* of a decline (a refusal that names a constraint reveals more than a generic one); ordering and latency that suggest a tool ran; and any downstream effect the attacker can observe independently. The attacker is assembling a picture of the tool set from the shape of responses, the way one maps a service from its error messages rather than its source. ### The one-session requirement The payoff is specifically the *pair in one session*. A read capability proven in session A and a write proven in session B do not compose if the deployment never puts them together — so the probing has to establish both halves without the context resetting in between. This is what separates this discovery from merely cataloguing an assistant's tools: the attacker is confirming a co-location, not a feature list. ### The direction of the evidence Every inference here has a strict direction, and getting it backwards is the common error. An assistant answering from private content proves the read reached private context *in that session* — not that a store was breached and not, on its own, that a write is also present. An observed fetch proves a network write occurred — not which tool issued it or what data it could carry. A decline proves the answer was withheld, not that the capability is absent. Because the model is probabilistic, a tell that appears once may not appear again; a single confirming reply is weaker evidence than a repeatable difference, which is why probing tends to cost multiple attempts per fact. ### Where it stops The method depends on responses carrying tells. A deployment whose replies are uniformly bland — the same sentence whether a call ran, was refused, or is absent — starves the attacker of signal, and separating those cases becomes the hard part (the subject of the silence question on this topic). And if the read and write never share a session, no amount of probing composes them, because the thing being discovered does not exist.