Security Model

Automation is unusual among software categories in that it needs the same credentials a person uses. A robot that logs into your ERP holds a password to your ERP. That makes the question "where do the secrets live, and who can read them" the first question worth answering — before features, before pricing.

This page describes the mechanisms. It is written for the security reviewer who has to sign off, so it names algorithms and says plainly where the boundaries are.

The short version

Question	Answer
Does Robomotion ever see my password?	No. Authentication is SRP-4096, a zero-knowledge proof. The server stores a verifier, not the password, and never receives the password itself.
Does Robomotion ever see my credentials?	No. Vault items are encrypted in your browser before upload, under a key derived from your password plus your vault secret key.
So can support recover my vault?	No. Nobody at Robomotion can. This is a deliberate consequence of the above, not an oversight.
Then what happens if I forget my password?	You can reset it and keep using the workspace, but the vault contents are gone — the key that decrypted them was derived from the old password. Keep the password in a password manager, and share any vault that matters with a second person.
Where do my automations actually run?	On your robot — your machine, your VPS, or your own cluster. The cloud service coordinates; it does not execute your flows unless you explicitly use Cloud Run.

Authentication: SRP, not password-over-TLS

Signing in uses SRP (Secure Remote Password) with 4096-bit parameters.

What that buys you over the usual "POST the password over TLS and hash it server-side":

• The password never leaves your device, in any form. Not hashed, not encrypted — not at all.
• The server stores a verifier derived from your password and a per-user salt. A verifier cannot be replayed as a password and cannot be reversed into one.
• A database disclosure therefore does not yield credentials to try elsewhere. That matters because password reuse, not password strength, is how most account compromise happens.

The user record holds salt, iv and verifier for this exchange. There is no password column, because there is no password to put in one.

Single sign-on

When your workspace is configured for Google, GitHub, OIDC or LDAP, the identity provider owns authentication and multi-factor, and SRP is not involved for those users. For password users, TOTP two-factor is available per user.

The vault: encrypted before it leaves you

Credentials for a flow — an ERP password, an API token, an SSH key — belong in a Vault, and nodes reference the vault item rather than holding the secret.

The important property is where the encryption happens. A vault item is encrypted in your browser, with 256-bit AES, before it is uploaded. What reaches the service is ciphertext. The key is derived from two things:

1. Your password — which, per the section above, the server has never seen.
2. Your vault secret key — generated on first vault setup, held by you.

Two things follow, and they are the same fact viewed from either side:

• Nobody at Robomotion can read your credentials. Not an engineer with database access, not support, not someone who exfiltrates a backup. There is no key on the server to compromise.
• Nobody at Robomotion can recover them for you either. If you lose the password or the secret key, the items are gone. Use a password manager, and keep the secret key somewhere you will still have it after a laptop dies.

Each user also holds an asymmetric key pair — public_key plus an enc_private_key that is itself encrypted under the vault key. Sharing a vault with a colleague works by re-wrapping the vault's key to that colleague's public key, which is why sharing does not require anyone to send a secret to anyone.

There is no recovery path, so build one yourself

The design above has a consequence worth planning around: a lost password means the vault contents are unrecoverable, by anyone, permanently.

The mitigation is not cryptographic — it is share the vault. A vault that two people can open never becomes a single point of failure, and sharing costs nothing at creation time. Doing it after the fact is impossible, because the re-wrap needs a vault key nobody has any more.

Robot identity

A robot authenticates in one of two ways, and the difference matters operationally.

User credentials — the robot connects as you. Convenient on your own desktop, and required for the robot to appear in the Flow Designer's Run dialog.

Robot token — generated per robot in Admin Console → Robots. Correct for anything unattended, because it is not tied to a person who might leave the company.

Two hardening measures worth knowing:

• Keep the token out of the process list. A token passed as --token is visible to every user on the machine through ps and /proc/<pid>/cmdline. The robot reads ROBOMOTION_ROBOT_TOKEN, ROBOMOTION_ROBOT_ID and ROBOMOTION_WORKSPACE from the environment when the corresponding flag is absent — see Linux VPS for a systemd unit that does this.
• Lock mode (--lock) refuses to run any flow that is not already cached, so a production robot cannot be pointed at newly-published work without a deliberate step.

Where secrets are not client-side encrypted

Being straight about the exceptions is more useful than a blanket claim.

Some configuration has to be readable by the service itself — an LDAP bind password, for instance, is used by the server to query your directory, so it cannot be encrypted to a key only your browser holds. Those values are encrypted at rest with AES-256-GCM under a deployment key (AUTH_CONFIG_ENC_KEY), which keeps them out of database backups and out of reach of a read-replica query, but is a different and weaker guarantee than the vault's.

GCM specifically, rather than a plain cipher, so a tampered ciphertext fails to authenticate instead of silently decrypting to a different bind password.

Audit

Every consequential action is recorded — robot created, flow published, schedule changed, job stopped, user invited, vault created, sign-in — with the acting user, a timestamp, and before/after state. See Audit, and /v1/audit.logs in the API for export.

What to take to a security review

• Authentication is SRP-4096; the server holds a verifier, never a password.
• Credential encryption is client-side AES-256; the service holds ciphertext only.
• There is no server-side recovery path, because there is no server-side key.
• Execution happens on infrastructure you control, unless Cloud Run is used explicitly.
• Service-side configuration secrets are AES-256-GCM at rest under a deployment key.
• All state-changing actions are audited with actor, timestamp and before/after state.

For where each of these physically lives, see Deployment Topologies.