Kernel-level policy enforcement

Kernel-level policy enforcement means using Linux security mechanisms - seccomp (secure computing mode), AppArmor, and eBPF (extended Berkeley Packet Filter) - to enforce what an agent process can do at the operating system level, independent of the agent's own behavior or the container configuration. These mechanisms intercept system calls before they execute and block, allow, or audit them based on a defined policy. An agent that is subject to kernel-level policy enforcement literally cannot perform prohibited operations regardless of what code it runs or what instructions it receives.

Seccomp allows you to define a list of permitted system calls. An agent process running under a seccomp profile that does not include fork, exec, or clone cannot spawn child processes. An agent running under a profile that does not include socket cannot open network connections. These restrictions are enforced by the Linux kernel and cannot be bypassed by the agent process itself - they are below the level of userspace code.

AppArmor (and its counterpart SELinux) provides mandatory access control at the file and network level. An AppArmor profile for an agent can specify: this process can read files in /workspace/, can write files in /workspace/, but cannot read /etc/passwd, cannot execute files outside of a specified whitelist, and cannot make outbound connections to ports other than 443. These policies apply even to the root user within the container.

eBPF is the most powerful and flexible of the three mechanisms. It allows you to attach custom programs to kernel hooks that run in response to system events (system calls, network packets, filesystem operations). Organizations running agent fleets at L4-L5 use eBPF to build comprehensive behavioral monitoring: every system call the agent makes is logged, patterns that suggest anomalous behavior (reading credential files, making connections to unexpected hosts, spawning unusual processes) trigger alerts in real time, and policy violations can be blocked before they complete.

By June 2026, microVM, hardware-isolated execution became the default surface for agent-generated code rather than an exotic add-on to kernel policy. AWS Lambda MicroVMs (announced June 22, built on Firecracker specifically for AI-generated code, with runtimes up to 8 hours) joined comparable moves from Google and Azure - the industry framing is that enterprise AI agents are leaving the shared server for hardware-enforced isolation. Teams with data-residency or compliance constraints run self-hosted E2B or Daytona sandboxes inside their own VPC instead of a vendor-hosted surface. Pair this isolation with cryptographic run provenance: Dapr 1.18 Verifiable Execution (June 11) produces tamper-evident, SPIFFE-identity-bound records of what an agent actually did during a run, so the kernel-level controls described here are matched by an auditable proof that they held.

• Defense in depth beyond container boundaries - containers provide namespace isolation, but container escapes are real vulnerabilities; kernel-level policies enforce constraints even if the container is compromised or misconfigured
• Cannot-be-overridden restrictions - an agent with a seccomp profile that blocks network system calls literally cannot make network connections, regardless of what the agent process requests or how it is instructed; this is a qualitatively different guarantee than policy-based restrictions
• Real-time behavioral monitoring - eBPF programs can emit telemetry on every system call, providing a complete audit trail of what the agent did at the system level; this audit trail is far more comprehensive than application-level logs
• Reduces the trusted computing base - with kernel policy enforcement, you do not need to trust the agent software to respect its constraints; the kernel enforces constraints independently of agent behavior
• Enables safety claims that can be audited - a seccomp profile is a machine-readable statement of what the agent can do; it can be reviewed, tested, and audited by security teams in a way that behavioral guidelines and prompt instructions cannot

1. Profile the agent's system call usage - Before restricting system calls, understand which ones the agent actually uses. Run the agent with strace -e trace=all or with a seccomp audit profile (log all calls without blocking) and collect the system call distribution over representative tasks. This profile is the basis for your allow-list.
2. Create a seccomp allow-list profile - Start from Docker's default seccomp profile (which already blocks the most dangerous calls like kexec_load and ptrace) and narrow it further based on your system call profile. A typical agent profile should not need calls like mount, pivot_root, settimeofday, or direct disk I/O syscalls.
3. Apply an AppArmor profile for filesystem access - Write an AppArmor profile that allows read/write access to the workspace directory, read access to necessary system libraries, and denies access to everything else. AppArmor profiles are file-path-based and can be precise: allow /workspace/** (rw), allow /usr/lib/** (r), deny /etc/**, deny /home/**.
4. Implement eBPF-based behavioral monitoring - Deploy Falco (an open-source eBPF-based security monitoring tool) in the agent infrastructure. Falco comes with rule sets for common anomalous behaviors and can be configured with custom rules for agent-specific patterns (e.g., alert when an agent process reads a file matching *credentials* or *.pem).
5. Test the policy with adversarial inputs - Verify the policy works by attempting prohibited operations from inside the agent container: try to write to /etc/hosts, try to connect to a blocked IP, try to read an SSH key file. These tests should all fail if the policy is correctly configured.
6. Monitor policy violations in production - Connect Falco or your eBPF monitoring to your alerting system. Policy violations in production may indicate an agent behaving unexpectedly (which requires investigation) or a legitimate workflow that the policy incorrectly blocks (which requires policy adjustment). Both types of violations need visibility.

Writing overly permissive policies to avoid breaking anything. A seccomp profile that allows 300 of the 400 available system calls provides much weaker isolation than one that allows the 50 calls the agent actually needs. Permissive policies are a natural response to the complexity of getting policies right, but they defeat the purpose. Do the profiling work to understand what the agent actually needs.

Not testing policy changes against the full range of agent tasks. Agents run different system calls for different task types. A policy that works for "write a function" tasks may block "run the test suite" tasks if test runners use system calls that code writing does not. Test policies against all agent task types before deploying them.

Kernel policy as a substitute for other isolation layers. Kernel-level policy enforcement is one layer of a defense-in-depth strategy, not a replacement for network isolation, credential scoping, or ephemeral environments. An agent with strong kernel policy but no network isolation can still exfiltrate data via permitted network system calls. All isolation layers work together.

Not version-controlling seccomp and AppArmor profiles. Security policies are code. They should live in the repository alongside the Dockerfile and docker-compose configuration, be reviewed in PRs, and be tested in CI. An ad-hoc policy that exists only on production servers is a maintenance liability.

Falco rules that generate too much noise. An eBPF monitoring system that generates hundreds of alerts per agent task will be ignored. Write Falco rules that alert on genuinely anomalous behavior (accessing /etc/passwd, connecting to unexpected external hosts, reading files outside the workspace) rather than on every system call. Alert fatigue kills monitoring effectiveness.