Is Retool Safe? Security Review for Internal Tool Builders (2026)

Retool makes building internal dashboards, admin panels, and data tools fast. What it does not make obvious is that when you connect your production database and invite an Editor, that person can open Retool's built-in query editor and run any SQL query against your database directly, not just the queries built into the app they're working on.

That gap catches founders off guard, especially when handing off tool development to a contractor or an outside agency.

What Retool Controls (Platform Security)

Retool Cloud is hosted on AWS and holds SOC 2 Type II certification. Independent auditors verify Retool's security controls annually. All data in transit uses TLS. Credentials for your connected resources (database passwords, API keys) are encrypted at rest using AES-256.

Retool also offers a self-hosted deployment option via Docker or Kubernetes. Self-hosted keeps query data and credentials entirely within your infrastructure, so Retool the company cannot access it. The tradeoff: you own patching, uptime, and the security of the host environment. For teams with strict data residency requirements or regulated industries, self-hosted is worth the operational overhead.

For most indie founders and small teams, Retool Cloud's security controls are adequate.

The Editor Access Problem

The single biggest security gap in Retool is not a vulnerability. It is a feature working as designed.

Every user with an Editor role in your Retool organization can:

1. Open any app in Retool and inspect its queries
2. Open Retool's query editor in the dev toolbar and write new queries from scratch
3. Run those queries directly against any connected resource, including your production database

There is no query-level permission gate below the organization role on Starter, Team, or Business plans. A contractor invited to build a customer support dashboard can open the query editor and run SELECT * FROM users against the same production database, even if that table has nothing to do with the support tool.

How to Limit the Damage

The practical mitigations:

Create a least-privilege database user for Retool. Instead of connecting your production database as the app user (which often has write access across all tables), create a dedicated Retool read-only user with access only to the schemas it needs.

-- PostgreSQL example
CREATE USER retool_ro WITH PASSWORD 'strong-password-here';
GRANT CONNECT ON DATABASE yourdb TO retool_ro;
GRANT USAGE ON SCHEMA public TO retool_ro;
GRANT SELECT ON TABLE customers, orders, support_tickets TO retool_ro;
-- Do NOT grant INSERT, UPDATE, DELETE, or access to financial/PII tables

Separate staging and production resources. Retool supports production and staging environments. Give Editors access to staging resources only; production resources require a separate approval. This way a contractor can build and test against real data shapes without touching production.

Use Viewer roles where possible. Viewers can run queries within apps (they trigger actions you've built) but cannot edit apps or access the query editor. If someone only needs to use your internal tool, not build it, make them a Viewer.

Audit Logs: Enterprise Only

If your production database gets queried for data it shouldn't expose, can you tell who did it and when in Retool?

On Starter, Team, and Business plans: no. Retool's audit log feature, which records which user executed which queries against which resources, is only available on the Enterprise plan.

On lower plans, your only option is enabling query logging at the database level (e.g., PostgreSQL's log_statement = 'all' or pg_audit). If compliance or incident response requires a query audit trail, either plan for Enterprise or implement database-level logging before connecting sensitive data.

Environment Variables and Secret Management

Retool has a built-in secrets store for environment variables accessible in queries and JavaScript. Secrets are scoped per environment (staging/production) and not visible in the app editor's UI once saved. Editors cannot read a saved secret's value through the Retool interface.

One gotcha: if a query directly returns the value of an environment variable (e.g., return retoolContext.environmentVariables.MY_SECRET), a JavaScript query can expose it to anyone running the app. Keep secret values out of query return values.

Retool Cloud vs. Self-Hosted Security Comparison

SSO and Multi-Factor Authentication

SAML-based SSO is available on the Business and Enterprise plans. If your organization already uses Okta, Azure AD, or Google Workspace, SSO is the cleanest way to enforce MFA and centralize access management for Retool.

On Starter and Team plans, users log in with email/password. Retool supports TOTP-based MFA, but it is not enforced by default. Enable org-level MFA enforcement in your Retool settings before connecting sensitive resources.