The safest AI agent is the one that can only see one folder

An AI agent is useful in proportion to what it is allowed to touch, and dangerous in the same proportion. Most agent products resolve that tension by asking you to trust them with the whole machine, or the whole project, and then promising to behave. Filer resolves it differently: the unit of trust is a folder, the amount of trust is a setting on that folder, and both are visible in the same place you already manage your files.

Excessive agency, in one paragraph

OWASP's Top 10 for LLM Applications lists Excessive Agency as a named risk: a system granted more capabilities, broader permissions, or more autonomy than the task at hand needs. The damage a compromised or simply confused agent can do scales with three things — how much it can reach, how fast it acts, and how long nobody notices. An agent with machine-wide access acts at model speed across every credential file, every project and every cloud config on the box; the boundary, if there is one, is a line in a system prompt the model is asked to respect. The recommended remedies are not exotic: minimum necessary capability, separate tool sets per level of trust, a human approving sensitive actions, permissions scoped per task. The question is where those live in the product, and whether the person using it can see them.

A scope you can already see

In Filer an agent belongs to a folder. A folder without an agent has nothing that can be compromised; a folder with one has exactly one agent, and that agent's world is the folder tree beneath it. You can tell which is which from File Explorer — the folder either carries an agent or it does not — with no security dashboard to open and no configuration file to read. The same rule shapes everything else the agent does: chat and AI Search are scoped to the folder you are standing in, and navigating deeper narrows them further.

The write side of that boundary is enforced in code, not by instruction. Every tool that creates, edits, deletes or moves a file resolves its target against the agent's folder tree, and anything pointing at a sibling, an ancestor or somewhere else on the disk is rejected before it runs — symlinks included, since they are resolved to their real path first. Reads are deliberately a little wider, because context from a parent folder makes an agent better at its job; they are governed by the folder's trust level and by a denylist for credential files and system paths, so an agent never reads what it should not.

A trust level per folder, not per machine

How much an agent may do on its own is a slider on the folder, chosen in Filer's Filer AI panel. Seven levels, each adding one class of action to what the folder treats as automatic:

The approval prompt covers the actions that cannot be un-done with a second click: deleting or moving a file, running a command, rolling a folder back to a checkpoint. Those are parked on a prompt and do not proceed until you answer, unless the folder's level explicitly allows them. Creating or editing a file inside the folder runs without a prompt at every level today — there, the folder boundary itself, not a dialog, is what contains the agent. A folder of untrusted downloads can sit at Sandbox while the folder that assembles your weekly report runs at Autonomous, on the same machine, at the same time, with no interference between them.

What the hierarchy guarantees

Folders nest, and so does trust — but only downward. A child folder can never exceed its parent's level: put a project root at Standard and every folder beneath it is capped at Standard no matter what its own setting says. When one agent hands a sub-task to a folder below it, the work runs at that folder's level, not the parent's. The practical effect is that widening trust is always a deliberate act at a place you can see, and narrowing it is the default direction of the tree.

This is the shape the standards ask for. OWASP's remedies for excessive agency map onto it one to one — minimum capability is the level, separate tool sets per level is what the level actually changes, human approval is the prompt, per-task scope is the folder, and every tool call is written to an execution log. The AWS Well-Architected Generative AI Lens recommends minimum-privilege permission boundaries with per-environment isolation for agentic workloads; a folder with its own level is the desktop version of an environment. And the default-deny, verify-per-request posture of NIST's Zero Trust Architecture is what the approval prompt is: destructive and external actions do not proceed on trust, they proceed on an answer.

What Filer does not claim

• Not immunity. A folder boundary limits what a bad outcome can reach; it does not prevent every bad outcome. Prompt injection can still happen inside a folder's scope — a poisoned document can still mislead the agent working on that folder.
• Not the whole model. The folder boundary is one layer. Input and output guards, per-execution process isolation, the secret-file denylist and the approval prompts are the others, and none of them is a substitute for the rest.
• Not the only valid design. Machine-scoped agents exist for good reasons. The claim here is narrower: for work that lives in folders — which is most of the work on a desktop — the folder is a boundary a person can actually reason about, and that is what makes handing more autonomy to it safe.

Rolling this out for a team is mostly a question of which levels to use where — the teams page covers what that involves. For what a folder agent actually does day to day, start with the scheduled-report usecase.

More from the blog