# An Agent With Write Access Needs a Written Boundary File ## Claim An AI coding agent with repository write access needs an explicit written statement of what it may and may not touch before it goes near vendored or plugin code, because nothing in the repository layout tells it where authorship ends. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds wherever an agent can write to a tree containing third-party or vendored code it did not author. - Requires the agent to have a mechanism that reads and honours an instructions file, and requires that file to be kept current as the tree changes. - A stale boundary file is worse than none: it reads as authoritative while describing a layout that has moved. - The boundary is about provenance, not about danger — vendor code is off-limits because edits there get overwritten, not because the edits are unsafe. ## Evidence From Helen Hou-Sandí's WordPress Accessibility Day 2025 session on continuous AI for accessibility: the agent is framed as an eager new hire that will edit plugin code unless told not to. ## Links - [[Write Agent-Facing Docs Assuming the Agent Wont Fetch the Reference]] — the writing constraint that makes such a boundary file actually work — state it inline, not behind a link - [[Issue Structure Raises Agent Fix Quality More Than Model Choice]] — the same session's other lever: shape the task, not the model - [[AI Documentation Pipelines Need an Explicit Authority Source]] — the same need for a named source of truth, applied to docs rather than to write scope - [[3. Resources/MOCs/AI Agent Safety MOC]] — the bounded-action thread — this is the write-scope control rather than a claim about model behaviour.