Broad access is the unsafe default
When an AI agent touches 31 files to do a 2-file job, something went wrong before the first line ran. Scope discipline prevents approval surprises, not after them.
What we observed
A routine task: update the API response format for one endpoint. The instruction was clear. The agent had access to the whole repo. It completed the task correctly. It also touched 29 other files on the way there.
Not maliciously. Not randomly. The agent used what it could see to gather confidence. It read widely, confirmed widely, and left traces widely. From the agent's perspective, thoroughness looked like good behavior. From a review perspective, it looked like an audit event.
The task was 2 files. The review surface was 31.
What changed when scope was enforced
Why broad access feels safe
Context helps agents work. The more an agent can see, the better it can reason about edge cases, naming conventions, related behavior. Giving broad access feels like giving good tools.
The problem is that access and scope are not the same thing. An agent can have read access to 200 files to inform its reasoning while only writing to 2. Without that separation, the default is that writing follows wherever reading went.
Access is what you can reach. Scope is what you are supposed to touch. Conflating the two turns every task into a surface area problem.
What Avorelo does differently
Avorelo sets task scope at the start of each run, not at review time. When a task is routed, it carries a file boundary declaration: the set of files this task is expected to write, and the set of files it is allowed to read for context.
If the agent's planned changes fall outside the write boundary, Avorelo flags it before the run continues. The agent is not stopped from doing good work. It is stopped from expanding scope without acknowledgment.
This prevents the common failure mode where a scope drift is discovered at review time, after the work is done, when the cost of catching it is highest.
The outcome in practice
In the observed case, scope narrowing reduced the write surface from 31 files to 2. The work was correct in both cases. But the 2-file version required no approval escalation, no cross-team coordination, and no line-by-line audit of unrelated changes.
The 31-file version was not wrong. It was expensive in a way that does not show up in correctness metrics.
Scope discipline is not about limiting agents. It is about making the review surface match the task surface, so the cost of verification stays proportional to the work done.
What to watch for in your own work
- Tasks that complete correctly but leave changes in unrelated files
- Review requests that cover files nobody expected to be in scope
- Agents that read configuration or shared utilities and then modify them
- PR descriptions that accurately describe the intent but not the full diff
Each of these is a sign that scope was not set before the run started. The task completed, but the boundary was never drawn.
Set scope before the run starts.
Avorelo enforces task boundaries automatically. Your review surface stays proportional to the work done.
Start free in your repo