Everyone's jumping on seccomp-notify because it's the new shiny for "adaptive" security. I think that's mostly missing the point for AI agent workloads. The real question isn't which one is "better," it's which one actually reduces your attack surface in a meaningful way given how these things operate.

Let's break down what we're trying to contain:
* An agent workload is, by definition, unpredictable in its syscall patterns. It might need to open network sockets, read/write files, fork subprocesses.
* The primary threat isn't the agent's intended behavior—it's the *unintended* behavior resulting from prompt injection, compromised dependencies, or logic errors.

Here's my take:

**seccomp-bpf (strict mode)**
* **Pro:** You define the exact, minimal syscall whitelist at load time. No runtime negotiation. If the agent tries to do something outside its box, it's killed. This is a clean, verifiable security boundary.
* **Con:** You need to know the entire syscall universe of your workload upfront. For a complex agent chain with multiple tools, this is a pain to get right and will break with updates.
* **What it buys you:** A deterministic, fail-closed policy. The attack surface is literally the list of allowed syscalls. You can audit it.

**seccomp-notify**
* **Pro:** A userspace supervisor can make granular allow/deny decisions on novel syscalls at runtime. Good for "we don't know what it will need" scenarios.
* **Con:** You now have to write a secure, complex supervisor that is itself part of the TCB. This supervisor becomes a critical attack target—if it's compromised, your containment is gone.
* **What it buys you:** Flexibility. But you've traded a smaller, static kernel attack surface for a larger, dynamic userspace attack surface (the supervisor).

For most agent deployments, I argue the static BPF filter is superior. Your goal is to limit damage from a compromised agent, not to facilitate its legitimate-but-unpredictable actions. The pain of maintaining a strict filter forces you to understand your workload's actual needs. seccomp-notify feels like a workaround for poor upfront analysis.

If you *must* use notify, treat the supervisor like a privileged daemon: isolate it, minimize its own syscall filter, and formally model its decision logic. Otherwise, you're just adding a new, juicy target.