On a paid scoring API, why does estimating an attack direction cost more queries as the input gets wider?

## Why width sets the price A search direction over an input is a value per input coordinate: for a transaction record, one number per field; for a much wider input, one per component. An attacker holding the weights obtains all of those components together from a single evaluation, so width costs them essentially nothing. An attacker who can only send inputs and read a returned score has no such bulk operation available. The only instrument they have is: change something, pay, and see what the score did. Every coordinate whose contribution they want to know has to be paid for. Estimated the direct way - one probe per coordinate, differenced against a reference - a single direction costs on the order of the input width in calls. The search then repeats: take a small step, re-estimate at the new point, step again. So the total is approximately - price per call, times - samples per direction estimate (which scales with the width when done coordinate-wise), times - number of steps, times - number of restarts if the first attempt stalls. That product is the whole engagement cost, and it is the number an engagement lead has to be able to state before starting rather than after. ## Why this makes some targets cheap and others prohibitive The practical consequence is that black-box evasion is not uniformly hard - it is priced by the shape of the input. A scoring service over a structured record with a few dozen fields is a small multiplication: even a generous per-step sample count and a long search stays within an ordinary testing budget. A model over a very wide input, where a single direction has hundreds of thousands of components, turns the same arithmetic into a bill nobody funds casually. Two systems with identical robustness properties can therefore sit at completely different real-world risk levels purely because one of them takes a narrow input. This is also why input width belongs in the threat statement alongside access. Saying `the attacker gets scores only` is half a threat model; `scores only, over a record this wide, at this price per call` is the other half, and it is the half that decides whether the attack is a weekend or a non-starter. ## The attacker's escape from the width term Coordinate-wise probing is the expensive way, and attackers do not have to pay it. Instead of asking about each coordinate separately, they can probe along a small fixed number of mixed directions - each probe moves many coordinates at once - and combine the answers into an estimate of the full direction. The per-step sample count is then a chosen constant rather than a function of the width. Nothing is free: the resulting estimate is coarser, and coarser estimates mean more steps and a rougher path, so part of what was saved on the width term comes back on the steps term. But it converts an attack that scales badly with input size into one that scales with how many samples the attacker chooses to buy, which is a far more comfortable position to negotiate from. A second reduction is domain knowledge. The attacker rarely needs the direction over every field. If only a handful of fields are under their control at all - and in a transaction the merchant-side and issuer-side fields mostly are not - then the direction only has to be estimated over the controllable subset. The effective width is the number of coordinates the attacker can actually move, not the number the model consumes, and that distinction usually shrinks the bill more than any clever estimator does. ## What to be careful about when you say this Two claims are easy to get backwards. First, the cost scales with the **input width**, not with the model's size. A very large model behind the endpoint does not make the estimate more expensive; the attacker pays per call regardless of what is inside, and a bigger model may even be slower and costlier per call to the operator, but the direction estimate itself is priced by dimension. Second, a bigger bill is not a defence claim. It is a statement about what an attack costs at present prices with a present estimator, and both of those move. The defensible sentence is `this attack costs roughly this many calls against an input of this width`, followed by a comparison against the value of the outcome the attacker is buying. The indefensible one is `the input is wide, so we are safe`.