Access Removal & Recovery
Ending one person's Files.com access does not necessarily end a shared Agent deployment. The Agent has its own identity, may serve several workflows, and may run on several hosts. Choose the level of access you need to withdraw before making changes.
Removing a User or Workflow
Remove the applicable Files.com permissions and credentials when a person should no longer use Agent-backed files or configure work. Review Automations, Syncs, mounts, and routed Remote Servers separately; shared work can continue after its original author loses access.
Already issued transfer URLs remain usable until expiration, and accepted operations may continue. Completed local changes and outputs remain in the destination system. File Transfer Authorization explains the difference between preventing new requests and canceling existing access.
An update policy of never only rejects remote software pushes. It does not stop transfers, Compute commands, or routed connections.
Withdrawing Host Access
If all work inside the environment must stop, stop the Agent service on every host serving that Remote Server. Close Direct Transfer listeners and associated forwarding, and withdraw network access as needed for the situation.
Account for high-availability nodes, standby machines, and other installations holding the same configuration. Stopping the currently active host leaves another authorized host able to receive work.
A graceful stop can allow active work to finish. Confirm that the service, remaining transfer listeners, and any local programs are no longer performing work when immediate withdrawal is required. Stopping the Agent does not undo operations a program already completed.
Disable or remove the Remote Server in Files.com to prevent future use and registration. Coordinate changes to its dependent mounts and workflows, and do not assume a cloud configuration change immediately invalidates every signed transfer authorization already issued to a running host.
Replacing a Disclosed Identity
Treat an exposed Agent private key as an identity that needs replacement. Downloading the configuration again returns the existing key, and changing the installer user's password or API key does not rotate it.
First withdraw access from the affected installations and the old Remote Server using the steps above. Create a replacement Agent Remote Server to obtain a new identity, and deploy its configuration only to trusted hosts.
Reconnect the required mounts, workflows, and routed connections to the replacement. Retire every old installation and configuration copy, including backups that could restore the disclosed identity.
If a host or deployment system exposed the key, correct that access before installing the replacement. Otherwise the new configuration can be disclosed through the same route.
Review access to files and internal services available to the old deployment, along with local and Files.com activity records. Replace other credentials when their confidentiality is in doubt; replacing the Agent key does not replace credentials for a separate destination service.
Migration and Retirement
Moving a trusted configuration to a new host preserves the same Agent identity. That can support a planned migration, but it also means the old host remains authorized until its installation and configuration copies are retired.
Include keys in backups, deployment packages, and configuration-management systems in the retirement plan. Removing the service does not automatically remove exchanged files, upload caches, logs, approved scripts, or their outputs.
Before restoring normal use, test the intended file operations and Compute results with appropriately limited users and host permissions. For high availability, verify each host's data access and command definitions. A Connected status establishes connectivity, not that every local permission or program is configured as intended.