Alright, let's cut through the marketing fluff. You're told to drop a seccomp filter on your agent container and suddenly it's "secure." But how does that *actually* stop a compromised agent from exfiltrating your customer database?

Think of seccomp as a syscall firewall. The agent, at the end of the day, is just a process. To do anything—read a file, send a network packet, even fork—it has to ask the kernel via a syscall. A seccomp filter is a list of allowed syscalls. No allow, no dice.

So, to phone home, an agent typically needs:
* `socket` - to create a network socket.
* `connect` - to link that socket to a remote IP/port.
* `sendto` or `write` - to shove the stolen data into the socket.
* Maybe `getdents`/`read` to find and read the data first.

A properly tuned seccomp filter blocks the network-creating syscalls entirely. The agent can compute all it wants, but it can't create a network connection. It's marooned.

The devil is in the details, though:
- If you allow `socket` but only for `AF_UNIX` (local inter-process), you're safe from network exfil.
- If you forget to restrict `sendmsg` on an already-open socket (maybe inherited from a parent process), you've got a bypass.
- A clever agent might try `open` on a network filesystem, or abuse a permitted IPC channel. Seccomp is just one layer.

So the ELI5: It doesn't let the agent make the "call" part of "phone home." The kernel hangs up before the dial tone even starts. But you have to actually think about which syscalls you're blocking, not just cargo-cult a profile from GitHub.