Attaching a permission hook to one tool does not protect you from all tools. That is the short version of a lesson developer Markus Eisele documented after working with a coding agent on a scoped Java task.
What He Was Trying to Do
The task was narrow: update a Java endpoint, adjust the corresponding tests, and leave the rest of the project untouched. He wrote that constraint into the prompt, then added a hook as a hard enforcement layer. The hook was a small program designed to run before any file edit and reject changes that fell outside the allowed scope.
He attached the hook to write_file. The agent updated the endpoint and the test. The test passed. On the surface, everything worked.
Where the Gap Was
When Eisele reviewed the tool call log, neither edit had passed through his hook. The agent had chosen apply_diff instead of write_file. Because the hook was only registered against one tool, the other tool ran without any check at all.
The guardrail was real. It just covered the wrong door.
The Takeaway for Operators and Dev Teams
If you are building or running agentic coding workflows, hooking a single editing tool is not enough. Agents have multiple tools that can write to the file system, and they will pick whichever one fits the task. A complete guardrail strategy means covering every tool that can touch files, not just the most obvious one.
Eisele frames it as a gap in tool permissions rather than a flaw in the agent. The agent did exactly what it was asked. The enforcement layer just was not wide enough.
