The Files.com Agent gives Files.com access to storage and approved programs inside your environment. File transfers require authorization from Files.com, while local programs run with the Agent account's operating-system permissions. Administrators approving a deployment need to choose both the file access and the local work they are delegating.

Agent Identity

The Agent's private key authenticates its installation to your Files.com site. Registration and continued registration require that Agent identity; signing in as a user or presenting an API key, from the same site or another site, does not authorize an installation to become the Agent.

By default, the key is stored in the Agent configuration file. It can instead be stored in a separate file referenced by the configuration. Protect both the configuration and the key like a password. Another installation holding the key can identify as the same Agent and receive the operations Files.com routes through it. Sharing the key for an authorized high-availability deployment therefore delegates the same identity to each host.

File Transfer Authorization

Files.com uses JSON Web Tokens (JWTs) to carry authorization in upload and download URLs for files on an On-Premise Agent. The token appears in the URL's jwt query parameter. It lets the Agent verify a transfer that Files.com has already authorized while file data travels through the standard connection route or an optional Direct Transfer.

Files.com checks the user's identity and permissions before issuing the URL. The Agent then checks the token's signature, expiration, and permitted operation and resource type (file or folder), and uses the path authorized by the token. The URL authorizes only that operation and path, without granting general access to the Files.com site.

The JWT is the authorization for that transfer. Anyone who presents the complete URL can use it until it expires, subject to the connection's network restrictions. The Agent does not require the person presenting it to sign in as the user who requested it. Treat the complete URL as sensitive, including when handling logs or sharing transfer diagnostics.

The token's contents, called claims, also identify the site, Remote Server, and transfer. Those identifiers describe the transfer's context; they do not restrict who can present the URL or their network address. Upload tokens also record the requesting client's IP address in the aud claim. For these transfer URLs, that value does not restrict use to that address. Download tokens do not include a client address.

To restrict which network addresses can connect directly to an Agent, use its direct_transfer_allowed_client_ips and direct_transfer_blocked_client_ips settings. Restricting Which Clients Can Connect explains those controls. A valid JWT supplies transfer authorization; it does not override those connection restrictions.

The lifetimes in Transfer URL Expiration apply to Agent transfer URLs. Removing a user's access prevents new URLs from being issued but leaves an already issued URL usable until it expires. Expiration limits when a request can start; a transfer accepted before expiration can continue afterward.

Agent Compute and Host Permissions

Access to an Agent-backed folder follows the applicable Files.com permissions and the Agent's access to local storage. Agent Compute delegates a separate kind of work on that host.

Agent Compute lets workflows invoke commands approved in the Agent's configuration. The host administrator defines the executable and argument templates; the Automation selects a configured name and supplies parameter values. This arrangement delegates local work without giving Automation authors access to the Agent configuration file.

A configured name limits which definition can be selected. The program behind that definition determines what the workflow can do. An interpreter that accepts command text, or a script that turns inputs into instructions, can expose any operation available to the Agent account. Approval therefore covers the executable, scripts it calls, how they interpret inputs, and the operating-system account under which they run. A descriptive name or a string parameter type does not restrict that authority.

Keep executable and script paths fixed, pass inputs as data, and have the program validate which operations and paths those inputs can select. Review values from incoming files and workflow data as well as values entered by administrators. The Agent configuration guidance explains the distinction between script parameters and interpreter command text.

The Agent's file-transfer root and read/write permissions do not confine launched programs. A Workspace controls which Files.com resources an Automation can reference, but does not impose equivalent permissions inside the Agent host. Use operating-system permissions to limit the Agent account's access to local files, credentials, and network resources. Otherwise, a broadly configured command can read, change, or remove unrelated data that account can access.

Protect both the command configuration and the programs it names from changes by people or workflows that should not control the approved operation. Review command and script changes together, and keep definitions consistent across hosts serving the same Agent Remote Server. Standard output and standard error return to Files.com as Automation data, so the program should disclose only the results its workflow needs.

Removing a Files.com credential does not undo work already completed on the destination, and a successful invocation does not establish that the destination retained or used its output as intended. Review the results where the operation runs.