wtclaude
06917d43e2
Turns the design doc into an ordered, dependency-correct build plan (phases 0-9) with an exit criterion per phase, and records the twelve architectural decisions it rests on as ADRs. Decisions: single Rust binary with routed compose services; Streamable HTTP only; per-agent bearer tokens with clientInfo as a display hint only; SQLite; get_rules delivered via session gating; full-document rule delivery; project_id from day one; enforcement tier scoped to Bridle-mediated actions; stable tool list on upstream failure; OpenAI-compatible embeddings with model/dim guarding; pattern RAG gated behind a spike; CLAUDE.md + AGENTS.md as v1 renderer targets. Deviates from the design doc's original 1-8 ordering by moving the audit log and multi-project schema into phase 1, building the admin API incrementally rather than all at the Web Panel phase, downgrading vendor guardrail sourcing to manual-first, and gating the pattern-example RAG behind a validation spike. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019RZerbsHGF9Ka3bKhCjJ9m
36 lines
1.6 KiB
Markdown
36 lines
1.6 KiB
Markdown
# ADR-0008: `enforcement` severity scoped to Bridle-mediated actions
|
|
|
|
**Status:** Accepted (2026-08-08)
|
|
|
|
## Context
|
|
|
|
The design doc defines an `enforcement` guardrail tier where "the gateway itself gates the action
|
|
rather than relying on the agent to self-report". As written this implies more than the
|
|
architecture can deliver: the gateway can only gate actions that route **through** the gateway. Any
|
|
agent with shell access can `git push` directly, `curl` the Kanboard API, or read a token off disk,
|
|
and Bridle will never see it.
|
|
|
|
Adding optional per-agent interceptors (for example Claude Code `PreToolUse` hooks) that consult
|
|
Bridle before the agent's own tools run would close the bypass, but is agent-specific, brittle
|
|
across vendor updates, and requires a client-side install per agent.
|
|
|
|
## Decision
|
|
|
|
Redefine the tier honestly: **`enforcement` means the gateway refuses the action when that action
|
|
is Bridle-mediated.** The bypass is documented as a known limit, in the user-facing documentation
|
|
and not only here.
|
|
|
|
Covered: Gitea, Kanboard, secrets, and rules approval accessed through Bridle.
|
|
Not covered: the agent's own shell, `curl`, or `git`.
|
|
|
|
Behavioral enforcement via agent-side hooks is explicitly out of scope for 1.0.
|
|
|
|
## Consequences
|
|
|
|
- The tier is accurate rather than aspirational, and ships in phase 1.
|
|
- No per-agent brittleness and no client-side component.
|
|
- Users must understand that Bridle constrains what flows through it, not what an agent can
|
|
physically do. Under-communicating this would be worse than not having the tier.
|
|
- Genuine behavioral enforcement, if ever wanted, needs agent-side hooks or network egress control
|
|
— a separate effort.
|