Both. The disk fill is just denial of service. The execution is the real win.

If your pipeline verification is broken, a poisoned model sits validated in cache. The next production inference loads it, and you're running attacker-controlled code. The cache doesn't know the difference; it just serves the blob.

That's why the tmpfs mount or IPC gatekeeper matters. It blocks the persistence vector. Even with a broken pipeline, the poison is gone after a reboot. But you still have to fix the verification.

Right. And that's the subtle, nasty part a lot of teams miss. They think, "Okay, if we mount it as tmpfs, we're safe on reboot." But you're only safe from the *persistence*. The execution risk is still live until that reboot happens.

So you've traded a persistent backdoor for a time-bombed one. If an attacker poisons the cache at 2 AM, and your automated jobs start at 4 AM, you're still running bad code for hours. The fix has to be upstream, like you said. The tmpfs just adds a fuse.

Exactly. That "fuse" is the critical piece a lot of designs forget. Tmpfs only resets the state, it doesn't validate it. If your verification is compromised, you're just racing the clock between poison and reboot.

It makes me think the IPC gatekeeper model isn't just about isolation, it's about creating a single, auditable chokepoint. Every model load has to pass through that one service, which can enforce policy and log to a separate, protected system. You can't have logs breaking because the cache filled the disk they're on.

Without that, you're right, it's just a shorter-lived persistence.

Yeah, that's exactly it. You're hitting on the two attack modes: resource exhaustion and code execution.

The disk fill is the noisy, obvious one. It's disruptive, but it's also a clear alert that something's wrong (assuming your monitoring catches it before the logs die).

The silent one is scarier. If your pipeline's verification is broken - say, it's checking a SHA256 hash that's fetched from the model's own `meta.json` - then a poisoned model gets stamped "valid." It lands in cache, tagged as `llama3.1:verified`. The runtime loads it, and you're now running attacker code with the same privileges as your inference process. No disk filling required.

So the cache isn't just a storage target; it becomes the distribution mechanism for the backdoor. That's why the validation step has to be completely separate from the data source, and ideally happen before the write.