From 3eff1e0b6e31a2cb1c91739081b3f381a6ec7609 Mon Sep 17 00:00:00 2001 From: didericis Date: Sun, 10 May 2026 00:41:14 -0400 Subject: [PATCH] docs: replace non-goals with a security model section in README Frames the per-agent isolation story (each bottle gets only the env, skills, ssh, and egress hosts its manifest grants) and is honest about the limits of the container boundary, pointing at the new research doc for the stronger-isolation v2 question. Co-Authored-By: Claude Opus 4.7 --- README.md | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 3ff4fc5..b413ac7 100644 --- a/README.md +++ b/README.md @@ -20,11 +20,22 @@ bottle is destroyed and the genie does not persist. - Allow me to easily spin up agent tasks in parallel - Create isolated, well defined, easily updated, shareable agents -## Non-goals +## Security model -- Communicating between agents directly -- Self hosted VMs (v1 uses local Docker containers, not VMs) -- Advanced agent auditing (lean on git history for auditing) +Each agent runs in its own bottle: its own container, its own internal +Docker network, and its own pipelock sidecar. Bottles don't share +state, don't talk to each other, and only get the env vars, skills, +SSH identities, and egress hosts the manifest grants them — nothing +more. Any one agent only has the access it needs to do its job. + +The container is the boundary against an uncoordinated agent reaching +the host: a misbehaving Claude Code session can't read files outside +the bottle, can't reach the host's network without going through +pipelock, and can't see other bottles. It is not a hardened boundary +against a determined attacker with kernel-level escape capability — +that's a v2 question (see +`docs/research/stronger-isolation-alternatives.md`). The egress proxy +and OAuth-token handling below are the load-bearing pieces of v1. ## Quickstart