Resource Limits

Secure Exec resource limits, defaults, backpressure constants, and warning names.

Secure Exec bounds each VM with per-VM resource caps so untrusted guest code can never exhaust the host. At a glance:

• Per-VM caps: Each VM gets its own ceilings on concurrent processes, open file descriptors, sockets, total filesystem bytes, and WASM stack depth.
• Kernel-enforced: The kernel mediates and accounts for every allocation. There is no path for the guest to reach host resources around these limits.
• Guest-local failure: A guest that exceeds a cap fails inside its own VM with a normal POSIX errno, exactly as it would on real Linux.
• Host is unaffected: Hitting a limit terminates or fails the guest operation only; the sidecar and host process stay intact and the VM keeps running.
• Operator-raisable: The caller configures the limits per VM and can raise or lower them to fit the workload.
• Observable: Queue, resource, memory, and CPU limits emit limit_warning structured events and WARN logs as they approach or hit a cap.

Operator constants

These constants are the default caps behind the limits.* VM config fields.

Backpressure constants

These internal queue caps are not per-VM config fields. They are tracked so slow consumers produce limit_warning events instead of silent stalls.

Audited constants

The limits audit classifies every limit-shaped constant as policy, policy-deferred, or invariant. Keep this table in sync with crates/sidecar/tests/fixtures/limits-inventory.json.

Warning names

The limit registry emits stable names in limit_warning.detail.limit. limits.resources.maxWasmStackBytes is audited as a configured constant above, but it does not emit limit_warning until runtime stack enforcement has a reliable exhaustion edge.

When a warning fires depends on whether the limit has a continuously-sampled usage:

• Queue, Resource, and CPU limits emit an edge-triggered ~80% approach warning (re-armed once usage drains back below ~50%), so the operator gets a heads-up before the cap is reached. The CPU budgets (v8_cpu_time_ms, v8_wall_clock_ms, wasm_fuel_ms) are sampled by the execution watchdogs; the queue/resource gauges are sampled as items flow through them.
• Memory limits (v8_heap_bytes, wasm_memory_bytes) emit at the terminal edge — V8’s near-heap-limit callback fires as the isolate is about to exceed its heap cap, and WASM memory is checked at module-instantiation time. There is no separate 80% heap sample because a V8 isolate cannot be safely read from the watchdog thread.

CPU budgets therefore emit both the ~80% approach warning and a terminal exhaustion warning when the watchdog finally terminates execution.

Related agentOS docs

agentOS layers its own session and adapter limits on top of Secure Exec.