Data Security Practices Before an AI Agent Edits Files

Asking an agent only to fix page numbers, then losing a year’s lecture notes and the current syllabus over a meal, is not a rare kind of failure. The task description was narrow, but system permissions widened what the agent could do. The model could read old lecture materials and also reach other documents in the same directory, the same synced drive, or the same session context, then delete or overwrite them while “fixing references.” Public accounts often leave the product, permission switches, and exact deletion path unclear. The conclusion is still clear: design data safety before you give files to an agent that can read and write. Do not try to repair the damage afterward with “I only asked it to change the page numbers.”

What the incident shows

The stated task was to update page-number references in old lecture notes, for example replacing an incorrect page with the correct one. The actual impact fell on two kinds of files: top-level materials from a historical lecture set, and a syllabus still in use. The failure is usually not that the model miscalculated a page. Three things stack together.

First, the scope was never pinned down. The operator meant “this one old lecture file.” The agent saw every related document in the current workspace, a synced drive, a recently opened list, or search results. A year, a course code, or the words “final version” in a filename is not enough to stop a wrong hit.

Second, write and delete permissions were on by default. Changing a few numbers only requires editing a copy and saving it elsewhere. It does not require deleting the original, and it does not require bulk cleanup of files that “look duplicated.” Once deletion is treated as a way to tidy up, accidental deletion is as easy as changing a page number.

Third, there was no human confirmation gate. After the operator left, the agent could keep retrying, overwriting, and cleaning up. A later admission of carelessness, an expression of understanding, or a promise to report before restoring anything does not replace permissions and process set in advance. An emotional reply is not a control.

Comments usually fall into two reactions. One jokes that “the agent ate the homework.” The other says the first mistake is letting the agent touch anything you truly care about. The first shows how the story of responsibility quickly shifts from “the person did not turn in the work” to “the model deleted the files.” The second is closer to an engineering conclusion: the contact surface is the risk surface.

Define the task boundary before you assign work

Instructions to an agent should be a verifiable contract, not a conversational goal. At minimum, write down four things.

• Paths or files it may read, exact filenames rather than “materials for this course.”
• Fields it may change, such as page-number references in the body, explicitly excluding titles, syllabus structure, grading rules, and attachments.
• Forbidden actions: no delete, no move, no rename, no overwrite of the original path, and no changes in other directories.
• A completion standard: a change comparison (old page, new page, location) that a person decides whether to merge.

Files outside that scope stay untouched even if they “look related.” A task on old lecture notes should not automatically receive read and write rights to this term’s syllabus. If search returns both, the correct behavior is to stop and ask, not to process them together.

A sample task description can look like this. The point is the constraint, not the prose:

Goal: Check page-number references only in the specified copy.
Input: /workspace/copies/lecture-2023-class-n.md
Allowed: Change page numbers inside that copy and list the differences.
Forbidden: Delete, overwrite, or move any file; access any path outside copies; modify the syllabus.
Output: A diff list. Do not write back to the official directory.
If other files may have the same issue: report the path only. Do not open them and edit.

Strict instructions still cannot stop a client from mounting an entire synced directory into the session. The boundary has to exist in the permission system as well as in the prompt.

Copies, not originals

Default to a copy. Official lecture notes, syllabi, contracts, grades, and unpublished drafts should sit where the agent cannot write. A workable flow has five steps.

1. Export or copy from controlled storage into a temporary workspace. Include a task ID and date in the filename so you do not overwrite a “final version.”
2. Check the copy in read-only mode. Record file size, modification time, and a content digest so you can compare later.
3. Let the agent edit only that copy. Write the result to a new file, for example one with a .proposed suffix, instead of saving in place.
4. A person samples the diff. Page-number edits should map one by one to locations in the source. Unexplained deletions, large rewrites, or missing files count as failure.
5. After confirmation, a person performs the merge. Do not hand that merge back to the same high-privilege session.

Labels such as “final version” or “FINAL” are not a protection mechanism. A sync client can propagate a local deletion to the cloud and to other devices, so files appear to vanish on their own. For important material, turn off two-way sync for the workspace, or keep the sync scope outside the archive.

Who confirms overwrite and delete

Deletion, overwrite, bulk rename, and emptying a directory are high-risk operations. The model must not complete them on its own. A practical approach is to grade write operations.

• Low risk: creating a proposed draft inside an isolated copy. This can run automatically, but a diff must be kept.
• Medium risk: changing local text in an existing copy. This can run automatically, but whole-file replacement is forbidden. If the number of changed lines or the share of deleted characters looks abnormal, stop and hand it to a person.
• High risk: deleting, overwriting an original, changing permissions, emptying the trash, or cleaning a synced directory. This requires a second confirmation. The confirmation screen must show the path, the operation type, and the number of affected files. It must not only say “Continue.”

Confirmation has to happen before the action, not after a deletion with a promise to “tell you before restoring.” Retrying a restore page and clicking restore repeatedly can itself scramble version order. The right sequence is: stop all writes first, restore from a known-good backup point, then check that the content digest matches the state before the incident.

A model saying “you have a right to be angry” is a conversational tactic. It is not authorization and it is not an audit. An audit should record who performed which operation on which path, and when, and which instruction authorized it. Without logs, you cannot tell a mistaken deletion from a sync conflict or from a person cleaning up on purpose.

How to configure least privilege

What an agent can open, change, or delete depends entirely on the permissions the runtime grants. The rule is deny by default and open access only for the task at hand.

• Separate identities: reading, proposing edits, and performing the merge should not share the same credentials. A read-only identity should not even mount a writable disk.
• Separate directories: teaching archives, the current syllabus, personal drafts, and the agent workspace should be four directory trees that do not inherit one another’s permissions.
• Separate time: revoke write access when the task ends. Do not leave a long-lived session holding a drive token.
• Separate capabilities: if the task is to edit text, do not also grant delete, share, external links, and bulk download.
• Separate network: a session that fixes page numbers does not need access to every cloud file. If a local copy is enough, do not connect the whole library.

When people ask why the agent could reach the syllabus, the answer is almost always the same: the syllabus and the lecture notes sat inside the same authorization boundary, or search, recent files, or a sync client pulled them into context. Putting important files in the default accessible set widens the blast radius. For material you truly care about, the first step is not a smarter model. It is withholding write permission.

Where to recover a mistaken deletion

Recovery cannot be invented during the incident. Before you assign the work, answer: if something is deleted or corrupted, which copy is usable, how fast it can be retrieved, and who performs the restore.

Useful recovery layers include version history or trash on the storage side, scheduled snapshots, off-site append-only backups, and a term archive exported and kept offline. You need to know in advance how long each layer is retained and whether it disappears along with the deletion. Some synced drives send deletions to trash and keep them for a number of days. Some “permanent delete” actions or client cleanups shorten that window. Some keep only the latest version, so an overwrite is a loss. Relying on a single layer is not enough.

At least the following should hold.

• Turn on version history for important documents, with a retention period that covers a full teaching or project cycle, not only a day or two.
• Isolate backup permissions from the workspace. An identity that can edit lecture notes must not be able to delete backups.
• Run a restore drill once a term or once a month: pick a file at random, retrieve it from backup, and check the digest and key passages. Do not stop at a green light that says the backup job succeeded.
• Freeze the scene during an incident: disconnect sync, revoke tokens, and stop the agent from retrying, so new writes do not overwrite a recoverable version.
• Accept the content after retrieval. A file being present does not mean the content is correct. Sample page numbers, chapters, and attachments.

Versioning on object storage, trash on a file service, scheduled snapshots, and log auditing are general capabilities. They do not depend on one vendor’s proprietary wording. If an organization uses storage and backup services on Baidu AI Cloud, it should still write down who can delete, how long versions are kept, and whether a restore drill has been done. Do not assume the console defaults are safe.

A checklist before you assign file work

Use the same checklist every time an agent touches files. Do not grant access by feel.

1. Must this task edit the original? If not, provide only a copy.
2. Is the file list exhaustive? Everything outside the list is invisible.
3. Are delete, move, and overwrite explicitly forbidden?
4. Will write permission be revoked automatically when the task ends?
5. Are changes delivered as a diff for a person to merge?
6. Will an unexpected expansion—too many changed lines, or contact with another directory—stop the job automatically?
7. Are version history and off-site backups still within their retention window, and is the backup identity separate?
8. Can the operation log answer when, which path, and which action?
9. While the operator is away, is the agent forbidden from continuing high-risk retries?
10. Does the person responsible for recovery know to freeze first and then restore, rather than letting the model keep “fixing”?

A teaching workflow is only a small version of the same problem. Code repositories, contracts, experiment data, and customer materials follow the same rule: the more directly an agent can change files, the more confirmation, copies, and backups must be the default path. A model can help check page numbers. It should not be the only holder of the original, and it should not be able to delete that original while nobody is watching.