Little documentation
Guides and APIRuntime

Isolation And Security

Trust boundaries for sessions, tools, storage, and scripts.

Little Harness: published on npm as little-harness@0.2.0-alpha.0 (2026-10-05). Sections labeled UNRELEASED describe source-only changes. Release status

Little Harness makes isolation the default behavior.

The first principle is simple: one session's files are not visible to another session unless the developer explicitly configured shared persistence.

Session Isolation

Each session receives its own workspace, artifacts, and trace. Parallel sessions do not mutate each other's working files.

Shared state only appears through:

  • a Persistent Dir
  • a host tool
  • an export action
  • a future policy-controlled shared memory feature

Tool Trust

Tool handlers run in the host app's trust boundary. The harness can trace and mediate tool calls, but it cannot make a malicious host tool safe.

Write tools should be named and described clearly:

save_report
create_ticket
update_crm_note

Avoid vague write tools such as finish, sync, or do_action.

Runtime Trust

Tier-0 — just-bash, bash emulated in JavaScript over a virtual filesystem — is a compatibility layer for trusted tool patterns, not an isolation boundary. Its commands never touch the real filesystem, processes, or sockets, so ordinary tool scripting is contained by construction; but that containment is a library's parser and virtual filesystem, not the operating system. Treat it as protection against mistakes, not against an adversary.

What follows from that:

  • Model-authored code does not run in the host process by default. localHost() defaults its sandbox option to "auto": a turn stays in-process only when runtime.python and runtime.javascript are both false and network is off. Every other turn runs in subprocessSandbox(). "in-process" opts out of that rule and should be reserved for trusted, read-only tool turns.
  • The subprocess sandbox is the floor for anything beyond pure read tools. Its worker starts with an empty environment (your API keys and tokens never reach it), a parent-side SIGKILL watchdog and init deadline, and just-bash's defense-in-depth layer, which defenseInDepthForAdapter turns on only in the worker — in-process it would patch process-wide globals of your app.
  • Neither tier confines native code. Use an OS-level sandbox (container, VM, microVM) behind a custom sandbox for genuinely untrusted workloads.

The rest of the design still applies around either tier:

  • network off by default
  • explicit harness directories only
  • host tools as explicit capabilities
  • trace records for tool and file activity
  • no arbitrary host path exposure by default

See Execution Environments for the modes and Execution Tiers for escalating commands Tier-0 cannot run.

App Policy

The app should still decide:

  • which tools are available
  • which users, teams, or request contexts may use them
  • which Persistent Dirs are exposed
  • whether export tools require approval
  • how persistence failures are surfaced to users

On this page