Host & File Access
An Agent should expose the storage its workflow needs without giving that workflow control over the machine itself. The file root, permitted operations, and operating-system account provide different parts of that boundary. Review them together before connecting production data.
File Root and Permitted Operations
The Agent's root selects the top-level directory exposed for ordinary file access. Set it to the narrowest directory that contains the intended exchange, rather than a drive or broad parent containing unrelated data.
The permission_set setting limits file operations to read_only, write_only, or read_write. Files.com folder permissions also apply to users accessing the storage through a mount. The host account must have the operating-system permissions needed to perform the requested operation.
These controls have separate effects. A Files.com grant does not create missing host permissions, and a broadly privileged service account does not give every Files.com user access to all mounted files. File Access covers configuration and network shares.
Linked and Hidden Locations
Symbolic links can connect an exchange folder to data outside it. The Agent does not follow them by default. Enabling follow_links permits access to linked locations outside root when the host account can access them.
Review where links lead and who can create or change them. A narrow root is insufficient if a person can add a link to a broader location and the Agent is configured to follow it.
On Windows, show_hidden_files controls whether Hidden files and folders appear in listings. It does not prevent access through a known path. Use permissions to protect confidential files; marking them Hidden is not an access restriction.
Choosing the Host Account
Run the Agent with only the file, share, credential, and network permissions its work needs. Review inherited directory permissions and access through network shares as well as the local root.
Agent Compute programs run with this account's operating-system permissions. The file-transfer root and read/write setting do not confine those programs. Their working directory also does not limit which files they can reach.
A Files.com Workspace controls platform resources, rather than permissions inside the host. If two workloads must have independent local access, separate their Agent identities and operating-system authority.
Keeping the Installation Outside the Exchange
People who can upload exchange files should not be able to change the Agent executable, configuration, private key, or approved programs. Keep those files and their parent directories outside writable exchange locations, and restrict who can replace them on the host.
Protect scripts as carefully as the command definitions that select them. A fixed script path provides little control if another user or workflow can overwrite the script at that path.
The Agent can also create temporary upload data and local logs. Restrict access to their storage and backups, and size the upload cache for the expected workload. Keeping the original files on your premises does not mean that transfers, workflow results, or diagnostics never leave the machine.
Use the installation guide's service verification to check service permissions. Also test the intended file operations under the actual service account and confirm that unrelated locations remain inaccessible. A connected Agent alone does not establish that its local access is appropriate.