In a transcription API that skips a heavy second decoding pass on confident audio, what does that shortcut hand an adversary?

## The shortcut, and the assumption underneath it A transcription pipeline that runs a cheap first decoding pass and consults a confidence check before deciding whether to run a heavier second pass is doing something entirely sensible. Most audio in a call-centre corpus is clean; spending the heavy pass on all of it would roughly double the compute for a small accuracy gain. So the pipeline spends work in proportion to how hard the input looks. The assumption buried in that design is **that the inputs arriving are drawn from the distribution the design was tuned against**. Costing, capacity planning and pricing all inherit that assumption. It holds for customers. It does not hold for someone who is choosing their inputs. ## What the adversary actually gets They get a number: the ratio between the work consumed by the most expensive input the interface still accepts and the work consumed by a median input. Call it the amplification. If a median call costs one unit and the worst admissible call costs twelve, then one attacker request is worth twelve ordinary ones — bought at the price of one, because the service bills audio minutes and the cost driver is compute. That ratio is a property of the pipeline, not of the attack. It came into existence the moment two paths of different cost were selected by something the client influences. Nobody chose it deliberately; it is a side effect that was never measured because friendly traffic never exercised it. ## The lever is the input-dependence, not the confidence score A common wrong turn is to treat the confidence signal as the vulnerability and propose hiding it. The client never sees that score, and does not need it. Their feedback channel is their own wall-clock latency and their own invoice, and even that is optional: the published input rules already bound what the most expensive admissible request looks like. The exploitable property is that **compute depends on the input at all**, plus the fact that the interface accepts inputs from the expensive region. That generalises well beyond speech, and an interviewer will usually push you to generalise it. The same ratio exists wherever a prediction path branches on the data: | pattern | the cheap case | what the adversary picks | | --- | --- | --- | | early exit on confidence | shallow answer accepted | inputs the gate never accepts | | cheap-model-first cascade | the small model answers | inputs that always escalate | | iterate until converged | converges in a few steps | inputs near the iteration ceiling | | variable-length processing | short items | the longest admissible item | Note what is *not* on that list: nothing about how to construct such an input. The properties that push a particular pipeline onto its expensive path are implementation detail and not the point. The point is that such inputs exist inside the interface's own rules, and that finding them costs an attacker only patience. ## The limit the adversary works under This is the part candidates skip, and it is the part that makes the finding actionable. Their constraint is not a perturbation radius; it is: - the input must remain **admissible** — format, duration cap, any content screening; - the pipeline's own ceiling on **forward passes per prediction**, if one exists, bounds the top of the ratio; - their **request count** must stay ordinary, or they lose the property that makes this hard to see. Everything they gain sits inside those three. Which is why the honest way to report this is as a measured ratio rather than as an adjective: *the worst request this interface accepts costs us N times the median, at the same price.* That single number turns an interesting observation into something a capacity owner and a pricing owner can both act on. ## Why the shortcut is still correct engineering The conclusion is not "remove the early exit". Input-dependent compute is how these systems are affordable at all, and removing it means paying the worst case on every call — which is precisely the outcome the adversary was trying to force, delivered voluntarily. The conclusion is that the ratio must be **known and bounded**, and that the interface's admission rules and the pricing unit are where it gets bounded, not the model. ## What an interviewer is listening for That you identify the average-case assumption and say why an adversary is not bound by it. That you express the gain as a ratio rather than as "it gets slower". That you resist the reflex of hiding the confidence signal. And that you recognise the pattern in a pipeline that has nothing to do with speech.