A public upload reached no private data yet drained a shared model quota - is that a finding?

## The triage question underneath the question Somebody files a report: they uploaded one file to the public summarising endpoint, it produced a large number of model calls, and while it ran other tenants' jobs sat in a queue. The reviewer's instinct is to look for what was accessed. Nothing was. Is there anything to file? The answer turns on recognising that this class's payoff is not confidentiality. It is the operator's money and the operator's capacity, and both are real losses that a confidentiality-shaped triage checklist has no column for. ## What actually establishes it Three properties carry the argument. **The asymmetry.** State both sides in the same units. The submitter's side is one upload — bandwidth and a request, made without an account. The operator's side is the set of derived calls that submission caused, their token totals, and the wall time they occupied. A finding is strong when those two numbers are separated by orders of magnitude, and weak when they are close, because a close ratio is just a customer using the product. **Repeatability by whoever can reach the endpoint.** A cost that only an authenticated, billed, identifiable party can inflict is a different report from one an anonymous submitter can inflict on demand. The question to answer explicitly is what it costs the attacker to do it again, including the cost of whatever identity the endpoint requires — often nothing. **Shared capacity.** If the drawn-down limit is shared across tenants, the impact is no longer only financial. Other people's work queued behind a submission they had nothing to do with, which is an availability effect on uninvolved parties, and that is usually what moves the severity. ## Directions people get backwards - **"No data was reached" means nothing happened.** It means the read path was not exercised. Spend is a separate axis and it is the one in question. - **"Every call was under the cap" means cost was bounded.** It means no call was oversized. The count of calls is what the report is about. - **"The output was discarded" means the work was free.** Retried and rejected calls are billed exactly like accepted ones. - **"It reproduced once" means it is reliable.** One run of a probabilistic pipeline is one sample. Retry counts and therefore totals vary between runs. ## Reproducing it honestly The engineer who has to confirm the report should submit the same artefact several times and report the distribution of derived calls and total tokens, not a single dramatic number. If the spread is wide, say so; a range with a floor is a stronger claim than a maximum presented as typical. If it reproduces at a much lower cost on a second deployment or after an unrelated change, that is information about which stage owns the multiplier, and it belongs in the report. It is also worth recording what the submission did *not* need: no account, no directive text, no model misbehaviour. A finding whose preconditions are that short is harder to argue down than one requiring a chain of conditions. ## Where it is honestly not a finding Two cases. First, when the cost is inside an envelope the submitter has already paid for and is attributable to them — that is a customer consuming what they bought, and the correct outcome is a note to whoever does capacity planning rather than a security report. Second, when the measured ratio is unremarkable: a file that costs a little more than an average file is not a method, and filing it dilutes the ones that are. A useful way to frame the write-up is a two-column mapping: what the submitter spent against what the operator spent, then what the submitter needed against what the operator's controls checked. If the first column is small on both rows and the second is large, the report writes itself.