Data encryption at rest and in transit

Encryption at rest

Credentials and field mappings are encrypted with libsodium authenticated encryption before they reach the database. Each value gets its own random 24-byte nonce, generated fresh at write time and stored alongside the ciphertext. Authenticated means tampering is detected rather than silently decrypted: a modified ciphertext fails to open instead of returning plausible garbage.

Encryption happens at the boundary

Plaintext exists only inside the action that receives it from your browser. From that point on, everything downstream stores and passes ciphertext. There is no internal service, queue message, or log line that carries a credential in the clear.

A separate key for every customer

Each customer environment has its own 256-bit master key, held as a deployment secret in that environment and nowhere else. It is never written to the database it protects, and it is never committed to source control. Two consequences follow: a stolen database is inert without the matching key, and a key lifted from one customer's environment cannot open another customer's data.

Encryption in transit

Every external call runs over TLS, in both directions: your browser to us, and us to the systems you connect. Inside your environment, the database and the job queue have no public internet exposure at all. They are reachable only on the private network, so there is no public endpoint to attack in the first place.

Credentials are decrypted only at the moment of use

A credential is decrypted in memory at the instant a flow needs it, used for that call, and discarded. It is never cached to disk, never returned to the browser, and never displayed again after you save it, including to you. A credential can be rotated or replaced, but it cannot be read back out of the product.

Secrets are stripped from logs

Logging redacts credential field names automatically, at the top level and two levels deep, so a secret nested inside an error object is caught as reliably as one at the surface. The list covers the names actually in use across our connectors, and a test asserts it stays complete:

• Passwords, including the sender and user passwords that EDI and accounting systems use
• Client secrets and shared secrets, in both camelCase and snake_case spellings
• Access tokens, refresh tokens, API keys, and session identifiers
• Authorization headers, cloud access keys, and backup encryption keys

Backups carry the same protection

Our backup engine encrypts every backup before it leaves the database, using the same authenticated encryption that protects your credentials. A backup file is no more readable than the database it came from.

Common questions

What encryption algorithm do you use?

libsodium's secretbox construction: XSalsa20 for the cipher and Poly1305 for authentication. It is authenticated encryption, so an altered ciphertext fails to open rather than decrypting to corrupt data.

Where is the encryption key stored?

As an environment secret inside your own dedicated environment, deliberately separate from the database it protects. It is never stored in that database and never committed to source control.

Can ml-connector staff read my system credentials?

No. Once saved, a credential is never displayed again through any interface, and logs redact credential fields automatically. Credentials can be rotated or replaced, never read back.

What would an attacker get from a stolen database?

Ciphertext. Every credential and field mapping in it is encrypted, and without the master key from that specific environment there is nothing to open it with.

Do you use one encryption key for all customers?

No. Each customer environment has its own key, so the blast radius of a compromised key is a single customer rather than the whole platform.