Security & isolation

Security & isolation

For operators and leadership

When AI can edit files and run tools, boundaries are the product. Jarvis is designed so automated work stays inside limits you set:

  • Work is limited to the project you choose—not your entire personal files.
  • Additional folders open only with explicit permission.
  • Network access is not open by default for untrusted steps.
  • Higher-risk actions can require approval, with a record of what was allowed.

Technical teams can dig into the implementation notes below. Executives can treat this page as the short version: power with containment.

Technical notes (operators)

JARVIS confines agent workloads (skill scripts, mnemos run create, future SWE/Factory steps) inside rootless Podman boxes by default when Podman is healthy. The control plane (harnessd / interactive TUI) stays on the host; host AppArmor/SELinux for that process is Enterprise (S5).

Doctrine

ID Rule
D-SB-1 Sandbox agent work first; do not pretend the whole of JARVIS lives in one box.
D-SB-2 Podman is the v0 local provider; custom MAC profiles after defaults are green.
D-SB-3 Host MAC for harnessd = Enterprise only.
D-SB-4 Project mount RW at /workspace; never bind ambient $HOME / .agents / .jarvis wholesale.
S3 Extra host paths only via allowlist; extras default RO.
S4 Skills + run create default to Podman when healthy; opt out with host.

Mode resolution (S4)

--sandbox flag  >  JARVIS_SANDBOX / SANDBOX env  >  health default
Preference Result
podman Always use Podman (fails at run if broken)
host Always run on host (legacy / debug)
auto / unset Podman if checkHealth OK, else host

Env names: JARVIS_SANDBOX first, then SANDBOX.

Box defaults

  • --network=none
  • --cap-drop=ALL, no-new-privileges, read-only root, tmpfs /tmp
  • --userns=keep-id (private project trees stay usable under rootless Podman)
  • Project bind: host project → /workspace (RW default; --mount-ro for RO)
  • Resource caps: pids / memory / cpus / timeout

Allowlist (S3)

// .jarvis/sandbox-allow.kdl  or  templates/sandbox-allow.kdl
sandbox_allow {
  mount path="/home/YOU/zData/models" mode="ro" target="/models"
  mount path="/tmp/agent-cache" mode="rw" target="/cache"
}

CLI:

mnemos sandbox run --project /path/to/repo \
  --allowlist .jarvis/sandbox-allow.kdl \
  --allow /tmp/ro-data \
  --allow-rw /tmp/scratch \
  -- COMMAND...

Skills also honor JARVIS_SANDBOX_ALLOWLIST or {skill}/sandbox-allow.kdl.

Ambient home roots remain ungrantable even if listed.

Operator commands

mnemos sandbox health
mnemos doctor                          # doctrine + resolveMode default
mnemos sandbox run --project . -- sh -c '…'
mnemos run create --project . -- true  # S4: Podman when healthy
JARVIS_SANDBOX=host mnemos run create -- true   # opt out

What this is not

  • Not multi-tenant isolation
  • Not a VM / Kata / gVisor boundary (shared host kernel)
  • Not a substitute for policy/approvals (SPEC-008/009 still apply)
  • Not host confinement of the operator TUI (Enterprise S5)

See also: threat-model.md, SPEC-012 sandbox providers, SPEC-015 elastic remote boxes (DRAFT).