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.

Approval needs a concrete object

„Yes, continue" is meaningful only when bound to a specific plan, diff and target revision. An approval identifier records person, time, change set, target state and permitted action. If the patch changes afterward, approval expires.

Gates scale with impact. Spelling fixes in drafts may apply automatically. Rules, prices, permissions, personal data and published content need human review. Irreversible or external actions receive a separate confirmation immediately before execution.

Version control is a control, not complete backup

Git can expose differences, label states and restore selected content. A good commit connects change, purpose, tests and responsible identity. Before committing, the agent checks that unrelated or sensitive files are excluded.

Version control does not cover every failure. Deleted repositories, damaged history, large untracked artefacts and committed secrets require independent backup and recovery. Restoration must be rehearsed. Rollback also cannot automatically undo downstream effects when content has already been exported or another process triggered.

Verification begins after mutation

A syntactically valid file may be professionally wrong. Verification therefore checks readability, schema, links, references, tests, expected artefacts and prohibited side effects. For prose it includes source binding, terminology, internal names and language completeness.

The test plan exists before the change, preventing success criteria from being adjusted afterward. Failed checks return a clear state, preserve the patch and trigger either automatic reversion or human decision.

Every effect needs provenance

A run report records request, agent identity, workspace, input revision, plan, changed files, patch, tools, tests, approvals, output revision and residual uncertainty. SLSA and W3C PROV provide transferable principles for describing where, when and how artefacts were produced.

Only necessary evidence is retained. Sensitive content can use hashes and references. The report must answer who or what changed which file, from which source, under which approval and with what result.

Operations need a stop switch and error budget

Agents begin in READ or PROPOSE. APPLY expands first to small reversible cases. Teams measure wrong targeting, unnecessary edits, conflicts, reverted patches, failed tests and false approvals. Exceeding an error budget returns the workflow to a less autonomous mode.

A stop switch removes write and network rights without deleting evidence. Open changes remain isolated. A manual fallback keeps the organisation functional without the agent. Autonomy must not become an irreplaceable single point.

Method: SCOPE → INSPECT → PLAN → PATCH → VERIFY → APPROVE → COMMIT → REPORT

SCOPE limits target and rights. INSPECT records state and dependencies. PLAN explains impact and abort conditions. PATCH creates a small preview. VERIFY checks syntax, domain quality and side effects. APPROVE binds a decision to the exact patch. COMMIT applies atomically and versions the state. REPORT records provenance, tests and uncertainty.

The transition to a local agent succeeds when write access becomes a chain of small, inspectable and recoverable state changes rather than invisible freedom.

Worksheet: Design a Safe File Mutation Protocol

1. Choose a real file change and classify it as READ, PROPOSE, APPLY or PUBLISH.

2. Define root path, allowed file types, forbidden targets and minimum rights.

3. Specify inspection, conflict detection and abort conditions.

4. Describe plan, diff, semantic effect and required approval.

5. Define seven checks before and after application.

6. Plan commit, independent backup, rollback and downstream-effect handling.

7. Design a run report with evidence, owner and residual uncertainty.

Reflection: Which current agent action has more permission than its purpose requires? Which file change is technically reversible but professionally consequential?

All materials to download — the topic overview and the worksheet:

Scope: Local execution and version control are not automatic guarantees of security or backup. The model is product-independent and must be adapted to the operating system, data class, jurisdiction and impact of a change. Editorial and technical review: 17 July 2026.