Agent Identity & Private Keys

An Agent can receive work inside your environment without a person signing in on that machine for each operation. Its private key supplies that continuing identity. Anyone responsible for an Agent deployment needs to know where this key exists and who can retrieve or copy it.

What the Key Authorizes

Files.com generates an Ed25519 key pair when you create an Agent Remote Server. The downloaded configuration contains the private key used by the installation to authenticate to your Files.com site.

Registration and continued registration require the Agent identity. A user session or API key, from the same site or another site, does not substitute for it.

The key also participates in signing authorizations accepted by the Agent for file operations and management. Disclosure therefore has consequences beyond another machine appearing under the same name: a holder can identify as the Agent and produce signed operational authorizations, subject to the remaining connection checks.

Software release approval uses separate Files.com signing keys. Possession of an Agent private key does not by itself authorize an arbitrary replacement executable. Software Updates explains that additional check.

Protecting Configuration Copies

By default, the key is stored inline in the Agent configuration file. You can instead keep it in a separate file referenced by private_key_path.

Separating the files can make storage and access management easier, but the configuration still selects the key and the work the Agent permits. Restrict reading of the key to the Agent account and authorized host administrators. Restrict changes to both files and their containing directories.

Keep these files outside folders exposed for exchange through Files.com. An upload permission should not let someone replace the Agent configuration, and a download permission should not reveal the key. Apply the same protection to deployment packages, backups, configuration-management systems, and copies supplied during troubleshooting.

Downloading the configuration again retrieves the existing identity; it does not rotate the key. Replacing a user's password or API key also does not replace the Agent identity.

Administrative Access and Shared Hosts

Permission to download an Agent configuration is more consequential than permission to use a mounted folder. Review who can administer the Remote Server and retrieve its configuration, including Site Administrators and the applicable Workspace Administrators. Remote Connections explains administrative access to shared and user-owned connections.

For high availability, multiple hosts deliberately use the same configuration and key. Each can serve the same Agent Remote Server, so each host must be trusted with the same identity and intended data.

A node name distinguishes installations operationally; it does not create an independent credential. Stopping one node or deleting one configuration copy leaves the other copies usable.

If the key is disclosed, removing the visible copy is insufficient. Replace the affected identity and account for every host and dependent workflow as described in Access Removal & Recovery.