A partner both files records that feed a demand forecaster's next training run and calls its live endpoint — how do those two entry points differ?
answer
- Two channels, two different remediations
- One is a request; one is a row
- A refused request leaves nothing behind
- The other needs no queries afterwards
- Ask what the weights already absorbed
basics
~20 sEntry point decides everything. A call to the live endpoint is one observable request that can be throttled or refused and leaves nothing behind; a record written before training is absorbed into the weights and outlives any single request.
solid answer
~50 sThey differ in what the adversary needs, what they leave behind, and what removing it costs. Calling the served forecaster is cheap and repeatable, but every attempt is a request: it is logged, it can be rate-limited, screened or refused, and a refused one leaves nothing behind. Writing records that land in the next training table is far harder access to obtain, but once the records are trained on, the adversary needs no queries at all — the effect lives in the weights and fires when someone else sends a perfectly ordinary request. That asymmetry sets remediation. An inference-time attempt is answered by a control on the request path. A train-time contamination is answered only by removing the bad rows and retraining, or by replacing the deployed checkpoint with one trained before they arrived — and neither of those is a rule you can deploy in minutes.
go deeper
Be ready to state the split in one sentence: sending the model inputs after training versus influencing what it learned before training. Know that the first is a request you can refuse and the second is already inside the weights.
An interviewer expects the mechanics: what access each position requires, that a refused request leaves no residue while an accepted training row does, and why deleting the row later does not change a model already fitted to it.
Show the operational consequence. Say which evidence exists for each case, which control class actually applies, and how long each remediation takes to take effect on the deployed model rather than on the dataset.
Own the framing that stage determines remediation cost. Be able to tell an owner that a control on the request path is the right answer for one class of exposure and no answer at all for the other, before anyone commits to a fix.
## The one distinction this leaf is about An adversary who does not own a model can stand in two places relative to it: **after training**, where the only thing they can do is send it inputs and read what comes back, or **before training**, where they can influence what the model learns from. Everything downstream — what evidence exists, which control can help, what "fixed" means, how long the fix takes — follows from which of the two it was. The running example here is a same-day grocery demand forecaster. It is trained on a table assembled from operational records, some of them supplied by integrated partners (store and inventory feeds), and the forecasts it serves are read by a courier-staffing service that decides how many drivers to book. One partner holds *both* channels: their records land in the next training table, and their systems also call the served forecast endpoint. When something goes wrong, the first question is which of the two they used. ## After training: the query channel This is the cheap channel. It requires no special position — just the ability to call the endpoint, which the product hands out on purpose. It is also the *loud* channel, and that is its defining property: - **Every attempt is a request.** It has a caller identity, a timestamp, a payload, a response. It appears in logs whether or not it succeeded. - **It is meterable.** Rate limits, quotas, per-caller pricing and coarser responses all raise the adversary's bill directly, because they need many calls to search for an input the model reads the wrong way. - **A refused attempt leaves nothing.** If the gateway rejects the call, the state of the system afterwards is identical to the state before. There is no residue. - **The effect is per-request.** One crafted input gets one wrong answer. To get a second wrong answer they must send a second request. So the natural remediations sit on the request path: refuse, throttle, screen, return less, revoke a key. They are fast — a rule can be live in minutes — and they are appropriate, because the exposure is a live conversation you are ending. ## Before training: the write channel This is the expensive channel to obtain. It needs a path into something the training run consumes — and in this example the partner already has one, legitimately, because they are integrated. That is the uncomfortable part: the write access is *authorized*. Nobody broke in. What that position buys is different in kind: - **The contribution is absorbed.** Once the training run consumes the rows, they stop being data and become part of the learned function. Deleting the rows afterwards does not touch the weights that were already fitted to them. - **No further contact is needed.** After the run, the adversary can go quiet. The behaviour persists in the deployed model without them sending anything. - **The firing input is ordinary.** Whatever the trained-in effect keys on, it arrives as a normal request. It is not anomalous by construction — the whole point is that it looks like traffic. - **The clock is the training cadence.** The write has no effect until the next run consumes it, and a correction has no effect until the run *after that*. Both directions are slow. ## The remediation asymmetry, stated plainly | Adversary stood | What they left | What removes it | How fast | | --- | --- | --- | --- | | After training, on the query channel | A logged request, and nothing else if refused | Refuse, throttle, screen, revoke | Minutes | | Before training, on the write channel | An effect fitted into the deployed weights | Retrain from an audited dataset, or roll back to a checkpoint trained before those rows | One training cycle, at best | This is why "we will handle it at the gateway" is the wrong answer to half the question. A gateway sees requests. It is the correct and sufficient answer for the query channel; it is structurally incapable of touching the second, because the request that triggers a trained-in behaviour is not distinguishable from legitimate traffic without already knowing what the adversary chose. ## What each channel lets you conclude Be careful about direction. A complete, unremarkable request log bounds the **query channel only** — it is evidence that nobody was searching your endpoint, not evidence that your training table was clean. Conversely, a dataset audit that comes back clean bounds what the audit looked for in the snapshot it looked at; it says nothing about a live caller probing the endpoint right now. ## What a candidate should actually say Name the stage first, then the consequences: what access it required, what it left behind, whether the adversary must keep acting, which control class can address it, and how long that control takes to take effect. An answer that says "an attack on the model" without saying *when the adversary stood there* has not answered the question, because the two cases share almost nothing except the word.
- Which of the two positions is harder to obtain, and does that make it rarer or just quieter?Write access ahead of training is much harder to obtain than the ability to call an endpoint, so it is rarer in general. But where a supply or integration relationship already grants writes, it is not rare at all — it is authorized. What it reliably is, is quieter: after the training run consumes the rows the adversary can stop acting entirely, so there is no ongoing traffic to notice.
- Every request to the forecaster is logged and nothing looks anomalous. What have you ruled out?Only the query channel, and only for the retention window you actually hold. A clean request log says nothing about what entered the training table before the last run. The input that fires a trained-in behaviour is an ordinary request by construction, so its absence from an anomaly review is expected rather than reassuring.
- Why does the same partner have to choose between the two channels at all?Because the payoffs differ. The query channel gets one wrong answer per call, with every call attributable to them. The write channel gets an effect that persists across every caller and outlives their involvement, but only takes hold at the next training run and cannot be steered afterwards. Cheap and immediate against slow and persistent.
One adversary rattles the door on every visit and is seen every time. The other altered the blueprint before the building went up, then never came back.
saying these in an interview costs you the question
- Calls both cases the attack without naming the stage
- Assumes partner-supplied training records are trusted because they are integrated
- Thinks input filtering covers both entry points
- Believes a train-time adversary must keep querying afterwards
- Treats a clean request log as evidence the training data was clean