Skip to main content

Security and privacy

The proxy executes commands inside your network on behalf of the automator, so its design centers on three questions: who can send work to the proxy, what that work is allowed to do, and what data leaves your network.

End-to-end encryption​

All command data exchanged between the automator platform and the proxy is encrypted with the key shared by the Proxy account and the profile. Neither the payload nor the result can be read in transit. After decrypting a payload, the proxy verifies the token before executing anything.

The encryption scheme depends on the profile mode.

Script mode​

Script-mode profiles use AES-256-GCM, which:

  • encrypts the payload,
  • produces a 16-byte authentication tag used to detect tampering.

Each profile has a single master key in the configuration file. The proxy derives separate encryption keys from it using HKDF (a standard key derivation function). One key encrypts requests (automator to proxy), another encrypts responses (proxy to automator). This means a request payload cannot be decrypted as a response, and vice versa.

Every encryption uses a random 12-byte initialization vector (IV), so encrypting the same data twice always produces different output.

Exec mode​

Exec profiles use a legacy scheme: AES-256-CBC encryption with a key derived from a shared passphrase. The passphrase can be any string (unlike script mode, which requires a 256-bit random key), and the same passphrase encrypts both requests and responses.

This scheme provides confidentiality but no tamper detection, and its strength depends on the passphrase. Prefer script mode; when exec mode is required, pick a long random passphrase.

Restricting what can be executed​

Use the Script execution mode instead of Command whenever the set of operations is known in advance. It limits what can be executed:

  • Packages cannot send arbitrary commands. Requests that include a raw command field are rejected.
  • Only scripts listed in the profile's commands configuration can run. Unknown script names are rejected.
  • Only parameter names listed in the command's params array are accepted. Extra parameters cause the request to be rejected.
  • All parameter values are shell-escaped before being passed to the script (see Shell escaping).

Shell escaping​

All parameter values passed to shell commands in script mode are escaped using shescape. Shescape quotes and escapes values based on the target shell (powershell, cmd, or unix shells), preventing command injection through parameter values.

Environment variable isolation​

Executed commands receive a minimal environment restricted to the variables listed in the profile's env_vars setting (default: ["PATH"]). This prevents environment variables set on the proxy process, such as database credentials, API keys, or internal infrastructure details, from being exposed to executed commands.

note

On Windows, PowerShell reconstructs certain system variables (SYSTEMROOT, WINDIR, TEMP, USERNAME, etc.) from the registry when it starts, regardless of the environment passed by the parent process. These variables will appear in the child process even though they are not included in env_vars. This is expected PowerShell behavior and does not indicate a leak of application secrets.

Network exposure​

With the default pull transport mode, every connection is opened by the proxy from inside your network: it polls the automator for work and posts the results back over outbound HTTPS. No inbound firewall openings are needed, and internal systems are never exposed to the internet. The poll is authenticated with a short-lived envelope encrypted with the profile key, so no credential travels in the clear, and payloads use the same end-to-end encryption as the push transport mode.

With the push transport mode, the automator connects to the proxy, so your firewall needs an inbound opening for the proxy's HTTPS endpoint. Configure ssl_key_path and ssl_cert_path so this endpoint is served over HTTPS (see Windows service settings).

What data leaves your network​

  • Only the data your packages exchange with the proxy travels between the automator and your network: the command or script name with its parameters going in, and whatever the command prints going out. All of it is encrypted end to end.
  • Credentials for internal systems stay inside your network. Anything your scripts need to reach those systems lives on the proxy machine and is never sent to, or stored on, the automator platform.
  • The proxy logs to a local file on the machine it runs on (the logfile setting); log data is not transmitted to the automator.