docs: add redundancy analysis to pipelock assessment

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-08 00:25:01 -04:00
parent 5607dce611
commit 08597ebcf8
1 changed files with 111 additions and 0 deletions
@@ -459,6 +459,117 @@ The reasoning:
 ---
 ## Does pipelock make claude-bottle redundant?
 Pipelock is itself an AI-agent firewall with an in-process sandbox mode,
 which raises a fair question: if pipelock can already wrap an agent process
 with Landlock + seccomp + namespaces (or `sandbox-exec` on macOS), is the
 Docker-container layer that claude-bottle provides still doing useful work?
 The short answer: **no, pipelock does not make claude-bottle redundant**.
 The two operate at different layers and the overlap is narrow.
 ### Where pipelock substitutes for parts of claude-bottle
 For a single-agent use case on Linux with full unprivileged-userns support,
 `pipelock sandbox -- claude` could replace the Docker container with a
 process-level sandbox: Landlock restricts the filesystem, seccomp filters
 syscalls, the network namespace forces traffic through the scanner. That is
 a real isolation primitive, not a fig leaf. A user whose only concern is
 "don't let one agent's bug touch my home directory or exfil my keys" could
 plausibly run pipelock on the host and skip Docker entirely.
 ### Where claude-bottle does work pipelock does not
 The redundancy argument breaks down once the actual goals from
 `CLAUDE.md` are enumerated:
 1. **Filesystem isolation that survives a misbehaving agent.** Docker
   containers give an entire kernel-mediated mount namespace and a separate
   root filesystem. Landlock restricts a process's filesystem view but the
   process still runs in the host's mount namespace, with the host's
   `/etc`, `/proc`, `/dev`, and so on visible (modulo the Landlock ruleset).
   For "Claude with `--dangerously-skip-permissions`", a fresh per-agent
   filesystem with nothing in `$HOME` except what was deliberately copied
   in is materially stronger than a Landlock-restricted view of the host
   filesystem.
 2. **Parallel agents.** A primary stated goal is "Allow me to easily spin
   up agent tasks in parallel". claude-bottle launches one container per
   agent invocation with a slug-derived name and a numeric suffix on
   conflict. Pipelock has no equivalent fleet-management concept; it is a
   per-process wrapper. Running `pipelock sandbox -- claude` four times in
   parallel on the host gives four sandboxed Claude processes sharing the
   same `$HOME`, the same shell history, the same `~/.claude/`, the same
   keychain. That is not the same property as four containers each with
   its own ephemeral filesystem.
 3. **The manifest model.** claude-bottle's `claude-bottle.json` carries
   per-agent `env`, `skills`, `prompt`, and `ssh` configuration with
   precise resolution semantics (prompt-at-launch secrets, host-env
   forwarding, literal env-file values, host-key fingerprint pinning).
   Pipelock has a YAML config for its own scanning rules but no concept of
   "for agent X use these env vars, skills, system prompt, and SSH keys".
   These are different problem domains.
 4. **Ephemeral state by construction.** Every container start is a fresh
   filesystem from the image; nothing the agent writes persists unless the
   user explicitly mounts a volume. This property is not derivable from
   pipelock — a pipelock-sandboxed agent on the host writes to the host's
   filesystem (subject to the Landlock ruleset), and persists across
   invocations.
 5. **The SSH-agent-in-container design.** The agent socket runs as root
   inside the container, the keys are deleted from disk after loading,
   and `socat` proxies node's connections so the OpenSSH peer-credential
   check passes. This solves a specific Docker-Desktop-on-macOS limitation
   (no UDS forwarding from host agent into the VM) and gives the property
   that the `node` user can sign with the key but cannot read its bytes.
   Pipelock does not address SSH at all, which is one of its documented
   gaps. claude-bottle's solution remains relevant under either deployment.
 6. **Skill-directory injection per agent.** The `skills` array copies named
   directories from `~/.claude/skills/` into the container at launch. There
   is no analogous concept in pipelock; the skill set claude-bottle exposes
   is part of the per-agent isolation model, not just a configuration.
 7. **Shareability of agent definitions.** A `claude-bottle.json` file can
   be checked into a project repo, and a third party can run the same
   agent with the same env-resolution rules. Pipelock configurations are
   per-installation; they do not encode "this is an agent named X".
 ### The opposite question
 Does claude-bottle make pipelock redundant? Equally no. Docker container
 isolation does nothing about content-level exfil over an allowed channel.
 A misbehaving agent inside a claude-bottle container with HTTPS access to
 `api.anthropic.com` can still attempt to exfiltrate via DNS subdomain
 encoding, prompt-injection responses from MCP servers, or covert HTTP
 parameters. Those are exactly the threats pipelock is designed to detect.
 The containment argument for claude-bottle and the content-inspection
 argument for pipelock do not overlap.
 ### Net conclusion
 Pipelock and claude-bottle are layered defenses, not alternatives.
 claude-bottle provides filesystem isolation, per-agent state ephemerality,
 fleet management, manifest-driven configuration, and the SSH-agent-without-
 key-leak property. Pipelock provides hostname allowlisting, content-aware
 DLP, MCP scanning, and subdomain-entropy DNS exfil detection at the network
 boundary. The strongest deployment is both: pipelock as a sidecar on the
 container's only egress route, claude-bottle as the per-agent container
 orchestrator. Removing either layer leaves a real and named threat
 uncovered.
 The one scenario in which adopting pipelock could justify retiring
 claude-bottle is a single-user, single-agent, host-resident deployment
 where the user is willing to give up the parallel-agent goal, accept
 Landlock-level filesystem restriction in place of mount-namespace
 isolation, and re-implement env / skill / SSH-key / prompt management
 some other way. That is not the use case the project was built for.
 ---
 ## Open questions
 1. **Who is `luckyPipewrench`?** The maintainer is not publicly identified