Security

Rollout isolates data per workspace, encrypts secrets and Connection credentials at rest, sandboxes workflow code execution, and records sensitive operations in an audit log.

Status: Alpha (features may change).

Authentication

Rollout supports email/password, email magic links, and Google sign-in.

  • Passwords are hashed with Bcrypt and never stored in plain text
  • Magic-link emails expire after 15 minutes
  • Sessions expire after 60 days; remember-me uses a signed cookie
  • Forms are CSRF-protected, and the session is renewed at login to prevent fixation
  • Failed password attempts are rate limited per IP address and per account; successful logins never consume the budget, so users behind a shared network are not locked out
  • Registration and magic-link requests are rate limited too, with the same generic response when throttled
  • Destructive account actions require a recent login and redirect you to re-authenticate when the session is stale

API tokens and devices

The desktop app authorizes through a device flow that issues an API token.

  • Issuing a token requires an explicit confirmation step in the browser
  • Tokens are stored hashed; the original cannot be reconstructed from the database
  • Tokens are valid for one year
  • Review devices, remove them, and control which capabilities they expose to workflows under Settings → Devices

Workspace isolation and sharing

Each workspace is a separate tenant with complete data isolation:

  • Every query is scoped to the workspace at the database level
  • Members hold a role: owner, admin, or member; sensitive settings pages are admin-only
  • Switching workspaces loads an entirely separate dataset
  • Operational resources such as Connections, secrets, and devices are private to their owner until shared with a team or the whole workspace
  • Access checks run inside the database query, so items you cannot access never leave the server

Secret store

Manage workspace secrets under Settings → Secrets.

  • Write-only: a value is set once at creation and can never be viewed again — the list shows names and metadata only
  • Envelope encryption at rest: each secret is encrypted with its own AES-256-GCM data key, and the data key is wrapped by a master key; in the cloud the master key lives in Cloud KMS and never leaves it, while self-hosted deployments supply their own master key through configuration
  • Fail-closed reads: a value that cannot be authenticated and decrypted returns an error, never garbled or partial data
  • A secret can instead reference a 1Password item (op://vault/item/field) when the workspace has a 1Password Connection
  • Secrets follow the private/team/workspace sharing model; workspace admins do not bypass private secrets
  • Every secret action is recorded in the audit log; secret values never appear there

Connections

  • Google Connections use OAuth 2.0 — no passwords are stored
  • Google scopes are granted per Connection: pick only the access a workflow needs (for example Gmail read, Gmail send, Sheets, Drive, or Calendar read)
  • OAuth access tokens refresh automatically
  • Other providers (GitHub, Atlassian, Telegram, SSH hosts, and more) authenticate with API tokens or keys
  • Connection credentials are encrypted at rest with the same envelope scheme as secrets
  • Connections are private to their creator until shared with a team or the workspace
  • Revoke a Connection at any time from Settings → Connections

Webhook security

Incoming webhooks support multiple security options:

  • Unique URLs - Each webhook has a random token in the URL
  • HMAC verification - Validate signatures from services like GitHub or Stripe using an encrypted tenant-secret reference; plaintext HMAC values are rejected
  • Timestamp validation - Reject old requests to prevent replay attacks
  • Token rotation - Regenerate webhook URLs if compromised

Code execution sandboxing

  • The Run JavaScript node runs JavaScript on Deno with default-deny permissions
  • In the cloud, each code step runs in an ephemeral container on gVisor-sandboxed infrastructure
  • Execution & network adds two admin-managed locks: an egress allowlist that restricts runs to listed domains over HTTPS, and a registry allowlist that restricts where workflow images may come from

MCP-authored action review

Workspace policy controls whether MCP-authored configuration requesting per-call never may receive a one-time human review. This applies to native and remote actions. Omitting the approval mode defaults to per-call review.

Actions are stored on their owning App, Agent profile or Workflow node. Save validates the exact configuration and target consent together. A pending replacement remains unavailable until its review succeeds; unrelated actions remain callable. An AI step stores local actions only in replace mode: switching it to inherit or none clears its list, and Save refuses a non-empty list in those modes.

A verified human must answer through a supported Rollout interface. MCP cannot answer that review, including when its credential belongs to the same person. Continuation rechecks the current issuer, original source credential, workspace policy, exact action and target authority. A denied, expired, superseded or revoked request cannot authorize execution.

Direct invoke calls create no saved action. Raw one-off native, remote and App-source recipes, including read-only recipes, wait for one exact human decision combining configuration, target and call review. This grants no reusable target access. An Agent credential is never treated as human approval.

Selecting an exact accepted consumer attachment preserves its configured per-call never or always policy. never can run without a fresh ask; always requires human approval. The actual caller must independently hold configuration access, invoke permission and current target and resource rights.

Selecting a consumer attachment through invoke uses its configuration under the caller's own current rights. It does not transfer the consumer's grants, credentials or installations. Actual App and admitted Workflow execution use server-owned consumer authority.

Explicit grant revocation closes affected undispatched calls and pending reviews. Running calls and immutable completed or unknown outcomes retain their evidence. Unknown external effects require reconciliation rather than automatic redispatch.

Audit log

Workspace admins can review the audit log in Settings.

  • Append-only trail covering secret actions, access changes to devices, Connections, storage volumes, and agent identities, and billing events
  • Records hold the actor, action, outcome, and timestamp; secret values are never written to the log
  • Timestamps display in UTC

Web security

  • Content-Security-Policy with a per-request script nonce — inline scripts without the nonce are blocked
  • HTTPS is enforced in production with Strict-Transport-Security (HSTS)
  • Standard hardening headers: X-Content-Type-Options, X-Frame-Options, Referrer-Policy

Data retention

  • Workflow runs are archived after 30 days and permanently deleted 90 days after archiving (defaults)
  • Archived items stay in each list's Archived view until restored
  • Deleted workflows, projects, tasks, documents, objectives and templates stay in Trash for 30 days and are then permanently deleted (workflows with their runs; a project's tasks are kept, unlinked)

Recommendations

Grant minimal scopes Pick only the scopes a Connection needs; create separate Connections for separate scope sets.

Keep credentials in the secret store Store API keys and tokens as secrets instead of pasting them into workflow configuration.

Rotate credentials periodically Regenerate webhook URLs and reconnect OAuth if you suspect a leak.

Separate test and production Use different workspaces for testing to avoid accidental data exposure.

Review access Periodically check Settings → Connections and Settings → Devices, and remove what you no longer use.

Lock down run egress Turn on the egress allowlist in Execution & network when workflows should only reach known domains.

Troubleshooting

Session expired unexpectedly

  • Sessions expire after 60 days; sign in again
  • Clear browser cookies if the problem persists

Too many login attempts

  • Failed password attempts are rate limited per IP and per account
  • Wait about 15 minutes for the window to reset, or sign in with a magic link

OAuth connection failing

  • Try disconnecting and reconnecting the service
  • Verify you granted all requested permissions

Webhook not validating

  • Double-check the HMAC secret matches on both ends
  • Verify the signature header name is correct
  • Check timestamp tolerance if using replay protection