Your logs show a few thousand tightly clustered full-precision queries to a small risk regressor — did someone solve for its weights or merely sample it?

## The chair you are sitting in You are the incident responder reconstructing from access logs what somebody actually walked away with. The target is a small equipment-failure-risk regressor served to industrial customers over turbine and pump telemetry: engineered sensor features in, one real-valued risk score out. One account has made a few thousand calls in a pattern that looks odd. The question your organisation wants answered is not 'was there abuse' but **what does that account now hold**. ## Two hypotheses that leave different footprints **Hypothesis A — they were building a training set** for a fitted stand-in. The footprint of that is volume and breadth: many calls, inputs spread across the range of plausible telemetry, coverage of the space that the copy needs to be good over. The attacker is indifferent to how precisely each score is reported, because rounding a supervision target barely hurts. Volume tends to be large, and often spread over more than one identity. **Hypothesis B — they were solving for parameters.** The footprint is the opposite in nearly every dimension. Total volume is modest — thousands, not millions, and unremarkable against ordinary usage. The inputs come in tight families: near-identical points that differ minutely in one feature, walking along a line, revisiting narrow neighbourhoods repeatedly and then jumping elsewhere. There is no attempt to cover the input distribution, because the attacker is not trying to learn what the model predicts on realistic data; they are trying to localise where the computed function bends. And the whole exercise is worthless without the low-order digits of each returned number. So the discriminating observations are: **step size between related queries, whether the input set covers the domain or clusters in threads, total volume, and how many digits you actually returned.** ## The precondition you check before you believe hypothesis B The solve is only on the table for a model that is small and built from piecewise-linear units, and where the reply carries many significant digits. Check those three facts about the served model before you write anything down. If the served model is large or deep, the same clustered pattern is much more likely to be something else, because the query and precision cost of a solve climbs steeply with width and depth. That check is what turns a suspicious pattern into a supportable hypothesis or dismisses it. ## Say precisely what the log can and cannot establish This is the part that separates a senior answer from a plausible one. Direction of claim matters: - The log establishes **what was asked and what you returned**. That is an upper bound on the material available to them. - It does **not** establish what they computed from it. Solving happens offline, on data you already handed over; nothing about success or failure comes back through your service. - A clean-looking log does **not** establish that nothing was taken. The volume this attack needs is small enough to be unremarkable, and it can be spread across sessions or identities. - The pattern is **not** unique to an attack. A careful customer doing sensitivity analysis — nudging one sensor feature to see how the risk score responds — produces something that can look similar. Attribution needs more than the shape of the traffic. ## What the finding should say Write the exposure, not a verdict. Something with the shape of: this account received N replies at full numeric precision against a model of this size and structure; that combination is sufficient material for a parameter-recovery attempt, which if successful yields a functionally equivalent model, identical up to permutation and rescaling of hidden units; the traffic pattern is consistent with such an attempt and also with legitimate sensitivity testing; we cannot determine from our side whether the solve was performed or succeeded. And then the forward-looking part, framed honestly: the protection for anything of this size and reply width is **cost and precision, not secrecy**. If somebody asks 'can they get our weights', the correct answer is not 'never' — it is a statement about what it would cost against this specific model, with the awareness that a smaller shipped model or a wider numeric contract moves that line. ## The trap The common failure is to reason from volume alone: a few thousand calls looks like nothing next to the millions people associate with model stealing, so the incident gets closed. Volume is the wrong axis for this attack. The axis is how much of each answer went out, and against how small a model.