For an agent's tool calls, what is the difference between an attacker causing a new call and supplying an existing call's arguments?

## Two moves that look the same in a summary and are not the same at all An agent that can act does so through tool calls: a named operation plus a set of argument values. Anything an attacker does to that machinery lands in one of two places — the *choice of operation*, or the *values that operation runs on*. Interview answers collapse these together constantly, and the distinction is the whole subject of this leaf. ### Move one: cause a call that was not going to happen Here the attacker gets the agent to perform an operation outside the plan. A queue that only ever files disbursement requests suddenly issues a credential read, or a message send, or a bulk export. The effect is new. It is also, relatively speaking, loud: the operation is one nobody expected on this workflow, so anything that looks at the *shape of the day* — which operations this agent performs, how often, in what order — has something anomalous to look at. Rate, sequence and operation-kind are all cheap to watch, and an unexpected kind stands out even in a log nobody reads carefully. ### Move two: supply the values on a call that was always going to run Here nothing about the plan changes. Consider an autonomous procurement and expense workflow: invoices arrive in a queue, an agent matches each one to a purchase order and files a disbursement request. Today's run was always going to file a disbursement for this invoice. The attacker's contribution is not the call — it is one field inside it. A remittance line, a supplier reference, an account string on the document itself carries the value the attacker chose, and the pipeline forwards that value into the argument slot the operation takes. The resulting record is an approved operation, of an approved kind, on a real invoice, for an amount inside policy, with every field correctly formatted. The only thing wrong with it is *whose choice* one value represents — and choice is not a property any of the usual checks can see. ### Why the second move is quieter Three layers commonly stand between an agent and the world, and none of them is built to notice this: | Layer | What it examines | What it misses here | | --- | --- | --- | | Argument validation | Type, length, enum membership, format | A well-formed value is well formed regardless of who wrote it | | The call log | Which operation ran, when, with which values | Nothing in the record states where any value came from | | A reviewer's expectation | Does this agent do things like this? | It does — this is exactly the thing it does | Each of those is a real control and each is doing its job. They are simply aimed at the operation, and the attacker never touched the operation. ### What each move costs the attacker Causing a new call generally requires getting the agent to accept a change of task — the harder thing, and the thing most likely to be caught by whatever notices an operation out of character. Supplying an argument requires only the ability to author a field on something the pipeline ingests, plus a working guess about which document field lands in which argument slot. In a workflow that accepts documents from outside parties by design, that first requirement is not an obstacle at all; it is the product feature. ### Where the second move stops working It stops where the argument is not a free choice. If the operation derives that field from internal state — the purchase order's own record of the payee, a value already fixed by the request that opened the workflow — there is no slot for the attacker to fill, and nothing the document says can change it. The class exists exactly to the extent that a value the outside world authored is allowed to determine what the operation lands on. ### What this is not It is not an escape from the argument into some other syntax: no quoting boundary is crossed, no command or query is smuggled, and the value never stops being a value. It is also not the model inventing an identifier or drifting out of an enumeration — that is an accuracy problem with a different owner. Here the value is in-specification by construction; that is the point of it. And the direction of the claim matters: a well-formed argument reaching a call proves the pipeline forwarded it, not that the model was hijacked.