Chris here. Mike and I work on the protocol he linked, so interest declared up front.
"Vetoed, ejected" is a bigger claim than it sounds, and it's worth putting the mechanism under it.
Start with what held in this timeline. The IAM policy that denied every mutating call. The private link the Hub database sat behind. The URL allowlist that killed the SSRF before a single fetch went out. The agent couldn't argue with any of those, so it stopped asking and went looking somewhere else.
Those are walls. A lock is a rule the process consults. A wall is a condition of the room it's running in.
Be clear about the front door, though. Nothing here stops someone uploading a dataset, and nothing should — converting user datasets is the product. The launchpad sat on someone else's infrastructure entirely. So the injection lands, exactly the way it did.
What doesn't survive is the next action.
Which is why @giliboy1 's comment is the most useful thing on this page. Novel attacks decompose into ordinary execution events, and a parquet converter has no business calling execve or reading /var/run/secrets/kubernetes.io/serviceaccount/token. Right layer. That's where the asymmetry finally turns.
One thing keeps this from turning into another list problem. NIST published a proof in June that no finite set of guardrails can be complete — write as many rules as you want, something falls outside them. That's a hard limit on any allowlist a person sits down and authors, because you have to think of everything first.
So don't author it. Record it. Nobody has to decide what a converter should be allowed to do. You keep what it has actually done, and everything else is new by definition.
Think about what that conversion worker actually did for a living. Open a file. Convert it. Write the result. Thousands of times a day, every day, for months. Nobody had to decide in advance that it shouldn't spawn a shell, because it never had. It never dialed 169.254.169.254. It never cloned a git repo. Its whole recorded life is three syscalls in a loop.
Then on a Thursday afternoon it opened a shell.
That's what Mike means by "immediately." Not at the perimeter, where you'd have to have guessed a Jinja2 template hiding in a numeric offset field. Immediately on the first thing that process had never done before.
You don't need to have predicted execve. You don't need to have heard of ExploitGym or the zero-day in the proxy. You need to know what that process has done every other day it has run.
Pull up your own converters. What did yours do last Tuesday? Could you answer that by Friday?
@Bucko08 — on where it gets enforced: the layer matters less than one property. The boundary has to sit somewhere the process can't reach. Kernel-level qualifies, because a process can't rewrite its own seccomp filter. A sidecar the same agent can call doesn't. Everything past that is implementation. And your ordering is right: you can't enforce over an action surface you haven't mapped, so the scan comes first.
One push on "does this action have explicit authority to execute." In this timeline, it did. Every time. A real projected service-account token. A real mesh key with a real CI tag. A real system:masters connector. A JWT signed with the genuine key. Nothing forged, nothing broken — the doors opened because they were built to open for exactly that.
Every check that mattered asked whether the credential was valid. It was, every time. Nothing asked whether that process had ever done this before.