Sensitive Write Boundary

Purpose

Sensitive Write Boundary defines the project-control surfaces an AI coding agent must not create, edit, move, or delete without explicit user confirmation in the current task.

It is a pre-write approval gate, not a diff-review checklist:

planned write -> protected-surface match -> explicit confirmation -> scoped write -> evidence

sensitive-code.md classifies risky content after a diff exists. This boundary acts earlier: it stops an unconfirmed write to a project-control surface before the diff is created.

Protected Surfaces

Trigger before any write whose target path matches one of these surfaces:

Surface	Typical paths	Why it is protected
Repository root files	README.md, AGENTS.md, LICENSE, package.json, lockfiles, dotfiles such as .gitignore or .editorconfig	They define project identity, agent behavior, and dependency contracts for every consumer.
Configuration	config/, linter and compiler configs, environment templates	One edit silently changes behavior for all builds, tools, and agents.
Documentation contracts	docs/, ADRs, specs, published architecture	They are the reviewed source of truth other work is validated against.
Shared automation	tools/, scripts/	Other workflows, hooks, and CI jobs execute these paths.
Hook lifecycle	hooks/, Git hook wiring, agent hook definitions	Hooks run automatically and can block or bypass safeguards.
CI/CD and release	.github/workflows/, pipelines, release and install scripts	Supply-chain and release paths execute with elevated trust.
Migration and schema	database migrations, schema definitions, seed data	Effects persist in data and are hard or impossible to roll back.

Projects may extend this table with their own control surfaces. Keep the project-specific path list in project policy or analyzer config; this document owns the boundary rule, not the path inventory.

Confirmation Rules

1. Match the target path against the protected surfaces before writing, not after the diff exists.
2. Confirmation must be explicit, current, and scoped: the user names the surface or file, the intended change, and the expected effect. Silence, topic similarity, or a generic "go ahead" from an earlier task does not qualify.
3. Approval does not carry over. One confirmation covers one described write set; a new task, session, or additional surface needs fresh confirmation.
4. A task instruction authorizes a protected write only when it names the surface. "Fix the failing tests" does not authorize editing a CI workflow; "update .github/workflows/ci.yml to fix the failing job" does.
5. Without confirmation, the agent proposes instead of writing: target paths, a change summary, the reason, and the expected effect, then waits. If the change can live outside a protected surface, route it there instead.
6. Never batch a protected write silently inside a broader change. Surface it as its own confirmation item even when the rest of the change is approved.

Required Evidence

For every write to a protected surface, record:

• target path and matched surface category
• confirmation source: the user message or instruction that named the surface
• change summary and expected effect
• validation command or test run after the write
• rollback route if the write must be undone

Escalation

If a protected write already happened without confirmation:

1. Report it immediately; do not fold it into an unrelated summary.
2. Show the diff and offer to revert.
3. Route the diff through review-trigger.md and sensitive-code.md for review classification before any further work builds on it.

Non-Goals

This file does not:

• implement permission enforcement, sandboxing, or filesystem ACLs
• replace code review or the diff classification in sensitive-code.md
• restrict reads, analysis, or drafting proposals about protected surfaces
• own Git or agent hook mechanics; use git-hooks.md for hook lifecycle placement

It defines when a write needs explicit user confirmation and what evidence the confirmation and the write must leave behind.