infrastructureL4 OptimizedAgent Runtime & Sandboxing

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 a

·Ephemeral devboxes spin up in under 10 seconds (Stripe benchmark)
·Devboxes come pre-loaded with codebase, dependencies, and MCP tools
·Kernel-level policy enforcement restricts agent actions (syscall filtering, resource limits)

·Devbox spin-up P99 latency is under 30 seconds
·Firecracker microVMs or equivalent provide VM-level isolation with container-level startup speed

Evidence

·Devbox spin-up latency dashboard showing P50 under 10 seconds
·Devbox snapshot configuration showing pre-loaded codebase, deps, and MCP tools
·Kernel policy configuration (seccomp profiles, cgroup limits)

What It Is

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.

Why It Matters

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

Getting Started

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.
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.
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/**.
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).
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.
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.

Tip

Start with an audit-only policy that logs policy violations without blocking them. Running the audit policy for two weeks against real agent workloads will reveal both the legitimate operations the policy would block (which need to be allowed) and the suspicious operations that should definitely be blocked. This profiling step prevents the policy from breaking legitimate agent workflows when you switch to enforcement mode.

6 steps to get from here to the next level

Common Pitfalls

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.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob's security team has been asking for documentation of what agent processes can and cannot do at a technical level. Bob's current answer is "the agent is instructed not to do certain things" - which is not satisfying to a security team. They want to see actual technical controls, not behavioral guidelines. Bob knows this is a gap but does not know how to address it without a major infrastructure effort.

What Bob should do: Bob should frame kernel-level policy enforcement as the answer to the security team's question. The security team is asking for technical controls, and seccomp + AppArmor provide exactly that: a machine-readable, auditable policy that defines what the agent process can do at the operating system level. Bob should assign one security-focused engineer to build a baseline seccomp profile for the agent container. The profile does not need to be perfect on day one - a starting point that blocks the most dangerous system calls and logs everything else gives the security team the technical control documentation they need while the policy is refined over time.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah is not deeply technical but she understands that the security team's concerns about AI agents are slowing down adoption. Her developers are being told they need security approval before deploying new agent workflows, and security approvals are slow because the security team does not have the visibility they need into what agents are doing. Kernel-level monitoring could give the security team the visibility that unblocks approvals.

What Sarah should do: Sarah should work with the security team to understand specifically what information would allow them to approve agent workflows faster. In most cases, the answer is: "we need to know what the agent can and cannot do, and we need to see evidence of what it actually does." A Falco-based eBPF monitoring setup addresses both needs: the seccomp and AppArmor profiles define what the agent can do (auditable, machine-readable), and Falco logs show what it actually did. Sarah should position kernel-level monitoring not as a restriction but as a visibility tool that enables faster security approvals and therefore faster agent adoption.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor has been experimenting with Falco for eBPF-based agent monitoring and has found it powerful but noisy out of the box. He has been tuning custom rule sets based on observed agent behavior in his devbox setup. His current rule set generates a manageable 5-10 alerts per agent session, all of which represent genuinely interesting events (attempts to read files outside the workspace, unexpected process spawns, unusual network calls).

What Victor should do: Victor should publish his Falco rule set as a starting point for the team. The rule set represents weeks of tuning work that the infrastructure team would otherwise have to repeat. Victor should also document the process for tuning Falco rules: how to read Falco output, how to distinguish legitimate events from anomalous ones, how to write custom rules for team-specific patterns. Beyond Falco, Victor should prototype a seccomp profile for the agent container by running the agent with strace and capturing the system call distribution. He should propose that seccomp enforcement and Falco monitoring be implemented together as a security package in the next infrastructure sprint.

What Victor should do - role-specific action plan