# 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.