Seccomp Profile

A seccomp profile enforces an irreversible security boundary. Once a process loads a seccomp filter, it can never regain the ability to make restricted system calls. This one-way transition prevents compromised processes from escaping the sandbox by reverting to a more permissive state. The kernel enforces this immutability at the prctl level, ensuring that even a process with full control of its own memory cannot disable the filter.

Seccomp profiles are implemented using classic Berkeley Packet Filter (cBPF) or extended BPF (eBPF) programs. These are small, event-driven bytecode programs that the kernel executes on every system call entry. The BPF program inspects the system call number and arguments, then returns one of several actions:

• SECCOMP_RET_KILL_PROCESS: Terminate the entire process immediately.
• SECCOMP_RET_ERRNO: Return a specified error code to the caller.
• SECCOMP_RET_ALLOW: Permit the system call to proceed. This architecture ensures filtering happens in the kernel with minimal overhead.

Seccomp operates in two distinct modes:

• SECCOMP_SET_MODE_STRICT: The most restrictive mode. The process is allowed only read(), write(), _exit(), and sigreturn(). Any other system call triggers SIGKILL.
• SECCOMP_SET_MODE_FILTER: Allows custom BPF programs to define a granular policy. This mode supports argument inspection, allowing rules like 'allow socket() only for AF_UNIX and SOCK_STREAM'. Filter mode is the foundation for modern container runtimes and sandboxed agent execution.

Beyond filtering by system call number, seccomp profiles can inspect system call arguments to enforce fine-grained policies. For example, a profile can allow openat() but restrict it to read-only mode by checking the flags argument for the absence of O_WRONLY or O_RDWR. This capability enables path-based restrictions and flag-based restrictions, preventing an agent from writing to critical files even if it can call the write syscall.

Modern container runtimes like Docker, containerd, and CRI-O automatically generate and apply seccomp profiles. Docker's default profile blocks approximately 44 system calls out of over 300, including dangerous calls like reboot(), kexec_load(), and bpf(). Kubernetes allows operators to define custom seccomp profiles per pod via the seccompProfile field in the security context, enabling workload-specific hardening for autonomous agent containers.

The SECCOMP_RET_USER_NOTIF action, introduced in Linux 5.0, allows a seccomp filter to delegate a decision to a user-space supervisor process. When a monitored system call is intercepted, the kernel sends a file descriptor to the supervisor, which can inspect arguments, make a policy decision, and instruct the kernel to allow or deny the call. This enables dynamic, context-aware sandboxing where a human-in-the-loop or an AI policy engine can approve high-risk agent actions in real-time.

The security principle that a process should have only the minimum permissions necessary to perform its function. Seccomp enforces this at the kernel boundary:

• An agent that only makes HTTP calls needs socket(), connect(), sendto(), recvfrom()
• It does not need fork(), execve(), or ptrace()
• Building a seccomp profile starts by profiling normal behavior with strace, then generating an allowlist that blocks everything else

A security control that prevents any binary or script from running unless it appears on a pre-approved list. Seccomp complements this by blocking the execve() and execveat() syscalls entirely for agent workloads that should never spawn child processes. Combined with a read-only root filesystem, this creates a powerful barrier against:

• Shell injection attacks
• Download-and-execute payloads
• Unauthorized tool invocation in agentic workflows

The practice of monitoring an agent's execution environment in real-time for anomalous behavior. Seccomp profiles generate audit logs via the SECCOMP_RET_LOG action, which records denied syscalls without killing the process. This enables:

• Profile refinement: Identify missing syscalls before enforcing strict mode
• Threat detection: Flag unexpected syscall patterns as potential compromise indicators
• Compliance auditing: Maintain an immutable record of all kernel interactions

Writing security rules in a machine-readable language that can be version-controlled, tested, and automatically enforced. Seccomp profiles can be expressed as JSON and managed through:

• Kubernetes Pod Security Standards: The RuntimeDefault profile enables the container runtime's default seccomp profile
• Custom profiles: Defined as ConfigMaps and referenced in pod securityContext
• CI/CD integration: Profiles are validated in staging before production deployment, ensuring no regressions