Syscall Filtering for AI Agent Processes in Production

AI agent security becomes enforceable at the point where a process acts. Syscall filtering puts a boundary that the kernel enforces around the actions of agent processes in production. Its value depends on pairing that boundary with the right isolation tier, narrow permissions, and evidence of what actually executed.

Why prompt-level controls are structurally insufficient for agent security

A customer-support agent reads inbound email, queries a database, and triggers refunds. An attacker hides instructions in an email signature, and the model treats a tool invocation as the plausible next step. The attack arrives through ordinary business content. It does not need to confront the system prompt directly, because the agent must process third-party text to do its job.

That is the structural weakness of prompt guards. The model is a probabilistic parser inside an untrusted execution loop, unreliable at separating developer instructions from hostile material. A guard that depends on the model choosing the right instruction remains a probabilistic filter. It does not establish a security boundary around the resulting action.

The strongest objection is that a second model can evaluate proposed actions and catch injections. That can add another check, but the evaluator shares the same kind of failure mode and adds latency without changing the execution surface. A regex over the final answer also leaves a tool payload that sends data elsewhere unprotected. The dangerous output may never appear in the conversation.

What agents can actually do at the kernel layer when nothing stops them

Coding agents turn that distinction into a machine-access problem. Cline, Aider, Codex CLI, and Claude Code process material such as cloned repositories and dependency READMEs while working with files, shell commands, and network access. When those capabilities are unrestricted, untrusted text sits upstream of powerful operations. A repository need not be trustworthy to look useful.

Local MCP servers widen the exposure because a process running under a user account can inherit that account’s ambient authority. SSH keys,.env files, database credentials, and browser cookies may be within reach without a separate grant. Wiz Research’s Amazon Q disclosure described repository-local MCP configurations loading without consent or a workspace trust check. The server processes that were started inherited the developer’s environment, which included cloud credentials and other secrets.

A runaway or injected agent can delete files, extract environment variables, make outbound connections, or attempt privilege escalation without a permissions dialog interrupting each action. On shared infrastructure, cross-tenant leakage is also part of the threat model. These harms share a source: agent-controlled code can reach the kernel’s syscall surface with more authority than it needs for its task.

Why Docker containers do not close the kernel exposure gap

Docker containers separate workloads while sharing the host kernel. That distinction limits what the container boundary can promise. A kernel exploit that enables an escape can expose the host, even when the workload’s filesystem view and resource allocation appear neatly contained. A container is not a private kernel.

Namespaces and cgroups remain useful controls, but they address visibility and resource usage rather than independently filtering calls into that shared kernel. The Antigravity case shows a similar failure of the boundary at the subprocess layer, below prompt-level and policy-level controls. Assess the execution paths the boundary actually covers independently of the interface’s “sandboxed” label.

For sandboxing to work, it therefore needs several controls around the container boundary. These include a read-only root filesystem, no shared memory between agent execution environments, restrictions on dangerous kernel operations, and time and resource limits that constrain recursive execution. Each closes a different route to harm. Resource limits can contain runaway consumption, for example, without deciding whether a process should be allowed to make a particular syscall.

The three kernel-isolation technologies and what each one actually enforces

Firecracker microVMs place each workload behind a dedicated kernel using KVM hardware virtualization. AWS’s open-source implementation is written in Rust. Its relevant guarantee is the separation between workload kernels, rather than another set of restrictions around processes sharing one kernel. That boundary addresses the cross-tenant exposure central to regulated data and multi-tenant platforms.

gVisor inserts a different kind of boundary. Its runsc runtime intercepts application syscalls and handles them in the Sentry, a Go-implemented, Linux-compatible kernel, rather than letting agent code invoke host kernel syscalls directly. Most container workloads can run unmodified because the Sentry provides a Linux-like syscall interface. This software-mediated boundary offers deeper mediation than seccomp-bpf filtering and a way to avoid full microVM boot overhead while retaining an intervening kernel implementation.

V8 Isolates have a narrower role. They suit lightweight, latency-critical workloads confined to a single language runtime. Their low overhead is useful only when that confinement fits the task. Treating them as interchangeable with a microVM would confuse a language-runtime boundary with a dedicated workload kernel.

Product sandbox modes are a separate axis. Codex CLI exposes read-only, workspace-write, and danger-full-access through its explicit --sandbox selector, with workspace-write serving as OpenAI’s default low-friction mode for local work in version-controlled folders. These modes describe permitted activity. The underlying isolation mechanism determines how that permission boundary is enforced.

How seccomp-bpf and eBPF filtering work as the enforceable floor inside any container tier

Seccomp-bpf attaches a BPF program to a process and evaluates its syscalls before the kernel executes them. The kernel acts on the result by allowing the call, denying it, or killing the process. The application does not get the deciding vote. Once a call is blocked, a persuasive prompt cannot talk it into executing.

eBPF extends kernel-level instrumentation into observability and enforcement. Probes at points where the kernel executes code can record file opens, network calls, and process creation, while the filtering logic runs inside the kernel’s verified sandbox. The useful distinction is between observing an operation and enforcing a restriction on it. A production design needs the latter where policy requires prevention.

grith illustrates the runtime interception pattern around CLI agents without requiring changes to their code. Its interception layer sends file opens, network calls, and process spawns through 17 independent security filters that run in parallel across three phases. A composite score routes each operation to auto-allow, auto-deny, or an asynchronous review queue. Most calls auto-approve, so there are fewer approvals to tire people out, and interception also helps track costs per session and keep audit trails.

The stated processing overhead is approximately 15ms. That belongs in the context of LLM response latency rather than an assumption that interception is free, and grith’s developer acknowledges ongoing optimization. The architectural benefit is that review occurs on the action path. It need not depend on the model volunteering an accurate account of its intentions.

The recommended pattern excludes general-purpose tools in favor of single-purpose typed RPCs, separates read and write channels with different credentials, and bounds execution to a task without persistent state between tool calls. Syscall restrictions support those boundaries at execution time. They do not, by themselves, turn a broad shell interface into a narrowly authorized business operation.

Matching the isolation tier to the workload's actual threat profile

The choice should start with blast radius and how sensitive the data is. An agent reading public web pages presents a different risk from one executing shell commands or accessing production databases. Deployment convenience is not a threat classification. Choosing the boundary first and describing the risk afterward reverses the reasoning.

For multi-tenant SaaS or workloads handling regulated data, including HIPAA and FedRAMP contexts, the recommended tier is Firecracker microVMs. These workloads need cross-tenant kernel isolation that shared-kernel containers cannot provide. For compute-heavy single-tenant workloads where boot latency is a significant constraint, gVisor offers syscall interception without full VM overhead. It also suits compute-heavy multi-tenant settings where that mediated boundary meets the needs and hardware isolation is not required.

For developer-facing coding agents on trusted hardware and low-sensitivity repositories, an OS process sandbox using Seatbelt, bubblewrap, or seccomp-bpf can be acceptable. Coverage must be explicit, however. Claude Code’s sandboxing documentation states that its built-in sandbox covers shell commands, while file tools, MCP servers, and hooks run outside it. Its sandbox-runtime package can wrap an entire process, but that requires explicit installation and launch.

For lightweight tasks confined to a single language runtime with no shell access and tight latency requirements, V8 Isolates fit the narrower execution model. Network access remains a separate decision in every tier. A permitted outbound connection can still become an exfiltration route, so network namespace isolation or an explicit egress allowlist is required. The point of tier selection is to avoid both universal microVM deployment and universal confidence in containers.

The authorization controls that syscall filtering depends on to be meaningful

Syscall filtering enforces the boundary it receives. If an agent already holds broad credentials and access to email, databases, APIs, and administrative operations, the filter constrains a large attack surface. Behavioral inspection cannot repair excessive entitlements. Authorization must first establish what the agent can reach before assessing whether its latest request looks suspicious.

MCP makes that question harder because identity spans the end user, AI host, MCP client, MCP server, and downstream APIs. A server can fall back to client trust, a shared service account, or cached credentials, bypassing the user’s actual permissions. The NSA’s May 2026 advisory flagged that MCP lacks support for exchanging RBAC permissions at instantiation. Two implementations can therefore claim MCP compliance without sharing interoperable access rules.

Agent-RBAC addresses both delegation and execution authority. It defines who can spawn which agent type, what actions that agent can perform on which data classes, and its per-session budget cap. Credential design must preserve the same limits. The recommended design uses short-lived scoped tokens that are rotated every 15 minutes or per tool call, with secrets limited to the task and revoked when work ends. A credential proxy such as the open-source Agent Vault keeps secrets out of the agent’s memory.

Policy placement then determines where those permissions are evaluated. OPA fits perimeter controls such as Kubernetes admission and Envoy routing, while AWS Cedar fits tool-level authorization inside the agent runtime control plane. Local evaluation can be sub-millisecond, whereas a separate OPA cluster introduces network latency and high-availability requirements. Placement affects both speed and operational complexity.

Authorization decisions also have a timing gap. Cedar does not jointly enforce a decision and the subsequent state transition, so relevant entity attributes may change between evaluation and execution. Syscall filtering partially compensates by enforcing restrictions when an operation occurs. It cannot make an earlier business-level authorization decision atomic. Execution controls therefore complement entitlement governance.

What production audit logs from syscall filtering must capture to satisfy SOC 2 and regulatory reviewers

Execution-level interception records what a process does, going beyond what it plans to do. For agentic systems entering SOC 2 Type 2 reviews, that distinction supports attribution to the session, user, and workflow that initiated an operation. Reviewers also need a clear definition of authorized and prohibited actions, plus evidence that permissions are limited to the task. A syscall record without that context is incomplete.

Interception gives the evidence a different footing from application logging because it sits on the execution path. grith’s audit trail, for example, follows directly from intercepting operations. That placement improves fidelity, but storage still needs protection. A kernel-originated event does not make its eventual log file immutable.

Tamper-evidence therefore belongs in the logging design. Ordinary text or JSON logs can be edited or deleted by identities with write access, so appropriate mechanisms include append-only or object-lock storage, WORM, or cryptographic hash-chaining. SOC 2 does not prescribe a particular mechanism. The requirement is evidence reviewers can trust.

The STRIDE framework gives that evidence an investigative context. For each agent, documentation should cover callable tools and APIs, readable and writable data sources, credential scope, execution triggers, who can modify those triggers, and the blast radius of full compromise. Syscall logs show what ran against that map. They help connect a permission grant to what a process actually did.

That connection is operational as well as regulatory. Mean time to detect, or MTTD, measures how quickly an agent anomaly becomes visible before failures cascade. Syscall-level interception with real-time scoring makes rapid detection achievable at scale. The same boundary that refuses a harmful operation can also provide the evidence needed to recognize the attempt.