App security
How apps handle security when using AI functionality, including data storage, routing, and LLM training policies.
| The new app building experience Availability | |||
|---|---|---|---|
| Cloud | Closed beta | ||
When working with an LLM, it is important to be aware of how Retool and LLM providers use your data. This page outlines how your data is handled when you use AI functionality in apps.
For more information, refer to the Retool AI Terms.
What Retool sends to LLMs
LLMs are only involved while a builder is editing the app in Retool. Published apps execute functions directly against your resources and never route runtime data through an LLM.
In order to create and edit apps that securely use your real data, the agent securely sends a limited set of information to LLM providers throughout the building session:
- Resource schemas (including full TypeScript definition files), which help LLMs understand the available data, and generate functions.
- The outputs of your functions, which are needed to understand data, format responses, and construct functions. Humans often use the same process, by using read or
GETrequests to understand the structure of their data. - The source files for your app:
- Frontend source files (
.tsx,.css, etc.), which help LLMs understand the current visual state of the app. - Function source files, which are necessary to understand the existing function structures.
- The
package.jsonfile and dependency metadata, which identifies the packages that are installed. - File tree listings and search hits, which help LLMs understand the structure of the app and search through it.
- Frontend source files (
Data storage, routing, and training
The following tables outline key details of Retool’s AI data storage and usage policies and practices based on your hosting option and API key strategy.
- Cloud instances
- Self-hosted instances
| API key | Internal database storage | Observability | API call routing | Training LLM models |
|---|---|---|---|---|
| Retool-managed key | Retool encrypts your chat history at rest in an internal database, which is required for the feature to function. | Retool stores your chat history with a third-party observability provider for QA and debugging. | API calls are routed through Retool’s managed infrastructure. | Retool does not use chat history to train or fine-tune internal models and does not permit external LLM providers to do so. More information. |
| Bring your own key (Enterprise only) | Retool encrypts your chat history at rest in an internal database, which is required for the feature to function. | Retool does not store chat history from Enterprise organizations with an observability provider. | API calls are routed through Retool’s managed infrastructure, but are sent to the LLM provider with your own key. | Usage of your data depends on your negotiated agreement with the LLM provider. |
| API key | Internal database storage | Observability | API call routing | Training LLM models |
|---|---|---|---|---|
| Retool-managed key | Chat history is stored in your platform database, which Retool does not have access to. | Retool does not store chat history with an observability provider. | API calls are routed through a managed egress proxy (OPENAI_PROXY_HOST) and sent to the LLM provider using Retool-managed keys. | Retool does not use chat history to train or fine-tune internal models and does not permit external LLM providers to do so. More information. |
| Bring your own key (Enterprise only) | Chat history is stored in your platform database, which Retool does not have access to. | Retool does not store chat history with an observability provider. | API calls are sent from your instance to the LLM provider and bypass Retool’s managed infrastructure. | Usage of your data depends on your negotiated agreement with the LLM provider. |
Chat history can include:
- User prompts.
- Tool calls and tool results.
- File contents the agent read.
- Generated source code.
- Resource schemas.
- Truncated function run results.
Security while building
Retool provides a number of measures that help you build apps that are secure by default.
Access to resources
LLM access to resources is enforced by the builder's permissions. The LLM cannot read or write any resource data the user is not already authorized to access. When the agent runs functions against resources, the function code executes server-side under the builder's authenticated session, and Retool applies the same permission checks it applies to any other request from that user.
Retool also statically analyzes any code the agent writes or runs, and rejects it if it references a resource the user lacks Edit access to. This enforces an authoring-privilege policy, which prevents a builder from saving or running code against resources that they don't have the proper access to. This check is stricter than the runtime access enforcement.
Human-in-the-loop requests
The agent always requests permission from the builder to run functions that change data in your resources, such as those that write, create, insert, update, or delete data. Read-only functions execute automatically and the result is returned to the LLM. The agent does not permit destructive statements (such as DROP TABLE or DROP DATABASE/SCHEMA).
In addition, installation or removal of third-party packages and creating new resources from the Chat tab always require approval.
Third-party packages
You can add npm packages to support additional functionality in your React apps. Retool imposes certain restrictions on the types of packages that can be installed:
- Packages must be at least 5 days old. Security vulnerabilities are often discovered quickly, so by avoiding installing a brand-new version of a package, you reduce the risk of installing a package before it's been fully vetted.
- Packages must use one of the following open source licenses: MIT, BSD-2-Clause, BSD-3-Clause, ISC, Apache-2.0, 0BSD, Unlicense, and CC0-1.0. While Retool enforces a list of allowable licenses, it is the builder's responsibility to confirm the license requirements for any third-party packages they include in their apps.
The agent always asks for permission before installing a third-party package. When prompted, carefully review the request, and apply any security guidance provided to you by your organization administrators or security team. If you trust the package, approve it, and the agent will configure your app accordingly.
Content security policy
Retool enforces a Content Security Policy (CSP) on all apps, which helps to prevent attackers from exploiting any security vulnerabilities. The following directives are enforced for apps, both in Edit and View modes:
default-src 'self'
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com
font-src 'self' https://fonts.gstatic.com
img-src 'self' data: blob: https:
object-src 'none'
frame-ancestors 'none'
form-action 'self' https://<your-oauth-origin>
base-uri 'self'