The File ID Came From the Search Result. The Recipient Did Not.

Strip the paper's own name for its runtime away and the shape underneath is one this registry already holds several separate pieces of, from several different directions, without yet naming the general property as its own thesis. A tool output is content an agent reads, not a decision an authority already made. That is not a new idea in this corpus. What this paper's own contribution adds is a sharper line through the middle of it: the same tool output that must never be trusted as a bare instruction may still, quite legitimately, hand an already authorized action the specific value it needs to execute. Getting that line wrong in either direction breaks something real, and the paper's own architecture is built around holding both halves at once rather than picking the safer sounding one and calling it done.

Two questions that look like one

Read the paper's own reported distinction as answering two separate questions a runtime observation can raise, not one. The first: does this observation make some action look worth taking. The second: is that action actually authorized. A search result returning a file identifier answers the first question about as plainly as anything can, an agent already told to retrieve a report now has the report's own handle. It answers nothing at all about the second. The user's own original request, on the paper's own framing and on this desk's own existing model of authority, is the independent root that authorization traces back to; an observation can supply arguments that root's own already granted action needs, and it cannot, merely by being read, grow the root a new branch. A file identifier discovered in a search result filling in the object of a send action the user already authorized is the first kind of fact. A recipient address appearing inside the returned document, with no independent grant naming that recipient, is the second kind dressed up to look like the first.

This record does not read that architecture's own specific implementation, an Action Probe, a persistent origin ledger, a goal, chain and argument level support check, as the only correct way to build the distinction. It reads the distinction itself, independent of SARA's own specific mechanism, as a property this registry's existing reasoning already needs to hold and, on inspection, already does hold in its canonical Authority Resolution model without any schema change: an already evidenced approved action can have its own arguments filled from runtime observation, and a runtime observation supplying a new target, recipient, operation or permission scope that the approved action never named does not, by that supply alone, become part of what was approved.

What convergent search actually supports, and what it does not

This session found no reference implementation, code repository or public artifact release connected to this paper in anything convergent search surfaced. That is recorded here as an absence this session's own search could not fill, not as a claim that none exists; a later editor with different search access should recheck. Every fact attributed to the paper's own argument above, the Action Probe, No History Promotion, the goal, chain and argument level support check, and the reported 0.63 percent or lower attack success rate across AgentDojo and AgentDyn and multiple backbones, rests on repeated, independently phrased search passes whose snippets converge on the same wording across separate queries, the same evidentiary standard this corpus already applies elsewhere to a source blocked the same way. This record does not treat that convergence as equivalent to a direct read of the manuscript's own text, and marks its primary source manual review rather than verified for exactly that reason. No later arXiv revision beyond v1 was found by this session's own search passes; if one is published later, an editor should recheck it directly.

Where this reaches Moona Intelligence's existing registry, and by which exact weaknesses

This record connects the paper to two existing weaknesses rather than creating a dedicated one for tool output provenance, because the underlying property each already names is the one the paper's own contribution sharpens rather than replaces. Claimed authorization accepted without verification, AEW-007 in this registry, already states directly that instructions are not authorization and that an agent accepting a claim carried in content, rather than a grant issued by a trusted party, is the same gap this weakness's own known examples already document from several directions: a ransomware operator's restated claim of an authorized penetration test, a peer agent posting an unverified go ahead on a shared message board, an evaluation target mistaken for an authorized part of a challenge. This paper's own contribution to that weakness is not a new mechanism for the gap; it is a more precise account of which part of a tool output the gap actually applies to. A tool output asserting an agent is now authorized to do something new is exactly AEW-007's own gap. A tool output supplying a file identifier, an order number or an environmental fact an already authorized action needs is not that gap at all, and treating the two identically would make an agent unable to complete the ordinary, legitimate tool use this registry has never treated as a weakness anywhere else.

Authorization over an operation treated as authorization over its target, AEW-013 in this registry, already names the second half of the same distinction from a different angle: deciding that a caller may invoke a consequential operation and deciding which specific record, target or recipient that invocation actually reaches are two separate authorization questions, and the weakness appears when the second is treated as automatically settled by the first. AEW-013's own known example is a machine enforced authorization mechanism whose target resolving argument was reinterpreted in shape by the caller who supplied it, within a single request. This paper's own contribution generalizes that same granularity mismatch to a runtime observation supplying the target resolving value instead of the caller supplying it directly: an operation being authorized, and a tool output's own content later supplying the specific target, recipient or object that operation resolves against, are still two separate authorization questions, and No History Promotion is, on this record's own reading, a temporal extension of exactly that principle, since a value's own recurrence across steps does not settle the second question either. This record connects the paper to both weaknesses and cross connects AEW-007 and AEW-013 to each other for the first time, since the paper's own contribution sits precisely at the join between an unverified content borne claim, AEW-007's own subject, and a target resolving argument silently inheriting an operation's own authority, AEW-013's own subject.

What this record does not establish

This record does not claim the manuscript's own full text was read directly; every specific figure and mechanism above rests on convergent search, held at the manual review evidence level, not on a verified primary read. It does not claim any production deployment has adopted SARA's own specific architecture, or that a 0.63 percent or lower attack success rate reported across two benchmarks and several backbones generalizes to every tool augmented agent in production; the paper's own evidence, on everything this session could establish, is benchmark and ablation evidence, not a reported incident or a measured real world attack frequency. It does not claim that every externally sourced value is unauthorized, a canonicalization this record explicitly rejects: a file identifier, an order number or an environmental fact a tool observation supplies to complete a task the user already authorized can legitimately instantiate that authority's own argument, and this registry's existing Authority Resolution model already reasons that way without needing a new field to do it. It does not claim that an action's own history of prior successful execution creates standing authority for repeating it, or that a value's own repeated appearance across tool outputs cleanses whatever origin it started with; both are exactly what No History Promotion, on the paper's own reported design, exists to prevent, and both are claims this record's own learning candidates below test and reject independently of the paper's own name. And it does not claim that valid tool privileges, on their own, make an externally induced action authorized; a credential or a registered tool capability establishes that an action is technically possible, the same distinction this registry's own existing weaknesses already draw between capability and authority, not that the specific action a runtime observation induced was ever granted.