Skip to main content
Palyra employs a multi-tiered sandboxing architecture to execute untrusted code and tools with varying degrees of isolation. The system is designed to balance performance, capability, and security by providing three distinct tiers (A, B, and C) that range from lightweight WebAssembly isolation to kernel-level process sandboxing. The primary entry point for executing these constrained processes is the run_constrained_process function [crates/palyra-daemon/src/sandbox_runner.rs#147-151] which enforces policies defined in SandboxProcessRunnerPolicy [crates/palyra-daemon/src/sandbox_runner.rs#81-93].

Execution Tier Overview

TierTechnologyIsolation LevelPrimary Use Case
Tier AWebAssembly (Wasmtime)Instruction-level (SFI)Plugins, Skills, and lightweight tools.
Tier Brlimit + Path ValidationOS Resource LimitsLocal process execution on Unix-like systems.
Tier CBubblewrap / sandbox-execKernel Namespaces / MACHigh-risk OS process execution with network/FS isolation.

Tier A: WebAssembly Isolation

Tier A utilizes the palyra-plugins-runtime crate, powered by wasmtime, to execute code in a Software Fault Isolation (SFI) environment [crates/palyra-plugins-runtime/src/lib.rs#105-108].

Tier B: OS Resource Constraints

Tier B is designed for Unix-based systems where full kernel namespacing (Tier C) might be overkill or unavailable, but resource consumption must still be capped.

Tier C: Kernel-Level Sandboxing

Tier C provides the strongest isolation by leveraging platform-specific sandboxing tools to create a restricted view of the operating system.
  • Linux (Bubblewrap): Uses bwrap to create new PID, network, and mount namespaces. It mounts a minimal /proc, /dev, and a read-only /usr scaffold, while binding only the specific workspace_root as writable [crates/palyra-sandbox/src/lib.rs#130-182].
  • macOS (sandbox-exec): Uses the macOS Seatbelt (AppSandbox) framework. It generates a temporary .sb profile that restricts the process to the workspace directory and limits network access [crates/palyra-sandbox/src/lib.rs#8-10].
  • Windows (Job Objects): (Planned/Partial) Uses Job Objects for resource accounting and basic restriction [crates/palyra-sandbox/src/lib.rs#11-13].

Sandbox Data Flow and Enforcement

The following diagram illustrates how a tool call is processed from a request into a sandboxed execution environment. Sandbox Execution Pipeline Sources: [crates/palyra-daemon/src/sandbox_runner.rs#147-209](http://crates/palyra-daemon/src/sandbox_runner.rs#147-209), [crates/palyra-daemon/src/tool_protocol.rs#20-26](http://crates/palyra-daemon/src/tool_protocol.rs#20-26), [crates/palyra-sandbox/src/lib.rs#81-91](http://crates/palyra-sandbox/src/lib.rs#81-91).

Key Security Components

1. Egress Enforcement Modes

The EgressEnforcementMode [crates/palyra-daemon/src/sandbox_runner.rs#47-51] determines how network access is handled:

2. Workspace Root Scoping

The sandbox ensures that all file operations are relative to a defined workspace_root.

3. Interpreter Guardrails

To prevent “jailbreaking” the sandbox via shell escapes, INTERPRETER_EXECUTABLE_DENYLIST [crates/palyra-daemon/src/sandbox_runner.rs#30-44] blocks common shells and language runtimes unless allow_interpreters is explicitly set to true in the policy [crates/palyra-daemon/src/sandbox_runner.rs#86].

Implementation Mapping

The relationship between the sandbox configuration and the underlying system execution. Policy to Executor Mapping Sources: [crates/palyra-daemon/src/sandbox_runner.rs#81-93](http://crates/palyra-daemon/src/sandbox_runner.rs#81-93), [crates/palyra-sandbox/src/lib.rs#81-91](http://crates/palyra-sandbox/src/lib.rs#81-91), [crates/palyra-daemon/src/sandbox_runner.rs#147-151](http://crates/palyra-daemon/src/sandbox_runner.rs#147-151).

Summary of Constraints

The sandbox enforces several hard limits defined in SandboxProcessRunnerPolicy: