When AI does not just read but changes files

A browser-based language model often operates inside a bounded conversation. It reads supplied material and generates text, while a person decides what enters operational files. A local agent can search folders, create files, replace content, run commands and pass results to other systems. This is useful: maintenance, transformation and quality checks can happen directly in the working set. It also moves the boundary from recommendation to effect.

The decisive change is not greater intelligence but greater authority. Granting write access requires workspace boundaries, identity, permissions, change procedure, verification and recovery to be designed as one system. A good prompt neither limits operating-system rights nor reverses an incorrect mutation.

Read, propose, apply and publish are distinct modes

Agentic systems need more than on and off. READ analyses without modification. PROPOSE creates a plan, patch or new files in isolation. APPLY incorporates an approved change into the working state. PUBLISH makes the result authoritative for other people or systems.

Each mode receives separate rights and gates. An agent may prepare a patch autonomously while APPLY needs confirmation and PUBLISH requires an additional quality check. Autonomy is graduated by impact rather than granted wholesale.

The workspace is a security boundary

A local agent needs an explicit root path. It must not interpret an entire home directory, unresolved variables or broad wildcards as scope. Paths are canonicalised before writes and checked against an allowlist. Symbolic links, mounts and network paths need particular care because an apparently local path can resolve outside the intended boundary.

Zones make rights understandable: sources/ remains read-only, working/ accepts changes, review/ holds previews and published/ receives only approved results. Temporary files have their own location and expiry. This prevents a source artefact from being treated as an editable output.

Inspect before changing

Before writing, the agent records target, type, size, checksum, modification time, owner, sensitivity and current revision. It checks whether another actor changed the file after the task began. This prevents stale work from overwriting newer human edits.

Inspection also maps dependencies. Renaming a schema can affect queries, links and exports. Changing configuration can alter the next run. Change reach determines tests and approval requirements.

The plan must be understandable before the patch

The agent first explains which files it intends to change, why, what remains untouched and how success will be tested. It states assumptions, risks and abort conditions. Only then does it produce a concrete patch or preview.

A patch is the smallest inspectable unit. It shows additions, removals and modifications. Structured data also needs a semantic summary of affected records, fields and relationships. „File updated" is insufficient because it hides scope and meaning.

Safe changes are small, atomic and repeatable

Independent goals should not be mixed into one enormous mutation. Small change sets are easier to inspect, test and reverse. New content is written to a temporary file, validated and only then substituted for the target. Where supported, atomic replacement reduces partially written states.

Idempotence matters. Repeating a step must not silently create duplicates or apply increments twice. The agent checks desired end state instead of blindly repeating an operation. Non-idempotent actions need execution identifiers and duplicate protection.

Concurrency creates conflicts

People, agents and automation can edit the same file. Last-write-wins behaviour destroys work without an obvious error. Optimistic concurrency therefore compares checksums or revisions before writing. If the target changed, the agent stops, regenerates the diff and requests a decision.

Locks can help for short operations but need expiry and recovery. Isolated branches or worktrees are often clearer for complex work: each task receives a separate state that can be reviewed and merged later.

Least privilege applies locally

Local does not mean trusted. A process with broad write rights can damage keys, configuration or backups. NIST frames least privilege as limiting access to what is necessary. In practice the agent receives a dedicated identity or isolated process, allowed paths and only required tools.

Read, write, delete, execute and network access are distinct. Formatting needs no internet. Research may download but must not publish. Deletion and recursive operations require exact target validation, preview and approval. Secrets never belong in task instructions or logs.

Read files are not trusted instructions

Documents, pages and messages can contain text that asks an agent to perform unwanted actions. For writing systems, indirect prompt injection can move from retrieved content to file mutation or external transfer.

Architecture treats the task and policy as trusted control while content remains data. Content cannot override permissions, paths or approval rules. Tool calls are independently checked against policy. OWASP notes that no single prompt fully removes this risk; minimum rights, destination allowlists, output validation and human confirmation remain essential.