DashboardSign inStart your trial

Security

How Rills protects your workspace: workspace isolation, encrypted credentials, sandboxed code, authenticated email, and immutable decision records.

Rills executes workflows that touch your CRM, your email, and your customers, so the security model is worth two minutes. This page covers how your data is isolated, how credentials are stored, and where the hard boundaries are.

#Workspace isolation

Every piece of data in Rills belongs to exactly one workspace, and every query is scoped to your workspace at the database layer, not just in application code. Row-level policies on every table mean a request from one workspace cannot read another’s rows even if application code had a bug. Your workspace context is derived from your authenticated session, never from anything a client sends.

#Encryption

  • In transit: all traffic to Rills is encrypted with HTTPS/TLS. There is no unencrypted access.
  • At rest: database storage is encrypted, and sensitive values get a second layer: workspace secrets , integration credentials, and OAuth tokens are individually encrypted with AES-256-GCM before they’re stored, with support for key rotation.
  • Write-only secrets: once you save a secret, its value is never shown again: you can rotate or delete it, but neither you nor Rills support can read it back out of the UI. Secrets are never logged.

#Integration credentials

OAuth tokens are stored encrypted, refreshed automatically before they expire, and revocable at any time from the integration page (or from the service’s own authorized-apps page). API-key connections are stored the same encrypted way. When an operation needs scopes you didn’t grant, it fails with a permissions error rather than silently over-reaching; see Integrations .

#Custom code sandbox

Custom JavaScript and Python never run on shared infrastructure with access to anything else. Each execution gets a fresh, isolated Vercel Sandbox that is destroyed afterwards:

  • No host environment access
  • No internal network access
  • Secrets available only via the credentials list you explicitly configured on the node

Details on the Custom Code page.

#Webhook authentication

Inbound webhooks support three modes: none (testing only), API key (stored as a one-way hash, shown once at creation), and HMAC signatures (SHA-256 by default, GitHub-compatible format, secret encrypted at rest). Signature verification means a caller can’t forge or tamper with a payload. Use API key or HMAC for anything public-facing.

#Email authenticity

Both directions of email are authenticated:

  • Outbound: sending from your own domain requires DNS verification with DKIM and SPF records, and a workspace can only send from domains it has verified, so no workspace can spoof another’s domain. See Email .
  • Inbound: the Inbound Email trigger checks author-domain alignment (the domain that actually authenticated the message must match the From domain) and exposes the result as a trust flag your workflow can branch on.

#Roles and permissions

Access inside a workspace is governed by four roles: Owner, Admin, Member, Viewer, each inheriting the permissions beneath it. Viewers can’t approve actions or change anything. The full permission table is in Account & Workspace .

#Decision records

Every approve, reject, and edit is recorded immutably (no update, no delete, enforced at the database layer), so the trail of who approved what can’t be rewritten after the fact. See Decision Records .

#Mobile app

The mobile app encrypts all local storage at rest with AES, approval snapshots and queued offline decisions included. The encryption key is generated per install and held in the operating system’s keystore (iOS Keychain / Android Keystore), so a filesystem or backup copy of the device yields only ciphertext.

#Rate limiting

Public endpoints, webhook URLs, public forms , and authentication routes are rate limited to blunt abuse. Requests over the limit are rejected with a 429 until the window resets.

#Questions

For our public security overview, see the security page . For anything specific (a questionnaire, a disclosure, a concern), email support@rills.ai .

#Related