---
title: "Escape tripwires · Ataris"
description: "Tripwires around the hypervisor and VMM: anomalous VMM process behavior, host syscalls it should never make, and tampering with guest memory or devices. Firecracker security, and the same for Cloud Hypervisor, Kata, gVisor, and runc."
canonical: "https://ataris.dev/product/escape-tripwires"
last-updated: 2026-11-02
---
# Know if anything breaks isolation.

Tripwires around the hypervisor and VMM: anomalous VMM process behavior, host syscalls it should never make, and tampering with guest memory or devices. Firecracker security, and the same for Cloud Hypervisor, Kata, gVisor, and runc.

## The VMM is small and predictable. Watch for anything else.

runc, Firecracker, gVisor, Kata, and KVM have all shipped isolation advisories. Patching closes the hole. It doesn't tell you whether someone used it. Tripwires on the host do.

### 1. Expect: Know what the VMM should do.

A VMM process opens a few files, talks to /dev/kvm and its tap device, and makes a narrow set of syscalls. Ataris watches each VMM process from the host with eBPF.

Example (firecracker · pid 7141): files = /dev/kvm, tap0, rootfs; syscalls = expected set; child processes = none; guest memory = VMM mappings only.

### 2. Trip: Trip on what it shouldn't.

A shell spawned by the VMM, a syscall outside its usual set, a file opened outside its jail. Each one is a tripwire, and each one opens a case with the process tree attached.

Example (vmm-71 · tripwires): syscall = ptrace · unexpected; execve = /bin/sh · unexpected; open = outside jail; sandbox = vm-41aa.

### 3. Guard: Watch guest memory and devices.

Access to a guest's memory, or to its virtual devices, from anything other than its own VMM is a tripwire too.

Example (vm-8a02 · memory): mapped by = vmm-71 (owner); foreign access = none; device tampering = none.

## Every runtime in the fleet.

One set of tripwires per isolation layer, all landing in the same case queue.

- **microVMs.** Firecracker and Cloud Hypervisor. VMM process behavior, host syscalls, guest memory access, virtual devices.
- **VM-backed containers.** Kata Containers. VMM process behavior, host syscalls, guest memory access, shim processes.
- **Containers.** gVisor and runc. sandbox process behavior, host syscalls, files outside the sandbox, new host processes.

## Related

- [Sandbox escapes](https://ataris.dev/use-cases/sandbox-escapes.md): Breakouts from runc, gVisor, Kata, KVM
- [AI agent sandboxes](https://ataris.dev/use-cases/agent-sandboxes.md): Firecracker, gVisor, Kata, containers
- [Host sensor](https://ataris.dev/product/host-sensor.md): eBPF on the host, Helm or Linux package

## Find out if your sandboxes ever leaked.

Book a demo and we'll walk through the tripwires for your runtime.

[Book a demo](https://ataris.dev/contact)