When AI can read files: start with a copied folder, not the whole project

An AI agent that can work inside a folder does not merely gain better context. It gains a handle on the organization's raw material: contracts, spreadsheets, code, exports, and documents that somebody actually relies on.

That is useful. It is also why the first pilot should run in a copy, not in the original folder.

The Grok Build incident shows why folder boundaries need testing

On July 13, security researcher Cereblab published a reproducible report about Grok Build. In tests with version 0.2.93, a tracked Git repository, including its history, was packed as a Git bundle and sent through a separate storage request. This happened even when the agent was told not to open any files. A file that the model had not read could still be included in the bundle.

The researcher later observed the same client receiving the server flag disable_codebase_upload: true, after which the reported full-repository upload stopped. The distinction matters: a server-controlled setting stopped the behavior. The report does not show that a verified client update alone resolved it, and it says nothing about every other file-capable agent.

Source: Cereblab's reproducible report and test material

Source: The Verge – reporting and independent security comment

SpaceXAI responded that teams using zero data retention, or ZDR, do not have trace or code data retained and that API-key use of Grok Build respects ZDR. The company also pointed to the /privacy command for disabling retention when ZDR is not in use. Elon Musk subsequently wrote that previously uploaded user data would be deleted. At the research cutoff, no detailed public matrix showed which tenants, accounts and versions were affected, and there was no independent confirmation that deletion had been completed.

Source: SpaceXAI response on ZDR and data retention

Source: Elon Musk's deletion statement

The lesson is not to judge every file tool by one incident. It is that file access, transmission, retention and model training are four different questions. A tool may respect a rule that stops the model from reading a file during its working steps while still having a separate sync or storage function. A retention setting does not automatically tell you what leaves the computer.

What is a file-capable AI agent?

A file-capable AI agent can read, create or change files as part of a multistep job. It might reconcile invoices, inspect a project, organize documents or build a report. Unlike a basic file upload, the agent may also use a command line, applications and network services while it works.

Manus, for example, describes its desktop agent as folder-scoped: the user selects a local directory and approves commands. That is a useful control model, but a vendor description is not a substitute for testing the specific product, version and configuration you plan to use.

Source: Manus Desktop – local file access and approvals

Design the pilot so that failure is cheap

1. Create the test folder outside the original

Copy only the files needed for the task. For code, first ask whether history is necessary at all. A fresh directory without .git reduces the chance that old secrets, deleted files or internal branches come along. If version comparisons are required, create new local history from the sanitized copy.

The same principle applies to document work. Export a small sample instead of connecting an entire SharePoint site, client folder or school server. Use invented names and amounts while the workflow is still under test.

2. Inventory what the agent can actually see

Save a file list before the run, including hidden files. Check metadata, temporary files, archives, shortcuts and links to other directories. For a code project, the review should cover tracked files and history, not only what is visible in the latest working tree.

At the same time, state what is explicitly forbidden: real API keys, pupil records, production databases, client contracts or any other data class the pilot does not need.

3. Start with a read task

The first run should produce a proposal, inventory or report. It should not move originals, overwrite spreadsheets, send email or publish anything. Read access lowers the consequence of a mistake and makes it easier to see which sources the agent uses.

A useful first instruction is concrete: “Read these 20 sanitized invoices, create a CSV in the output folder and flag uncertain values. Do not change any source files.”

4. Add a fake canary file

Create a unique, harmless marker in the test folder, such as PILOT-CANARY-2026-07-A7. Put it in a file the task does not require. Then check whether the marker appears in the agent's response, logs, exports or observed network traffic.

The canary does not prove that everything is safe. It can reveal a mismatch between the declared working area and the actual behavior.

5. Write down the expected data path

Document which domains, applications and storage locations should be used before the run. Compare that list with available logs, proxy data or the vendor's administration view. If the tool does not provide enough visibility, that is a result: the pilot should not move to more sensitive material.

xAI's enterprise documentation separates local tool execution, transport to the inference service, server processing, retention and local session history in ~/.grok/. That separation is a useful set of questions for other vendors too.

Source: xAI Grok Build – enterprise controls and data lifecycle

6. Review the diff, not only the final file

Compare the test folder with the untouched copy. Review created, changed and deleted files, as well as commands and external calls where records are available. A polished final document can hide the fact that the agent read too much, wrote to the wrong location or left temporary copies behind.

Only after a person approves the diff should the same type of action be considered for the next pilot stage. Keep send, delete, publish and permission changes behind a separate approval.

7. Require evidence of cleanup and recovery

Do not end with “it looked fine.” Remove the test copy according to the agreed plan, check local session history and document how vendor retention or deletion works. Rotate a secret immediately if you discover that it was present in the test material or version history.

Keep a recovery point as well. For documents, that may be the untouched export. For code, it may be a separate copy and an approved diff. Rollback is not the same as deletion at the vendor; each needs its own control.

Fill in this folder-pilot card

Copy these fields into a working document and complete them before the first run:

• Task: What should the agent deliver, in what format and to which folder?
• Owner: Who may start, pause and stop the pilot?
• Source: Which originals were copied, and when?
• Allowed content: Which files and data classes may be used?
• Forbidden content: What is not allowed in the test folder?
• Allowed actions: Read, create drafts, write to an output folder, or something else?
• Expected destinations: Which domains and storage locations should appear?
• Canary file: Which fake marker is used, and where will you check for it?
• Acceptance criteria: What must be true before a person accepts the run?
• Stop rule: Which finding pauses the pilot immediately?
• Cleanup evidence: How will local cleanup, retention and any deletion be verified?
• Decision date: When will you stop, adjust or proceed?

Three sensible first tests

Code project: Copy one module to a fresh directory without Git history. Replace configuration with fake values. Ask the agent to propose a change without applying it. Then inspect accessed files, network destinations and the diff.

Finance administration: Put 20 sanitized PDF invoices in a test folder. Have the agent produce a CSV with fixed columns and flag uncertainty. Compare it with a manually checked answer file before trying real documents.

School or office: Use public policy documents and invented meeting notes. Ask for a source-linked summary. Keep pupil data, staff cases and authenticated cloud folders outside the pilot until data flow, logs and approvals have been verified.

This is a practical Tool Forge problem: not “which agent is best?” but “which folder, data and action may the agent use, and what evidence is required before we trust the result?” If the pilot cannot answer those questions, it is not ready for original files.