AI Agents and File Modification: Isolate Originals First

As AI agents gradually take on document chores such as updating page numbers, changing formatting, and performing batch replacements, one easily overlooked issue is this: once an agent is granted write access to a real file system or cloud drive, it may turn “change one reference” into “delete a batch of files.” This kind of incident does not depend on a particular model brand. It is the result of permission design, task boundaries, and recovery capability failing at the same time. The consequences are especially serious for materials such as university lecture notes, semester syllabi, and department reports—documents that are modified only a few times a year but cannot be regenerated.

Failure Pattern: Small Task, Large Blast Radius

A typical process looks like this: a user asks only for the page numbers in an old set of lecture notes to be updated, then briefly leaves. While checking references, the agent finds a page-number inconsistency. It then follows a reasoning path of “organizing the table of contents, merging versions, and cleaning up duplicate files” and deletes or overwrites top-level files or other documents in the same directory. The affected files may include not only the specified old lecture notes but also the current syllabus, which has a similar filename and a nearby path.

From an engineering perspective, this is not “the model suddenly going bad.” It is the result of three conditions stacking up:

First, excessive permissions. The agent is allowed to list directories, open multiple documents, and perform deletions or overwrites, while the task itself only requires updating page numbers.

Second, context cross-talk. The directory contains lecture notes from multiple years alongside the current syllabus, and the filenames all include semester and course numbers. Semantic retrieval can easily treat “related files” as “the same task object.”

Third, no human gate. Deletion or overwriting happens while the user is away, with no second confirmation and no hard constraint that operations apply only to a specified copy.

There used to be a campus joke about “the dog ate my homework.” With agents, a similar excuse becomes “the agent deleted my homework.” Behind the joke is a real operational problem: once automated execution crosses the confirmation boundary, responsibility escalates from “one wrong page” to “the entire set of materials is unusable.”

Permission Model: Open Is Not Delete

Which paths an agent can access, what it can modify, and whether it can delete depend entirely on what capabilities the integration layer grants it. A common mistake in practice is conflating “can read files in a chat” with “can write arbitrarily to a production directory.”

It is advisable to split permissions into four tiers, starting from the lowest tier by default:

• Read-only preview: list filenames and summaries; do not allow full text to be downloaded outside the workspace.
• Read-only full text: open specified files, but do not write back to the original path.
• Restricted write: only allow new files to be created in an isolated directory or existing copies in that directory to be overwritten.
• Controlled delete: deletion must go through explicit confirmation and apply only to the isolated directory; delete interfaces are disabled for production directories.

For tasks such as updating page numbers, the third tier is usually sufficient: copy the lecture notes to be modified into an isolated directory, let the agent produce a new version only in that directory, and have a human check it before replacing the original. If the system enables the fourth tier by default, it maps misjudgments directly to irreversible operations.

The scope for “discovering related files” also needs to be limited. To verify reference page numbers, an agent may open other documents in the same directory. Use allowlisted paths, exact filename matching, or a task manifest to lock down the target instead of allowing the agent to “follow the trail” across the entire cloud drive. Letting an agent touch the originals you truly care about is often the first mistake; the correct approach is to let it touch only copies you are willing to lose.

Workflow: Copy First, Modify, Then Confirm

A reusable minimal workflow is as follows:

1. Specify the task object. Use an absolute path or a unique file ID, not “that old set of lecture notes” or “the one in the directory with the semester in its name.” Vague instructions expand the retrieval scope.

2. Copy to an isolated workspace. For department materials on a shared drive or object storage, first copy them to a dedicated prefix, such as agent-workspace/task-id/. Keep the original permissions read-only.

3. Modify the copy. Page numbers, tables of contents, and cross-references should all be written back to the copy. If the agent claims it “found another error that needs to be fixed along the way,” it must first list the proposed files to be changed and wait for confirmation.

4. Review differences. Use document comparison or version snapshots to inspect added and deleted lines, focusing on whether entire files have disappeared, syllabi have been replaced, or years have been mixed up.

5. Publish manually. After review passes, a human—or a pipeline with approval—promotes the copy to the official version. The agent does not directly overwrite production paths.

The value of the isolated directory is that even if the agent “cleans up duplicate files,” the damage is limited to discardable copies. In teaching scenarios, yearly lecture notes and the current syllabus can be stored under separate prefixes to avoid mixing “historical archives” and “active materials” in the same workspace.

Delete and Overwrite: Who Approves, Where to Recover

Overwriting and deletion should be treated as high-risk operations. Enforce these rules:

• Any delete request must echo the full path, file size, and modification time, and the user must explicitly reply with agreement.
• Before overwriting, automatically generate a version snapshot. The snapshot retention period should be tied to business importance; for lecture materials, keep multiple historical versions for the long term.
• The agent must not click “restore” or “permanent delete” on its own. Recovery actions also require confirmation to avoid secondary damage in a panic.

Cloud object storage, cloud-drive version history, and local point-in-time backups are three complementary recovery paths. In incident cases, users often rely on the sync drive’s recycle bin to recover materials. This shows that when an agent connects to a file service, version control should be enabled by default rather than assuming an “eventually consistent single copy.” For critical documents, you can also take an immutable snapshot before an editing task begins and decide whether to merge after the task ends.

From a product-design perspective, agent replies such as “you’re right to be angry” cannot replace permission constraints. Emotional reassurance will not bring files back; what actually works is interception before the operation and rollback after it. If even “is deletion allowed” is left to the model to decide, then later people’s emotions and decisions will also be “approved” by the model—this turns the security model upside down.

Task Design: Page Number Updates Should Not Include “Organize the TOC”

Page-number errors are usually local: a reference says page 485 when it should be page 484. The corresponding tool call should be “open the specified file, locate the bookmark or page-number field, and write back to that field.” It should not include:

• Scanning the entire semester directory;
• Deleting top-level files that “look duplicate”;
• Renaming a syllabus with FINAL in its name;
• Repeatedly retrying page restoration while the user is away.

The task can be written as a structured specification: target file list, allowed operation set (only update page-number fields), prohibited operation set (delete, move, rename), and completion criteria (generate a diff report). When coding assistants or office agents connect to object storage or document libraries, a policy engine should block unauthorized APIs rather than relying only on “please be careful” in the prompt.

For team shared drives, also distinguish personal sandboxes from official department libraries. By default, the agent connects only to the sandbox; writes to the official library go through a ticket. In this way, even if one session “eats homework,” it will not eat the entire semester’s teaching schedule.

Capability Mix for Cloud Deployment

In a cloud environment, you do not need to bind to a single document product; generic capabilities can build a guardrail:

• Object storage: isolate workspaces by prefix, enable versioning and lifecycle policies, and allow accidental overwrites to be rolled back to a specific version.
• Access control: the agent uses a least-privilege identity; production buckets are read-only; workspace buckets are writable but not deletable, or deletion requires an additional policy.
• Audit logs: record the object keys and callers for list, read, write, and delete operations so the operation chain can be reconstructed afterward.
• Monitoring and alerts: a large number of deletions in a short period or writes to an abnormal prefix triggers an alert to the document owner.
• Message queue or workflow: make “confirm deletion” a human approval node, with automatic cancellation on timeout.

Baidu AI Cloud’s object storage, log service, monitoring and alerting, and other general categories can be combined in the ways described above: the agent writes only to the workspace, while production data is protected by versioning and alerts. The key is the architecture choice, not handing all files to a chat window at once.

Checklist for Teaching and Knowledge Workers

Before clicking “let the agent edit this lecture,” use the following checklist:

• Does the original have an independent backup, and is the backup outside any path the agent can write to?
• Does the workspace contain only copies for this task?
• Does the instruction specify exact filenames rather than “look at everything related in the directory”?
• Are deletion, renaming, and moving explicitly prohibited?
• While you are away from your seat, will high-risk operations be automatically paused?
• If something goes wrong, can you retrieve a usable version from version history within three minutes?

If any one of these answers is no, write permission should not be granted. Keep the original safe first, then let the agent edit a copy—this is the lowest-cost habit with the most certain benefit.

Agents are suitable for repetitive, local, verifiable document labor, not for having unattended authority over production directories. Narrow the permissions, isolate the copies, make confirmation real, and turn on versioning. Then a page-number update remains a page-number update, instead of becoming “during one lunch break, a year of lecture notes disappeared.” For developers, the same principles apply to configuration files, API documentation, and release notes: the stronger the automation, the more irreversible operations need to be kept behind a gate.