Outbound Connections and Credentials

Connecting Files.com to another system creates an authorized path for work and, often, for file contents. Files.com checks whether a user or workflow may request an operation; the destination checks the credentials used for that operation. Review both sides so the connected service's access matches the work you intend Files.com to perform.

Remote Storage and Delegated Use

A Remote Server holds a connection configuration for a storage service or server. Mounts, syncs, and automations can use that connection. Their ability to read or write depends both on the applicable Files.com permissions and on the account or credentials configured at the remote destination.

This arrangement lets users work with connected storage without receiving its underlying secret. Not seeing a password does not mean a user has no access to the connected system: permissions can authorize the user or a workflow to use the connection on their behalf. Review which folders expose a mount and which administrators can configure work against the Remote Server.

Use an account on the destination whose permissions fit the integration. Files.com cannot grant permissions the destination account lacks, while an unnecessarily broad destination account gives the connection more authority than its intended work needs. Removing an individual Files.com user's folder access does not disable a shared Remote Server or stop independently configured workflows.

Credential Ownership and Rotation

The Remote Server Credential Manager lets administrators maintain credentials shared by multiple Remote Servers. Updating a shared credential updates the connections that use it, which is useful for coordinated rotation and also means that a mistaken change can interrupt several workflows. Identify those connections before replacing or removing a credential.

OAuth connections authorize each Remote Server separately and are not shared through the Credential Manager. Review the remote service's grants as well as the Files.com configuration when disconnecting an OAuth integration. Expiration or revocation at the remote service can stop access even while the connection remains configured in Files.com.

Assign responsibility for the connection to the team operating the workflow. A saved connection is a continuing configuration, not a login session belonging to the person who last edited it. An account offboarding process should therefore include any shared destination credentials the person controlled and the workflows that still need them.

Webhook Destinations and Content

Webhooks deliver information to configured HTTP endpoints. Review the selected events and payload: a webhook can send file details, and a configured payload can include file contents. Every primary and backup URL receives its configured requests; a backup URL is also a destination that must be approved to receive the data.

Files.com validates every destination when the configuration is saved. URLs must be well formed, use an allowed port, and resolve to public addresses. Destinations that resolve to private, loopback, or link-local addresses, or whose hostname cannot resolve, cannot be saved. The rules apply in every workspace and through the web interface, API, CLI, and SDKs.

This validation does not send a test HTTP request or require a successful receiver response. A delivery test checks a different question: whether the receiver accepts the request. Overriding a failed delivery test does not bypass destination validation. If validation cannot finish, the save fails and the previous configuration remains intact.

Destinations are checked again when sending, so a saved URL is not a promise of future delivery. DNS, receiver availability, credentials, and receiver behavior can change. Use HTTPS for confidential deliveries, maintain any receiver credentials, and monitor the delivery results for the workflow you depend on.

Work Inside Your Environment

The Files.com Agent provides a configured connection to systems inside your environment. It is separate from a public webhook destination. Access to an Agent-backed folder follows the applicable Files.com permissions and the Agent's access to local storage.

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.