Do You Really Know What Your AI Agent Is Doing in the Sandbox?

The rapid adoption of AI agents equipped with shells, filesystems, and network access has created a fundamental observability problem. When an agent finishes a task, logs generated by the model itself and platform metrics provide only a partial picture. The real question remains: what system calls did the agent actually execute?

Two main approaches exist for observing agent behavior. The first intercepts tool calls inside the agent framework, which is inexpensive but blind to any actions performed outside the framework. The second uses eBPF probes on the host kernel to capture every syscall, an approach used by container security tools. This method is more trustworthy yet assumes the agent shares the host kernel.

Strong isolation runtimes break that assumption. gVisor implements its own kernel in user space, while Kata Containers and Firecracker run a full guest Linux kernel inside a virtual machine. In both cases, guest syscalls never reach the host kernel where traditional monitors attach.

Existing standards cover several aspects of agent operation. MCP standardizes how agents connect to tools and data. OpenTelemetry defines semantic conventions for model and agent spans. RuntimeClass lets Kubernetes switch between runtimes without changing application manifests. The new agent-sandbox project treats sandboxes as first-class Kubernetes resources. None of these standards, however, define a common interface for reporting the actual syscalls performed inside the sandbox.

Empirical testing used a generator that performed ten distinct operations, each tagged with a unique marker. Probes verified that the monitoring stack itself was functioning correctly. Results across 24 runs demonstrated that visibility is determined by whether filesystem operations cross into a host process. When a block device backs the guest root, almost no guest file operations appear on the host. When virtiofs or an overlay shares the filesystem via a host process, file names and writes become visible.

Even within the same runtime, configuration changes produce dramatically different results. Enabling the in-memory overlay in one gVisor mode hides writes and deletions while still exposing opens. Executions never surface as execve events on the host under any tested sandbox; only prior file copies leave detectable traces when the filesystem is host-mediated.

Commercial security products already reflect these limitations. Falco removed its gVisor engine, Google Container Threat Detection is incompatible with GKE Sandbox, and Microsoft Defender cannot inspect Kata pods. The measurements confirm that switching a RuntimeClass value can silently eliminate visibility into entire classes of agent actions.