Boundary Contracts: Drawing Clear Permission Boundaries for Coding Agents

Coding agents are increasingly modifying codebases autonomously, but a fundamental question is emerging: merely "seeing" relevant context does not mean having the right operational permissions. A pilot study from RSS proposes Boundary Contracts, a machine-readable abstraction that attempts to explicitly declare each artifact's role in a task before repository modifications occur.

The Problem: Relevant Does Not Mean Editable

The study points out an easily overlooked distinction: an artifact may be highly relevant to a maintenance task yet unsuitable for editing; conversely, an artifact may not be mentioned in the request at all yet be necessary to complete the task.

Traditional approaches rely on context windows or retrieval augmentation, feeding "relevant information" to the agent wholesale. But this conflates "visibility" with "operational authority." An agent might casually modify a configuration file simply because it saw it, or miss modifying a dependency file because the request didn't mention it. The research team identifies this permission ambiguity as one of the core risks of expanding coding agent autonomy.

What Are Boundary Contracts

Boundary Contracts are a machine-readable abstraction that assigns each artifact one of four task-specific roles: editable, inspect-only, required, and protected. These roles are explicitly defined before repository modifications begin, thereby constraining the agent's action space.

According to the study, this contract transforms "should this be changed" from an implicit judgment by the agent into a pre-declared, auditable statement. The agent no longer needs to guess during execution which files are safe; instead, it receives an explicit permission map.

F1 score is a commonly used composite metric in information retrieval and classification tasks, defined as the harmonic mean of precision and recall, ranging from 0 to 1. In this context, the F1 of "macro edit selection" measures how well the set of files the agent chose to modify matches the set of files that "should be modified": precision reflects how many of the files the agent modified were truly supposed to be changed, and recall reflects how many of the files that should have been changed were actually modified by the agent. F1 treats both equally, so it penalizes both "changing too much" and "changing too little." However, F1 only concerns whether file-level selection is correct and does not reflect the quality of the patch content itself—which is why the study also reports the stricter metric of "strictly acceptable patch count."

Pilot Experiment: 40 Real Enterprise Tasks

The research team conducted a pilot study on 40 maintenance tasks in a real enterprise repository, comparing the performance of the same Codex-based coding agent with and without boundary contract information.

The results showed clear differences:

• Macro edit selection F1 improved from 0.440 to 0.682;
• Required behavior coverage improved from 0.429 to 0.673;
• Strictly acceptable patch count improved from 9 out of 40 to 18.

These numbers come from pilot scale, and the study itself explicitly states it does not establish the general validity of boundary contracts on this basis. But the fact that all three metrics improved in the same direction at least suggests that explicit role declarations have a considerable impact on maintenance behavior.

Strictly acceptable patch is a binary metric closer to actual merge standards than F1: a patch is counted as acceptable only if it simultaneously satisfies multiple conditions such as "modifying the correct files," "the changes resolve the task," and "no inappropriate changes were introduced." The study uses a count of "how many of 40 tasks produced strictly acceptable patches" rather than an average score, meaning it characterizes whether the agent can deliver changes end-to-end that would pass human review. This metric is very sensitive to local errors—even if the right files are selected, any out-of-scope modifications in the patch will make it unacceptable. Therefore, the improvement from 9/40 to 18/40, while still low in absolute terms, represents a doubling that indicates explicit role declarations affect not only "where to change" but also "how cleanly the changes are made."

Ruling Out the "Just Better Localization" Explanation

A natural skepticism is: are these improvements simply because the agent more accurately finds the files that should be changed? If it's just better file localization, then the value of boundary contracts would be limited.

To address this, the study additionally analyzed 21 tasks—in which both conditions (with and without contracts) modified at least one identical file. In other words, file localization was already aligned between the two groups. The results showed that differences in edit selectivity and patch outcomes still persisted. The study thus provides preliminary evidence that explicit artifact roles may influence maintenance behavior, not just localization.

The Unanswered Questions Are More Important

The wording of this pilot is notably restrained: it does not claim that boundary contracts are universally effective, but rather positions them as a starting point for a broader research question—as repository-level maintenance becomes increasingly autonomous, how should coding agents' operational boundaries be generated, validated, revised, and ultimately enforced?

These four verbs form a complete governance chain. Generation is deriving roles from task descriptions and repository structure; validation is checking whether the contract is reasonable; revision is responding to task changes; and enforcement is making it impossible for the agent to overstep. The pilot only touches the front end of the chain; enforcement remains to be explored.

From an engineering perspective, the idea of boundary contracts shares similarities with permission systems and access control, but it targets semantic-level "should this be changed" rather than simple read-write permissions. This means that contract generation and validation themselves may become new bottlenecks—if the contract is wrong, the agent may be incorrectly constrained. The study does not discuss this in depth, but it is an unavoidable direction for future research.

Implications for Practitioners

For teams introducing coding agents into real repositories, this pilot delivers an actionable signal: before letting the agent act, first clarify what can be touched, what can only be viewed, what must be handled, and what must not be touched. This kind of pre-declaration requires no complex infrastructure, yet may significantly change patch acceptability rates.

Of course, a pilot on 40 tasks in an enterprise repository is still far from production-level conclusions. Whether boundary contracts can generalize to different repositories and different task types, as well as who generates the contracts and how they are maintained, are all open questions. But at the very least, it turns "agent permission boundaries" from a vague concern into a research object that can be measured and experimented with.

One-line Summary

Boundary contracts declare artifact operational roles before modification; pilot shows they can significantly improve coding agent patch acceptability rates.

Paragraph Summary

This article introduces a pilot study on Boundary Contracts. The study points out that coding agents "seeing" relevant context does not mean having the right modification permissions—the traditional context window approach conflates visibility with operational authority. Boundary contracts are a machine-readable abstraction that declares one of four roles for each artifact before repository modifications: editable, inspect-only, required, and protected. On 40 real enterprise maintenance tasks, the same Codex agent with contracts introduced improved macro edit selection F1 from 0.440 to 0.682, required behavior coverage from 0.429 to 0.673, and strictly acceptable patches from 9/40 to 18/40. The study also used 21 tasks where both groups modified the same files to preliminarily rule out the "just better localization" explanation. The authors emphasize this is pilot scale and do not claim universal validity, but rather raise the broader governance question of how operational boundaries should be generated, validated, revised, and enforced.