Level 0 (off, default): no stderr output beyond boot line.
Level 1 (blocks): each block/warn emitted as JSON with reason and
request context (host, method, path, response_status for inbound).
Level 2 (full): level-1 events + egress_request and egress_response
JSON lines for every forwarded connection.
Block logging at level 1+ replaces the previous plain-text stderr write.
DLP warn logging is also gated on level 1+. All block call sites now pass
_req_ctx(flow) so the blocked request is visible in the log entry.
Boot message shows log level label (off/blocks/full).
Adds PRD 0053 documenting wire format, manifest format, and all log event
shapes.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
prd-new-user-provider-plugins → 0053-user-provider-plugins
prd-new-named-labelled-agents → 0054-named-labelled-agents
Both PRDs ship with their implementations so Status flips Draft → Active.
Manual fix: the prd-number workflow did not fire on these merges.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Dashboard no longer exists; remove all references to it
- Active agent display surface is cli list active, not a TUI pane
- Label/color rendered with ANSI escape codes in list output
- Modal called from cmd_start only, no supervisor _new_agent_flow
- Remove _format_agent_row/_color_pair_for curses design (list is
plain text); add _ansi_color() helper design instead
- Clarify slug-suffix caveat: modal appears before prepare() mints
the slug so default label falls back to agent_name
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Single modal with two steps (label then color) instead of
bare text prompts dropped to terminal
- Default label is <agent_name>-<slug_suffix>; first keystroke
replaces the pre-fill rather than appending to it
- Color step shows a navigable list with live color preview;
(none) selected by default; Esc skips
- Modal lives in tui.py and is shared between supervisor flow
and cmd_start
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Renames docs/prds/0052-user-provider-plugins.md to 0053-user-provider-plugins.md
and updates the heading inside the file. 0052 is now reserved for the egress
DLP addon.
Implements #213: PRDs use prd-new-<slug>.md while a PR is open; a
post-merge workflow on main assigns sequential numbers and renames the
file. A required PR check blocks prd-new-*.md from landing on main
without going through the workflow.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Pipelock was removed in PR #193. Update the five remaining places
where current documentation (README, examples/bottles/claude.md,
tests/README.md, docs/ci.md, sidecar_bundle.py comment) still
described the old pipelock + cred-proxy topology.
Research doc: close open questions with decisions from review — hard
cutover on path_allowlist, drop glob (regex sufficient), stick with
Gateway API OR semantics for headers, case-insensitive method names.
PRD 0053: adopt Gateway API HTTPRoute match vocabulary (paths, methods,
headers) as the route schema replacement for path_allowlist. Add
MatchEntry / PathMatch / HeaderMatch types to EgressRoute design; cite
the route matching research doc; fold match restructure into chunk 1
alongside the dlp block.
Adds the product requirements document for replacing pipelock's DLP
capability with a per-route mitmproxy addon. Covers three implementation
chunks: token-pattern detection, known-secret detection, and naive prompt
injection scanning. References the research in PR #192 and issue #195.
Add analysis of Google DeepMind's CaMeL (arXiv:2503.18813), which
prevents prompt injections architecturally rather than detecting them.
Key findings:
- CaMeL operates at the agent execution layer (P-LLM/Q-LLM split +
capability-based data flow tracking), not the network layer
- Not a replacement for pipelock/DLP — different threat surface
- Not viable today: research artifact, requires agent rearchitecture,
doubles LLM costs, 7% utility loss on AgentDojo
- Worth watching: its capability model could complement bot-bottle's
network controls if it matures into production software
Also clarifies pipelock's actual detection capabilities (no prompt
injection detection) and adds naive detector sketch.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Remove all time estimates (2-3 weeks, 1-2 weeks, etc.)
- Add detailed analysis of using LLM for prompt injection detection
- Survey existing models (none purpose-built for this)
- Sketch DistilBERT fine-tuning approach (~67MB quantized)
- Analyze latency/footprint tradeoffs (50-150ms vs. <5ms for patterns)
- Recommend pattern-based Phase 2, with LLM as optional Phase 2b
- Include code sketch of LLM detector with timeout fallback
- List open questions for LLM deployment
Conclusion: Patterns are faster/simpler for now; LLM only if patterns
miss sophisticated attacks in production.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>