The prevailing wisdom in our circles is that leveraging a runtime's default sandbox—be it gVisor, Firecracker, or even a basic container profile—constitutes a meaningful security boundary. I contend this is a dangerous form of complacency. Default configurations exist to ensure broad compatibility, not to provide a defensible, minimalistic security posture. They are a starting point for the convenience of the developer, not an endpoint for the security engineer.

Consider the typical default seccomp-bpf filter for containers. It is a blocklist model, often derived from a large whitelist of syscalls deemed "generally safe." This approach fails for several reasons:

* It presumes the threat model is limited to known-dangerous syscalls, ignoring that a benign syscall can become a powerful primitive when combined with others or when operating on an unintended resource.
* It does not account for application-specific behavior. Why should a network analytics agent require the `mount` syscall, or a data processing workload require `personality`? The defaults leave these doors open.
* It often ignores namespace subtleties. A syscall permitted in the default profile may have drastically different security implications depending on whether the user, network, or IPC namespaces are shared or isolated.

The only methodology that approaches sufficiency is constructing a custom, application-tailored seccomp policy from a deny-all baseline. This requires a disciplined, multi-phase process:

1. **Profiling:** Run the application under a strict, trace-only seccomp profile that logs all syscalls made during comprehensive functional and stress testing. Tools like `strace` or `scmp_sys_resolver` are foundational here, but one must also consider libraries and subprocesses.
2. **Analysis:** Audit the resulting syscall list. Each must be justified. Ask: For what specific operational purpose does this agent require `ptrace` or `setuid`? Is `clone` needed, or only `clone3` with specific flags? This is where understanding the actual workload is non-negotiable.
3. **Policy Generation:** Author a JSON seccomp profile that permits *only* the justified syscalls, with arguments constrained where possible (e.g., restricting `open` to specific `O_*` flags, blocking `execve` of writable paths). This becomes part of the agent's immutable deployment artifact.
4. **Validation:** Deploy the restrictive policy in a staging environment and subject the agent to its full operational workload, including failure modes and edge cases. The absence of syscall violation logs is not success; it must be paired with confirmed operational fidelity.

The counter-argument is invariably cost: the man-hours for profiling and maintenance. This is a false economy. The cost of a breach or a privilege escalation via an unused syscall left open by a default profile—such as using `openat` and `fcntl` to manipulate host file descriptors leaked through a compromised subprocess—dwarfs the initial investment. Furthermore, in paradigms like on-device AI or federated learning, where agents handle sensitive data on untrusted hardware, this granular control is the only way to approach a zero-trust architecture for the kernel interface itself.

Relying on a runtime's default sandbox is akin to installing a fortified door on a house with walls of paper. The real work is in building the wall. If your security posture for a deployed agent does not include a bespoke seccomp policy derived from its unique behavior, you are delegating your kernel-level attack surface reduction to a committee designing for the lowest common denominator. That is an indefensible position.