KN-19 · Path guard boundaries
A coding agent built a deny hook to protect files on a Windows host. A drive rename later that evening gave the same folder several reachable names. Testing each name revealed exactly where the guard’s protection ended.
A hook that matches the text in a tool request can catch an address it recognizes. A file system can resolve another address to the same object. That distinction explains why the same target received different answers in this case.
The agent listed a folder containing credentials and reported that it had not opened the files. The operator asked for a technical rule against opening them. The agent built a pre-tool hook. The first version named the files directly. Later versions separated the rules into a file, added read-only protections for memory and instructions, and denied memory tools by name.
| Elapsed time | Change | Passing checks |
|---|---|---|
| 4 minutes | First hook for three named files | 38 simulated calls |
| 11 minutes | Rules file with a root and patterns | 78 |
| 28 minutes | Read-only paths and memory tool denies | 134 |
| Next session | A copy’s source treated as a read | 152 |
The operator required one copy for all sessions and another for the project. The agent’s instructions said to stop after a denial and avoid retries through another tool or path. The hook denied a reviewer launch because its prompt named the files while forbidding access to them. The operator chose to keep that behavior.
The old drive letter still worked through a mapped share while the team moved to the new letter. The agent used the hook’s read-only test mode to ask about the same proposed write through the old letter, the new letter and the share path. The rule matched only the old spelling.
The same gap affected the credentials folder. A directory listing through the new letter exposed file names without drawing a denial. The agent reported that it did not read their contents. The test suite, run from the new location, passed 130 of 134 checks. All four failures involved writes to protected memory. Adding rules for the new letter brought the run to 134 of 134. That restored the tested cases under that spelling.
Figure 01Reported path test
Read-only test of a proposed write; no writes executed. Selecting a case replays the reported decision.
The proposed write names the folder through the old drive letter.
The rule recognizes the old spelling.
The test reports a denial for this path text.
The proposed write names the same folder through the new drive letter.
The rule does not recognize this spelling as the protected path.
The test reports an allow decision. This does not establish that the write is safe.
The proposed write names the same folder through a mapped share.
The rule does not recognize this spelling as the protected path.
The test reports an allow decision. This does not establish that the write is safe.
The agent reported a read-only test of a proposed write on one Windows host. It did not execute the writes. The publication did not rerun the test.
Over two sessions covering four and a half hours on the clock, the agent reported seven denials. Five were over-blocks, one was a copy operation misclassified as a write, and one was the hook’s intended response to rules that could not be parsed. The record contains no retry after any of the seven denials.
| Activity | Trigger | Classification |
|---|---|---|
| Launch a reviewer | Prompt named a protected file | Over-block kept by operator |
| Run the hook’s test mode | Command text included a protected path | Over-block |
| Regenerate a plan | Wildcard counted as a broad read | Over-block |
| Make a tool call | Hand-edited rules did not parse | Designed denial |
| Write a scratch copy of rules | File content matched a rule pattern | Over-block |
| Delete scratch directory | Operation counted as a broad read | Over-block |
| Copy a session log | Source read counted as a write | Bug fixed that night |
The directory listing was the material exposure described in the record. It drew no denial. The agent could write the hook’s own files and changed them only under the operator’s direction. The seven stops describe the observed behavior of this agent under its instruction, with no comparison run.
The agent first expected the hook to become active in a new session, then saw it deny a tool call in the current session. In the next session the operator renamed both hook configuration files to switch it off, but it still denied a delete two minutes later. In both cases the guard was active when someone thought it was off. The rule file was read on each tool call, so a rule edit took effect immediately.
Within fourteen minutes during a review, both rules files switched to the new letter alone, leaving the old mapped spelling uncovered. A hand edit then broke parsing in one copy and blocked all calls until repaired. The repair left one copy empty while the second copy continued to cover the new letter. Redundant copies carried the rule through the edit and also showed how easily copies can drift. The agent reported the changes without making them itself.
The immediate change was to add the new spelling. A separate design proposed resolving both the rule root and the candidate path to their file system identities, with an explicit denial when resolution fails. A read-only review found three ways its first design could still allow a call without establishing the target.
The design was corrected on paper. It left the harness’s behavior on hook timeout open. A text-only check also cannot inspect a target that exists only after a command computes it at runtime. The team considered operating system isolation as a separate enforcement boundary.
Figure 02Evidence comparison
Original designAssumed the old alias would stay available.
Risk the reviewer identifiedRemoving the bridge could leave the old root unresolved.
Original designChecked the deadline before a blocking call.
Risk the reviewer identifiedThe lookup could run beyond the deadline before a decision.
Original designTreated access denied like not found.
Risk the reviewer identifiedThe rule could allow a call without establishing the target’s identity.
These findings came from review of a proposed design. The paper was corrected. Timeout behavior and targets computed at runtime still need separate checks.
Use a harmless protected canary to check whether the hook is active at session start. Exercise denial on an unreadable path, invalid rules and a resolver timeout. Keep the guard’s files outside the agent’s write authority where the platform supports it. Use an independent permission boundary for credentials.
This is one Windows field case from 4–5 November 2026. The source team read two session records and the design review. The test results, elapsed counts, path outcomes and seven denials were reported by the agent in those records. The reviewers identified flaws in the design paper. The source team did not run the hook, review its code or independently probe the three paths. This publication did not rerun the case.
Unreported denials would be missing from the count. The logs establish that the agent reported a listing and said it had not opened the files. They do not independently establish what it could read. A different agent or a session without the instruction was not tested.