Files
Agentic-Bridle/docs/adr/0008-enforcement-scoped-to-mediated-actions.md
wtclaude 06917d43e2 docs: add phased implementation plan and architecture decision records
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
2026-08-08 14:33:27 -05:00

1.6 KiB

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.