DashboardSign inStart your trial

Security — Sandboxed Code & Encrypted Credentials

Last updated:

Overview

Rills is built with security as a foundational principle, not an afterthought. From the way we store your data to how we execute custom code, every layer of the platform is designed to protect your information and keep your workflows safe.

This page covers our approach to:

  • The approval layer: how human approval and decision records keep you in control of what your automation does
  • Infrastructure security: how we host and protect the platform
  • Data encryption: how your data and credentials are protected at rest and in transit
  • Authentication: how we verify your identity and secure programmatic access
  • Multi-tenant isolation: how we ensure your data is never accessible to other users
  • Code execution sandbox: how custom code runs in fully isolated environments
  • Input validation and rate limiting: how we protect against common web vulnerabilities and abuse
  • Mobile app security: how the Rills mobile app protects data on your device
  • AI data handling: how your data is treated when processed by AI models
  • Responsible disclosure: how to report security issues

The Approval Layer

The core of Rills is itself a security control: AI and automation propose actions, and humans approve them before they execute.

  • Human approval gates: Workflows can pause at any consequential action and wait for an explicit human decision. Nothing gated behind an approval executes until someone with access to your workspace approves it.
  • Decision records: Every approval and rejection is recorded — who decided, what they decided, and when. Decision records are retained for 365 days on every plan, giving you an audit trail for the actions your automation takes.
  • Earned autonomy: Confidence is scored on every execution, and only runs above your threshold proceed without review. Rills may suggest adjusting a threshold or a workflow, but every change waits for your explicit approval.

Infrastructure Security

Rills runs on modern, enterprise-grade cloud infrastructure with security built into every layer:

  • Automatic HTTPS: All traffic between your browser and our servers is encrypted using HTTPS with TLS. There is no way to access Rills over an unencrypted connection.
  • Edge network: Requests are served from a global edge network, reducing latency and providing built-in DDoS protection.
  • Database security: Our database is hosted on Neon, a serverless PostgreSQL provider, with encryption at rest and automated backups.
  • Dependency management: We regularly apply security updates and patches to all dependencies, and monitor for known vulnerabilities in our supply chain.

Data Encryption

Encryption in Transit

All data transmitted between your browser and our servers is encrypted using HTTPS/TLS. This ensures that your workflow data, credentials, and personal information cannot be intercepted or read by third parties during transmission.

Encryption at Rest

All database storage is encrypted using AES-256 encryption. Your workflow definitions, execution history, and account data are protected even at the storage layer.

Webhook Security

Webhook signatures are verified using HMAC-SHA256 to prevent tampering. This ensures that incoming webhook payloads are authentic and have not been modified in transit.

Secrets Management

API keys, OAuth tokens, and other credentials you store in Rills get an additional layer of protection beyond database encryption:

  • Application-level encryption: Secrets are encrypted with AES-256-GCM before they are written to the database, on top of the database's own encryption at rest.
  • Key rotation: Encryption keys are versioned, and stored secrets can be re-encrypted under new keys without downtime.
  • Runtime-only decryption: Secrets are decrypted only at the moment a workflow execution or integration call needs them. They are never embedded in workflow definitions.
  • Never shown, never logged: Plaintext secret values are never sent to the browser — the interface only ever shows a masked version — and secret values are never written to logs.
  • Access auditing: Access to stored secrets is recorded in a security audit log.

Authentication

Rills supports multiple sign-in methods to balance security with convenience:

  • Email and password: Passwords are stored using secure one-way hashing (bcrypt). We never store your password in plain text, and even our own team cannot retrieve it.
  • Magic link: Passwordless sign-in via a secure, time-limited link sent to your email address.
  • Social login: Sign in with your existing accounts from supported identity providers.

Session Management

Sessions are managed using secure, httpOnly cookies that cannot be accessed by client-side JavaScript. Sessions expire after a period of inactivity, and you can sign out of all active sessions from your account settings.

API Access

Programmatic access to your workspace — including through our MCP server — is secured with the same rigor as the web app:

  • Scoped API keys: API keys carry explicit permission scopes, so a key can only do what you granted it — nothing more.
  • OAuth for sensitive operations: Operations that act with your authority, such as approving or rejecting actions, require an OAuth-authenticated user — an API key alone is not enough.
  • Service identities: Automated access runs under a workspace-scoped service identity rather than a personal account, so machine activity is always attributable and separable from human activity.

Multi-Tenant Isolation

Rills is a multi-tenant platform, which means multiple organizations share the same infrastructure. We take data isolation extremely seriously:

  • Workspace-scoped data: Every piece of data in Rills is scoped to your workspace. Workflows, execution history, integrations, and settings all belong to a specific workspace and cannot be accessed by other workspaces.
  • Row-Level Security (RLS): We enforce Row-Level Security policies directly at the database level. Even if a bug existed in our application code, the database itself would prevent cross-tenant data access. This is a defense-in-depth measure that provides an additional layer of protection beyond application-level checks.
  • Query filtering: All database queries are automatically filtered by workspace to ensure strict data isolation. Workspace context is derived from your authenticated session. It is never accepted from client-side input.
  • Full-stack enforcement: Workspace boundaries are enforced at every layer of the stack: the API layer, the application layer, and the database layer.

Code Execution Sandbox

Rills allows you to write custom JavaScript and Python code as part of your workflows. All custom code runs in fully isolated sandbox environments with strict security controls:

  • Complete isolation: Each code execution runs in a fresh, isolated sandbox environment. Your code cannot access the filesystem, make unrestricted network calls, or interact with other users' data or the underlying infrastructure.
  • Resource limits: Sandboxes enforce strict memory limits, execution time limits, and network restrictions to prevent abuse and ensure fair usage for all users.
  • No persistent state: Each execution starts from a clean state. There is no way for custom code from one execution to affect another, whether within the same workspace or across workspaces.
  • Restricted network access: Outbound network requests from sandboxes are controlled and limited to prevent data exfiltration or abuse.

Input Validation

All user input is validated using strict schemas before it is processed by the platform:

  • Schema-based validation: Every endpoint validates incoming data against a strict schema before any processing occurs. Invalid input is rejected immediately with a clear error message.
  • Server-side enforcement: Validation always runs on the server. Client-side validation exists for a better user experience, but it is never trusted as a security boundary.
  • Protection against common vulnerabilities: Our validation and encoding practices protect against cross-site scripting (XSS), SQL injection, and cross-site request forgery (CSRF).

Rate Limiting

All public API endpoints are protected by rate limiting to prevent abuse and ensure platform stability:

  • Distributed rate limiting: Rate limits are enforced using distributed infrastructure, ensuring consistent protection regardless of which server handles your request.
  • Abuse prevention: Automatic throttling protects the platform and all users from denial-of-service attempts and other forms of abuse.
  • Fair usage: Rate limits are designed to support normal usage patterns while preventing any single user or automated system from degrading the experience for others.

Mobile App Security

The Rills mobile app — where many approvals happen — applies the same security standards as the web platform, plus protections specific to your device:

  • Encrypted local storage: All data the app stores on your device is encrypted at rest using AES encryption. Approval content is never written to disk in plain text.
  • Hardware-backed keys: The encryption key protecting local storage is held in the operating system's secure keystore (iOS Keychain / Android Keystore), not alongside the data it protects.
  • Encrypted transport: All communication between the app and our servers uses HTTPS/TLS, identical to the web platform.

AI Data Handling

Rills uses AI models from third-party providers to power workflow features. You choose which model powers your workflows, and every request is routed through an AI gateway that holds one consistent privacy standard across every provider it can reach:

  • No model training: Every AI request we make carries a no-training routing policy — it can only be served by providers with verified agreements not to use your data for model training. Your data is used solely to fulfill your workflow requests.
  • Encrypted in transit: All data sent to AI providers is encrypted via HTTPS/TLS, ensuring it cannot be intercepted during transmission.
  • Purpose-limited processing: AI providers process your data only to generate the outputs your workflows request. Data is not retained by providers beyond what is necessary to complete the request.
  • Your workflows only: You choose which workflows use AI features and what data they process. Rills also analyzes your workspace's own execution and approval history — including with AI models — to suggest improvements to your own workflows; suggestions take effect only when you accept them, and your data is never used to improve other customers' workflows.

For full details on how we handle your data, see our Privacy Policy.

Responsible Disclosure

We welcome security researchers to report vulnerabilities responsibly. If you discover a security issue in Rills, we want to hear about it.

How to Report

Please email security@rills.ai with details of the vulnerability. Include enough information for us to understand and reproduce the issue.

Our Commitment

  • We will acknowledge your report within 48 hours.
  • We will work with you to understand the issue and develop a fix as quickly as possible.
  • We will not take legal action against researchers who follow responsible disclosure practices.
  • We will credit you in any public disclosure (if you wish) once the issue is resolved.

Guidelines for Researchers

  • Do not access, modify, or delete other users' data.
  • Avoid destructive testing. Do not degrade or disrupt the Service for other users.
  • Provide sufficient detail to reproduce the vulnerability, including steps, tools, and screenshots where applicable.
  • Give us a reasonable amount of time to address the issue before any public disclosure.

Contact

If you have questions about our security practices or need to report a concern, please reach out: