refactor!: rename project to bot-bottle
Assisted-by: Codex
This commit is contained in:
@@ -1,4 +1,4 @@
|
||||
# Pipelock assessment for claude-bottle egress control
|
||||
# Pipelock assessment for bot-bottle egress control
|
||||
|
||||
Research into whether pipelock — an open-source AI agent firewall —
|
||||
is a suitable replacement for, or complement to, the egress-control
|
||||
@@ -10,7 +10,7 @@ tripwire approach sketched in `secret-exfil-tripwire-encodings.md`.
|
||||
- Pipelock (`luckyPipewrench/pipelock`) is an open-source AI agent
|
||||
firewall implemented as a single Go binary. It sits inline as an HTTP
|
||||
forward proxy and, optionally, applies OS-level process containment. It
|
||||
is the most directly relevant tool found for claude-bottle's egress /
|
||||
is the most directly relevant tool found for bot-bottle's egress /
|
||||
data-exfiltration concerns.
|
||||
- Its strongest differentiator over the v1 iptables recommendation is
|
||||
**content-aware DLP**: it matches 48 credential patterns across
|
||||
@@ -238,12 +238,12 @@ The following threat-model items from `network-egress-guard.md` are
|
||||
|
||||
---
|
||||
|
||||
## Fit for claude-bottle
|
||||
## Fit for bot-bottle
|
||||
|
||||
### Deployment topology
|
||||
|
||||
Pipelock explicitly supports two deployment shapes relevant to
|
||||
claude-bottle:
|
||||
bot-bottle:
|
||||
|
||||
**Sidecar proxy.** A separate container running pipelock on an
|
||||
`--internal` Docker network, with the agent container's only route to the
|
||||
@@ -269,12 +269,12 @@ its own scanner. This avoids a second container but introduces the
|
||||
`--best-effort` degradation problem described below and means the agent and
|
||||
the proxy run in the same failure domain.
|
||||
|
||||
The sidecar topology is recommended for claude-bottle because it matches
|
||||
The sidecar topology is recommended for bot-bottle because it matches
|
||||
the existing Python-orchestrated multi-container model (the SSH key agent
|
||||
already uses a separate process), keeps pipelock outside the agent's kill
|
||||
reach, and avoids the `--best-effort` issue on macOS Docker Desktop.
|
||||
|
||||
The claude-bottle manifest model would need one new piece of plumbing: a
|
||||
The bot-bottle manifest model would need one new piece of plumbing: a
|
||||
per-agent pipelock ACL YAML generated from the manifest's `allowlist`
|
||||
and `ssh` entries, analogous to what the smokescreen section of
|
||||
`network-egress-guard.md` already sketches. The `cli.py` changes required
|
||||
@@ -341,7 +341,7 @@ generated with `pipelock generate config --preset balanced > pipelock.yaml`.
|
||||
The config watcher picks up changes at runtime (100ms debounce on SIGHUP or
|
||||
file events), so per-agent ACL updates do not require a container restart.
|
||||
|
||||
For claude-bottle, the relevant per-agent configuration is the domain
|
||||
For bot-bottle, the relevant per-agent configuration is the domain
|
||||
allowlist. The manifest already captures the necessary inputs: the `ssh`
|
||||
array has target hostnames, and an `allowlist` key is planned for the v2
|
||||
egress work (per `network-egress-guard.md`). Generating a per-agent pipelock
|
||||
@@ -353,14 +353,14 @@ The YAML format is more expressive than smokescreen's YAML ACL: it also
|
||||
carries DLP sensitivity settings, per-domain data budgets, and rate limits.
|
||||
For a first integration pass, only the `api_allowlist` section needs
|
||||
per-agent population; the rest of the defaults are appropriate for the
|
||||
claude-bottle threat model.
|
||||
bot-bottle threat model.
|
||||
|
||||
### Runtime footprint
|
||||
|
||||
A single Go binary, ~12–20 MB (sources report slightly different figures; the
|
||||
GitHub description says "~20 MB" and the randomcpu.com writeup says "~12 MB").
|
||||
Zero runtime dependencies; the Go standard library is statically linked. This
|
||||
is consistent with claude-bottle's low-dependency principle. Adding Go as a
|
||||
is consistent with bot-bottle's low-dependency principle. Adding Go as a
|
||||
host build dependency is not required — the binary is fetched from a Docker
|
||||
image or Homebrew.
|
||||
|
||||
@@ -410,7 +410,7 @@ The reasoning:
|
||||
everything smokescreen covers (CONNECT-based hostname allowlisting,
|
||||
RFC 1918 blocking, Docker `--internal` network isolation) and adds DLP,
|
||||
subdomain-entropy DNS exfil detection, MCP scanning, and request
|
||||
redaction. The integration shape for claude-bottle is identical: a
|
||||
redaction. The integration shape for bot-bottle is identical: a
|
||||
separate container on an internal Docker network, with the agent's
|
||||
`HTTPS_PROXY` pointing at it. The `cli.py` changes are the same pattern.
|
||||
|
||||
@@ -454,7 +454,7 @@ The reasoning:
|
||||
hostname-based allowlisting, content DLP, subdomain entropy analysis, and
|
||||
MCP scanning on top of the v1 IP layer. Implementation effort is comparable
|
||||
to the smokescreen plan; capabilities are a strict superset for the
|
||||
claude-bottle threat model.
|
||||
bot-bottle threat model.
|
||||
- **DIY tripwire script (deferred):** the `secret-exfil-tripwire-encodings.md`
|
||||
DIY sketch can be deferred entirely if pipelock's DLP patterns cover the
|
||||
secrets in use. Custom patterns (for secrets not matching pipelock's 48
|
||||
@@ -463,17 +463,17 @@ The reasoning:
|
||||
|
||||
---
|
||||
|
||||
## Does pipelock make claude-bottle redundant?
|
||||
## Does pipelock make bot-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?
|
||||
Docker-container layer that bot-bottle provides still doing useful work?
|
||||
|
||||
The short answer: **no, pipelock does not make claude-bottle redundant**.
|
||||
The short answer: **no, pipelock does not make bot-bottle redundant**.
|
||||
The two operate at different layers and the overlap is narrow.
|
||||
|
||||
### Where pipelock substitutes for parts of claude-bottle
|
||||
### Where pipelock substitutes for parts of bot-bottle
|
||||
|
||||
For a single-agent use case on Linux with full unprivileged-userns support,
|
||||
`pipelock sandbox -- claude` could replace the Docker container with a
|
||||
@@ -483,7 +483,7 @@ 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
|
||||
### Where bot-bottle does work pipelock does not
|
||||
|
||||
The redundancy argument breaks down once the actual goals from
|
||||
`CLAUDE.md` are enumerated:
|
||||
@@ -499,7 +499,7 @@ The redundancy argument breaks down once the actual goals from
|
||||
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
|
||||
up agent tasks in parallel". bot-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
|
||||
@@ -508,7 +508,7 @@ The redundancy argument breaks down once the actual goals from
|
||||
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
|
||||
3. **The manifest model.** bot-bottle's `bot-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).
|
||||
@@ -530,43 +530,43 @@ The redundancy argument breaks down once the actual goals from
|
||||
(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.
|
||||
gaps. bot-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 no analogous concept in pipelock; the skill set bot-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
|
||||
7. **Shareability of agent definitions.** A `bot-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
|
||||
Does bot-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
|
||||
A misbehaving agent inside a bot-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
|
||||
The containment argument for bot-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,
|
||||
Pipelock and bot-bottle are layered defenses, not alternatives.
|
||||
bot-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
|
||||
container's only egress route, bot-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
|
||||
bot-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
|
||||
@@ -587,7 +587,7 @@ some other way. That is not the use case the project was built for.
|
||||
from an unvetted source. Pinning by digest (as the CLAUDE.md recommends
|
||||
for supply-chain hygiene) and building from source are both options.
|
||||
|
||||
3. **What is the actual DLP false-positive rate for the secrets claude-bottle
|
||||
3. **What is the actual DLP false-positive rate for the secrets bot-bottle
|
||||
agents use?** The 48 patterns cover well-known credential formats. Custom
|
||||
patterns can be added but the mechanism (signed rule bundles) is not
|
||||
documented in detail in public search results. Before v2, testing against
|
||||
@@ -606,12 +606,12 @@ some other way. That is not the use case the project was built for.
|
||||
integration work, audit which capabilities cited above are in the
|
||||
Apache 2.0 core and which require accepting ELv2 terms (which permit
|
||||
internal use and modification but prohibit offering pipelock as a
|
||||
managed service). For claude-bottle's local-Docker single-user use case,
|
||||
managed service). For bot-bottle's local-Docker single-user use case,
|
||||
ELv2 is likely acceptable, but the determination should be explicit.
|
||||
|
||||
6. **Can pipelock's YAML config be generated per-agent from the manifest in
|
||||
a way that handles the `ssh` array correctly?** The `ssh` array in
|
||||
`claude-bottle.json` contains hostnames, ports, and `KnownHostKey` entries.
|
||||
`bot-bottle.json` contains hostnames, ports, and `KnownHostKey` entries.
|
||||
These need to be mapped to pipelock's `api_allowlist` (for HTTP) and
|
||||
potentially to a separate bypass for the SSH socket. SSH is opaque to the
|
||||
HTTP proxy and does not go through `HTTPS_PROXY`; the allowlist entry is
|
||||
|
||||
Reference in New Issue
Block a user