Run AI Agents Locally Without Exposing Personal Files

Updated 5 November 2026 · Standard formula, shown below

Running an AI agent on your own computer can keep prompts and model processing local, but it does not automatically keep your documents private. This guide shows how to limit an agent to a dedicated workspace, reduce its permissions, and check what it can access before you use it.

What You’ll Need

A computer with an operating system and enough memory and storage for your chosen local model and agent software. Requirements vary by model.
A local model runner and an agent application that can connect to it. Prefer software with clear documentation and settings for tool, folder, and network access.
A separate, empty folder for the agent’s workspace. Do not use your home folder, desktop, documents folder, or a drive containing personal files.
A non-administrator user account if practical, plus time to test access using files that are safe to expose.

Step-by-Step

Choose a local model and inspect the software. Select a model that your computer can run, then obtain it from the project’s official source. Check whether the agent sends prompts, telemetry, logs, or files to online services. A model running locally does not guarantee that the surrounding application or its tools are offline.
Install the model runner and agent separately. Follow their official installation instructions. Avoid running copied commands with administrator privileges unless you understand why they need them. Do not paste private keys, passwords, or personal documents into setup prompts. If the agent supports a local endpoint, configure it to use the local runner rather than a hosted model.
Create a clean workspace. Make a new folder such as agent-sandbox in a location you can easily inspect. Put only test files or specific copies of files you are willing to share with the agent inside it. Do not create shortcuts, symbolic links, or mounted folders that point back to personal directories; these may expose files outside the workspace.
Use a separate, low-privilege account when possible. Create a standard operating-system account for agent work, not an administrator account. Keep personal files in your usual account and do not sign the agent account into services that reveal private data. If a separate account is impractical, use the strongest folder restrictions the operating system and agent provide.
Limit the agent’s file access. In the agent’s settings, grant access only to the sandbox folder. Turn off broad options such as “entire computer,” home-directory access, automatic file discovery, or unrestricted shell access. If access is granted through a file picker, select only the intended folder and verify the displayed path. A prompt telling an agent not to read a file is not a permission control.
Restrict tools and network access. Disable tools the task does not need, especially shell commands, browser access, email, cloud drives, and arbitrary code execution. If network access is unnecessary, block it using the agent’s setting or an operating-system firewall rule. If it is needed, allow only the specific connection where your software supports that level of control. Do not assume that “local model” means network traffic is disabled.
Check credentials and environment access. Do not run the agent in a shell session containing API keys or cloud credentials unless required. Remove unnecessary secrets from environment variables and configuration files accessible to its account. Keep credentials outside the workspace, and never ask the agent to inspect credential stores or browser profiles.
Test the boundary with harmless files. Put a clearly named sample file in the sandbox and ask the agent to read it. Then ask it to find a file in a personal folder, without granting access. It should be unable to read that file; if it can, stop and tighten permissions before using the agent. Do not test with real sensitive documents.
Review actions before approving them. Keep confirmation prompts enabled for file changes, command execution, and network calls. Read the exact paths and commands before approving. Start with a copy of any input and review the output before replacing or deleting files. Close the agent and revoke access when the task is finished.
Recheck after updates or configuration changes. Software updates can change defaults, tools, or permission behavior. After changing the model, agent, plugins, or workspace, repeat the harmless-file test and review network and file-access settings.

Common Mistakes

Assuming local means private. The model may run on the computer while the agent, plugin, telemetry, or update checker still connects to a service. Review each component’s behavior.
Giving access to a parent folder. Selecting your home directory or a whole drive can include downloads, photos, configuration files, and other accounts’ data. Select only the sandbox.
Relying on instructions in the prompt. “Do not open my documents” does not stop a tool from opening them. Use operating-system permissions and application controls.
Ignoring links and mounts. A folder inside the sandbox may lead elsewhere through a shortcut, symbolic link, shared mount, or network drive. Remove those paths unless specifically needed.
Approving commands without inspection. An agent may propose commands that read, overwrite, or transmit files. Do not approve a command you cannot understand; disable shell access if it is not essential.

Tips

Use copies of documents, redact information that is not needed, and keep originals outside the workspace.
Keep the sandbox small and task-specific. Clear it when the work is complete, after saving only the output you want.
Use a virtual machine or a properly configured container for stronger isolation when you understand how its shared folders and network settings work. A container is not automatically a security boundary, particularly when given broad host access.
Keep the operating system and agent software updated, but inspect permission changes after updates.
For especially sensitive files, the safest choice is not to give them to an agent at all.

Troubleshooting

The agent cannot find a test file: Confirm that the file is inside the selected workspace, that the agent has read permission, and that it is using the expected path. Avoid solving this by granting access to your whole home folder.
The agent can see files outside the sandbox: Stop the session and revoke its access. Check for a broad folder grant, a linked or mounted directory, an overly privileged account, or a tool that runs outside the intended restriction. Remove the cause, restart the agent, and repeat the test with harmless files.
The agent contacts the internet: Review its network settings, plugins, and logs; disable unnecessary connections or block them with the operating system’s firewall. If you cannot establish what is being sent, do not provide private files or prompts.
The model is too slow or fails to load: Check the model runner’s documented hardware requirements and available memory and storage. Try a smaller compatible model rather than loosening file permissions or downloading an unknown build.
A command or file change seems unsafe: Decline it, stop the agent, and inspect the proposed command and affected paths. Restore from a backup if needed; do not assume an agent can reliably undo its changes.

Frequently Asked Questions

Does running a model locally guarantee my files stay private?
No. The agent or its tools may still access files or send data over a network. Restrict both file permissions and network access.

Can an agent read files outside its workspace?
It may be able to if it runs with your account’s permissions or has broad tool access. A workspace setting alone may not enforce an operating-system boundary.

Is a separate user account necessary?
It is a useful extra boundary, but not a substitute for checking permissions and tools. Use a standard account with access only to the files the task needs.

Should I disable internet access?
Disable it when the task does not need online features. If it does, limit connections where possible and review what the application sends.

Is a container enough to protect personal files?
Not by itself. Shared folders, host mounts, privileges, and network settings can weaken isolation. Configure them narrowly and test what the agent can reach.

What is the safest way to work with sensitive documents?
Do not provide them unless necessary. If needed, use a redacted copy in a restricted workspace and verify access boundaries before starting.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.