Alright, let's cut through the usual "unbreakable container isolation" marketing. We're all running these agent frameworks in containers now, and everyone acts like a `--network none` flag is a magic forcefield. It's not.

I've been poking at NanoClaw's "container-first" agent tasks. Their model is fine for a single agent in a pristine pod. But start stacking concurrent workloads, shared volumes, or let someone get lazy with the orchestration config? The gaps get wide enough to drive a privilege escalation through. I watched a task with a benign file-write capability start leaving artifacts in a shared emptyDir volume that another, more sensitive task picked up. No syscall violation, just a dumb data leak the isolation model never considered.

So I got tired of guessing and wrote a little eBPF tool to trace syscalls that cross container boundaries. It hooks into `cgroup` and `namespace` info to filter out the noise. It's not pretty, but it shows you the raw `open`, `connect`, `execve` attempts that reach outside the container's assigned resources. You'd be surprised how many "read-only" mounts get a write attempt, or how often a task probes `/proc` of a sibling container when the node is under load.

Ran it on a test cluster with a simulated high-concurrency agent workload. The logs lit up with cross-container `stat` and `readlink` calls the kernel allowed because the underlying host FS permissions didn't care about namespace boundaries. Orchestration said "isolated." The kernel logs told a different story.

If your security model relies solely on the container runtime, you're only seeing half the picture. Sometimes you need to watch what the kernel is actually being asked to do.

- Ray