Why can't a request filter at a forecast endpoint remove a behaviour a poisoned training record put into the weights?

## What a request-path control can and cannot see A control on the request path — a gateway rule, an input screen, a validator in front of the served model — has exactly one input: the request. It can decide, per call, whether the call proceeds. That is a complete answer to an adversary whose whole capability is sending calls, and it is a genuinely good one: it is fast to deploy, reversible, attributable per caller, and a refused call leaves no residue. It is not an answer to anything that already happened during training, and the reason is structural rather than a matter of tuning. ## Why the firing request is unremarkable When an adversary writes records that a training run consumes, what they are buying is a change to the learned function: on some region of the input space the model now behaves the way they wanted. Which region that is, is *their* choice, made before anyone was looking. Two consequences follow. First, the input that lands in that region is not malformed. It does not need an oversized payload, an odd field, a strange encoding or a suspicious caller. In the grocery-forecaster example, it can be an entirely legitimate forecast request for a particular region on a particular weekday — the kind the courier-staffing service sends hundreds of times a day. There is nothing for a rule to key on. Second, the defender does not know the condition. A filter is a pattern match, and to write the pattern you must know what to match. The adversary chose it privately; discovering it means recovering something about the learned function, which is a research exercise, not a gateway configuration. Any rule broad enough to be written without that knowledge is broad enough to refuse real traffic — and in this system, refused forecast requests mean the staffing service falls back to a guess. ## The tempting wrong answer, and what it actually gets you "We will handle it at the API gateway" is the answer a competent engineer gives, because for most of a security career it has been correct: the boundary is where you stop things. Here it is a category error. Compare what each control touches: | Control | Acts on | Reaches a train-time effect? | | --- | --- | --- | | Request filter or schema validation | The current call | No — the call is ordinary | | Rate limit, quota, caller revocation | The volume of calls | No — the effect needs no calls from the adversary | | Coarser responses (label only, no scores) | What the caller learns | No — that is a cost control on searching | | Retraining from an audited dataset | The weights | Yes, at the next run | | Rolling back to an earlier checkpoint | The weights | Yes, if you can date the contamination | The top three are all correct controls against an adversary standing *after* training. None of them is a defect. The defect is closing a train-time finding on the strength of one. ## Why the last two are the only real answers Retraining works because it rebuilds the function from data you have audited: the contaminated rows are excluded, and the fitted parameters no longer reflect them. It costs a full training cycle and a revalidation, and it is only as good as the audit — if you removed the rows you found and the adversary supplied more, the new run learns them again. Rollback works because an earlier checkpoint was fitted before the rows existed. It is faster than retraining, but it requires knowing *when* the contamination first entered a training snapshot. Without that date you are guessing, and a rollback that lands on a checkpoint trained on the same rows changes nothing while creating the impression that something was done. It also discards everything legitimately learned since that point, which on a demand forecaster means giving up weeks of genuine seasonal signal. ## Reading remediation text honestly This is where the distinction stops being academic. A finding that names a train-time root cause and then records a request-path remediation with no residual exposure is internally inconsistent, and the inconsistency is easy to miss because both halves are individually reasonable sentences. The responder's obligation is to write down, in the remediation section, that no request-blocking control could have removed this one — and to name what will, and when it takes effect. ## The one thing to keep straight The gateway is not useless and the answer is not "gateways don't help". The accurate statement is narrower and more useful: **a control on the request path bounds the request path.** Where the exposure entered through a different channel, it bounds nothing about that channel, and saying so early is what stops a fix from being declared that was never a fix.