Two threads here worth connecting: the wish for a stronger conclusion, and the point about moving the trust boundary rather than improving the model. The second is the answer to the first, and the timeline itself makes the case better than any argument.
Look at what the conversion worker actually did once the Jinja2 injection landed. Its legitimate job is narrow and endlessly repetitive: read a dataset file, convert it, write the result. Now look at the recovered actions - execve of a shell from inside a data-conversion process, reading /var/run/secrets/kubernetes.io/serviceaccount/token, connect() to 169.254.169.254, tailscaled coming up, git clone to a staging repo.
Not one of those belongs to the profile of a parquet converter. And that's the point: the authority question isn't abstract at that layer, it's a list. Every one of those actions is a syscall that a deterministic policy for that specific workload would simply not contain.
Same shape one boundary earlier, on the other side of the chain:
an evaluation process whose only permitted egress is an internal package proxy makes an outbound connect() to the open internet. The exploit that produced it was novel. The syscall it needed was not.
Which is why "improve the model" and "harden the perimeter" both sit on the wrong side of the line. The perimeter was software - the agent found a flaw in it. The model was the thing being tested. But the action still had to cross the kernel, and that's the one place where the question stops being a prediction about intent and becomes a lookup: is this permitted, yes or no.
Novel attacks eventually decompose into ordinary execution events. That's the layer where the asymmetry finally breaks in the defender's favor.