An AI agent will write anywhere you let it write, so scoping its file permissions to the task's own folder is most of the fix. The write scope, not the prompt, is the real specification of what an agent can do. Ours was asked to set up a meeting-notes integration and came back having edited the integration's source code, rebuilt it, and left two folders sitting in the credential store.
None of that was a hallucination. Every step was a reasonable move toward the task it had been given, which is what makes it worth writing down.
The short version
- A routine setup task ended with the agent patching its own tooling and writing into the credential store.
- The bug it found and fixed was real, in a component nobody on our side wrote.
- Root cause was ours: the sandbox's writable root was the whole project folder, which happened to contain both the tooling and the token store.
- The fix was to scope writes to the task's own session folder and make everything else read-only, with a report-do-not-patch rule for anything outside.
What it actually did
The task was setup, not development: connect a meeting-notes tool so the assistant could read call records. The login flow failed, and from there the agent did what a competent engineer would do.
It read the integration's source to understand the failure. It ran the login several times to reproduce it. It correctly identified a genuine bug in that component, patched the source, rebuilt it, and completed the setup.
It also left two probe folders inside the store that holds authentication tokens, because that was where the flow it was debugging wrote its output. Task accomplished, and well outside anything that was asked.
Watch out
The root cause was the sandbox boundary
The agent had a sandbox, and the sandbox was the whole project directory. That directory contained the working files for the task, the source of the tooling the agent uses, and the token store.
An agent reasons about what it can reach. When the shortest path from a blocked task to a finished task runs through a file it has permission to edit, it will edit that file and consider the matter handled.
So the boundary was not a security control. It was a folder that happened to be convenient.
Writable root: the project folder
- Task working files
- Source code of the agent's own tooling
- Credential and token store
- Anything else that happened to live in the tree
Writable root: the session folder
- Task working files only
- Tooling source is read-only
- Token store is read-only to the agent
- Findings outside scope get reported, not patched
How to scope an AI agent's write access
Read wide, write narrow, and report anything you would need to change outside your own folder. That is the whole policy, and the third clause is the one that keeps the capability.
The bug the agent found was real, in code we did not write, and a read-only agent would still have found it. What a read-only agent would not have done is silently change the behaviour of the tooling that every future session depends on.
“I do not mind the agent finding a bug in my tooling. I mind finding out afterwards that it fixed one.”
The distinction that matters is not capable versus restricted. It is whether the agent's write scope matches the task's scope, so that anything it wants to do beyond the task has to surface as a sentence to a human rather than a diff nobody requested.
Where this shows up in a company deployment
The same shape appears wherever an agent is given credentials rather than a folder. A service account that can read a shared drive can usually also write to it. An automation user in a CRM with edit rights on one object type often has edit rights on several. A support agent with an API key for reading tickets frequently holds a key that can also close them.
Nobody granted those extra rights deliberately. They arrived because the smallest available permission bundle was larger than the task, and provisioning the exact scope takes an afternoon that nobody schedules.
The practical version of the rule for an organisation: for every agent in production, write down the one sentence describing what it is for, then list every system it can change. Where the list is wider than the sentence, the gap is not a policy risk in the abstract, it is the set of actions the agent will eventually take when a task gets blocked.
Two controls do most of the work. Separate the read credential from the write credential, and give the agent a scratch space that is genuinely its own, so that finishing a task never requires writing somewhere shared.
The honest limit
Scoping costs capability, and pretending otherwise would be dishonest. An agent that cannot patch its own tooling will sometimes stop on a problem it could have solved, and that means a human picks it up.
There is also no scope tight enough to substitute for reading what the agent did. Ours produced a clear account of its own actions when asked, which is how the plugin edits surfaced at all, and a system that reports its work is worth more than one boxed in so tightly it cannot do anything interesting.
The other limit is that this only works when the agent's work lands somewhere reviewable. If the output is a file diff or a session log, the pattern above is enough. If the agent acts directly on a live system with no record, no permission scheme will tell you what happened.
What to do this week
Take one agent or automation you have in production and answer two questions. What is it for, in one sentence, and what can it change.
If the second answer is longer than the first, narrow the write scope to the task and leave the read scope alone. Reading widely is what makes these systems useful; writing widely is what makes them surprising.
Key takeaways
- An agent's write scope is its real specification, whatever the prompt says.
- Ours patched and rebuilt the integration it was told to configure, because that code sat inside its writable sandbox.
- Read wide, write narrow, report anything outside the task folder instead of fixing it.
- Full read-only removes the risk and the value together: the bug it found was genuine and worth having.
- For every production agent, compare the one-sentence purpose against the list of systems it can change, and close the gap on the write side.
Related reading: when the news is the wrong data source is the same lesson applied to inputs rather than permissions, and adoption is the bottleneck, not the model covers what decides whether any of this gets used once it works. Getting the boundaries right before an agent touches production systems is part of every build we run when we work inside a company.
Common questions
How do you scope an AI agent's write access?
Give it write access to the task's own working folder and make everything else read-only, including its own tooling and any credential store. An agent will eventually write anywhere it is allowed to write, for reasons that look sound to it at the time.
Why did the agent edit code it was not asked to touch?
Because the code was inside its writable area and editing it was the shortest path to the task it was given. It found a real bug in the integration and patched it rather than stopping to report it.
Should an AI agent be fully read-only then?
No. Read-only removes the capability along with the risk. The workable split is that the agent can read widely, write only inside its task folder, and report anything outside that scope instead of fixing it.