There are two places where you can select the AI model you want to use: on the main Projects page or within a Project that's already running.
Privacy Mode provides enhanced privacy controls for code generation sessions. This feature is designed for enterprise customers who require strict data privacy controls.
Privacy mode is only accessible through the Builder CLI and the Builder Desktop Application.
In the Builder desktop app, enable Privacy Mode in the Desktop App Settings.
By default, Builder.io provides baseline security protections for all users:
- All data transmission uses HTTPS/TLS encryption.
- Data stored in Google Cloud Storage uses Google's default encryption with AES-256.
- Builder.io infrastructure follows Google Cloud security standards.
- Only authorized Builder.io systems can access stored data.
Your data is never public, but Builder.io controls the encryption keys used to protect stored session data.
When you enable Privacy Mode, you gain:
- Client-controlled encryption keys. You control the encryption keys used to protect your stored session data.
- Zero data retention equivalent. Combined with LLM provider policies, this ensures no long-term retention of unencrypted code.
- Enhanced data control. You decide when and how to decrypt your stored sessions.
Privacy Mode is not fully end-to-end encrypted but minimizes data exposure through client-controlled encryption and selective data redaction.
Builder.io uses Agentic RAG (Retrieval-Augmented Generation with AI agents) to access your code. This approach applies to both Privacy Mode and default mode.
Builder.io does not upload entire codebases. Instead:
- AI agents explore dynamically. Agents use tools like
ls,grep, andglobto explore your codebase. - Only relevant code is retrieved. Files and code snippets are brought into context only when relevant to your current task.
- Code is accessed on-demand. Code is retrieved as needed during the conversation, not bulk uploaded.
- Scope is targeted. Agents focus on specific files, functions, or code patterns related to your request.
This selective approach limits data exposure by ensuring that:
- There are no complete working copies. Builder never receives or stores your entire codebase.
- Builder only has context-driven access. Only code pieces needed for the current task are processed.
- Only individual files are transferred. Individual files or code snippets are sent, not entire codebases.
- AI scope is task-specific. Data access is limited to what's necessary for your immediate request.
Privacy Mode operates on a processing-time access model with encrypted-at-rest storage.
When you submit a request, the following systems temporarily access your unencrypted code:
- The Client sends code and prompts to Builder servers by HTTPS.
- Builder's infrastructure has temporary access to unencrypted code during processing.
- LLM providers such as Anthropic or OpenAI receive and process the unencrypted code.
- Server processes process the LLM response and generate completion data.
If Privacy Mode is enabled, additional steps are taken.
- Your encryption key is loaded into server memory.
- All session data is encrypted using AES-GCM 256-bit encryption.
- Encrypted data is stored in Redis and Firebase/GCS.
- Your encryption key is immediately discarded from server memory.
- Future access requires you to provide the encryption key again.
Temporary access to unencrypted code is necessary for:
- LLM processing. Language models require unencrypted code to generate meaningful responses.
- Tool execution. Code analysis, file operations, and debugging tools need access to raw code.
- Context building. Session continuity requires understanding previous interactions.
Encrypted storage enables continuous conversations across multiple sessions:
- Chat threads can be resumed across sessions.
- Context preservation maintains conversation history and state.
- File tracking remembers which files were modified.
- Tool results are preserved for follow-up interactions.
Without encrypted storage, each interaction would be isolated with no memory of previous work.
When Privacy Mode is enabled, this infrastructure implements a Zero Data Retention (ZDR) equivalent policy which enforces the following:
- Builder does not retain unencrypted code after request completion.
- LLM providers also implement Zero Data Retention policies.
- No persistent storage of unencrypted code anywhere in the processing chain.
- Code is used solely for inference and immediately discarded.
While code is temporarily processed by multiple systems, the combination of Builder's client-controlled encryption and LLM providers' ZDR policies ensures no long-term retention of unencrypted user code.
interface PrivacyMode {
encrypt: boolean;
encryptKey?: string;
redactUserMessages?: boolean;
redactLLMMessages?: boolean;
mcpServers?: boolean;
}- Purpose: enables client-controlled encryption for stored session data
- Effect: all codegen state is encrypted before storage using client-provided key
- Access: only clients with the encryption key can retrieve session data
- Purpose: client-generated encryption key in JWK format
- Storage: client-side only, never persisted on servers
- Lifecycle: transmitted with each request, used for encryption, immediately discarded
- Purpose: removes user input from stored conversation history
- Effect: user messages are replaced with
"_REDACTED_"in session storage - Use Case: prevents storage of sensitive prompts or proprietary instructions
- Purpose: removes LLM responses from stored conversation history
- Effect: file/diff content is replaced with
"_REDACTED_", but structure is preserved - Use Case: prevents storage of generated code while maintaining conversation flow
- Purpose: controls whether MCP (Model Context Protocol) servers are enabled
- Security: MCP servers may have access to unencrypted data during processing
- Default: disabled in privacy mode for maximum data isolation
- Algorithm: AES-GCM (Galois/Counter Mode)
- Key Size: 256 bits
- IV: Unique 128-bit initialization vector per session
- Authentication: built-in integrity protection with GCM mode
- Generation: client-side using Web Crypto API
- Format: JSON Web Key (JWK) standard
- Transmission: sent with each request, never stored server-side
- Lifecycle: exists in server memory only during request processing
When Privacy Mode is enabled, the following data is encrypted before storage:
- Complete session state including file contents and conversation history
- Code diffs and generated file modifications
- Tool execution results and debugging information
- User prompts and custom instructions (unless redacted)
- LLM responses and generated code (unless redacted)
The following metadata stays unencrypted for operational purposes:
- Session identifiers and completion tracking
- Authentication tokens and user credentials
- Usage metrics and performance data
- Error logs and system diagnostics
- Redacted message markers (showing something was redacted, but not the content)
- Duration: 5 minutes after completion
- Purpose: fast access for immediate follow-up requests
- Content: encrypted session data with client-controlled keys
- Duration: persistent until manually deleted
- Purpose: session resumption and thread continuity
- File naming:
{completionId}.json.aesfor encrypted sessions - Associated data: initialization vectors stored separately for security
To access stored session data, clients must:
- Provide the original encryption key with each retrieval request
- Authenticate using standard Builder credentials
- Match the session owner (encrypted data is tied to the creating user/organization)
The server cannot decrypt stored data without the client-provided key, ensuring that Builder.io staff cannot access encrypted session content.
Enable Privacy Mode in your project configuration:
{
"privacyMode": {
"encrypt": true,
"redactUserMessages": true,
"redactLLMMessages": false,
"mcpServers": false
}
}Privacy Mode can be configured through the Builder.io Desktop App interface.
- Desktop App Required: privacy Mode settings are only available in the Builder.io Desktop App, not in the browser version
- Admin Access: you must be an admin on the space to configure privacy settings
- Space Access: privacy settings are configured per Space and affect all projects within that Space
- Open Desktop App Settings and click on the settings or configuration option in the desktop app.
- Go to Privacy and find Desktop App Settings.
The Desktop App provides toggle switches and dropdown menus for the following privacy settings:
Enforce desktop app only
- Forces all users in the space to use the desktop app.
- Prevents access through web browsers.
- Ensures privacy mode compatibility across all users.
Fusion Project execution environment
- Configure where Fusion projects run (Local Containers/Docker recommended for privacy).
- Provides isolation and performance with local control over the environment.
Enable Privacy Mode
- Master toggle to enable or disable privacy mode for the space.
- When enabled, activates client-controlled encryption.
Enable MCP Servers in Privacy Mode
- Controls whether Model Context Protocol servers can be used.
- Disabled by default for maximum data isolation.
- Only enable for trusted external tools.
Message Redaction Options
- Redact user messages: Removes user input from stored conversation history
- Redact LLM messages: Removes AI responses from stored conversation history
Encryption Key Management
- Displays current encryption key status
- Shows whether a key is configured and active
- Provides comprehensive key management options:
- Enable Desktop App Enforcement: Toggle "Enforce Desktop App Only" to ensure all team members use the desktop app
- Configure Execution Environment: Select "Local Containers (Docker)" for the Fusion Project Execution Environment
- Enable Privacy Mode: Toggle "Enable Privacy Mode" to activate encryption
- Configure Redaction: Enable message redaction based on your privacy requirements:
- Manage Encryption Keys: The system automatically generates encryption keys, which are shown in the interface
- Disable MCP Servers: Keep "Enable MCP Servers in Privacy Mode" disabled unless you specifically need external tools
For teams that need to share access to encrypted sessions, use the key management features:
- Export Keys: Use "Export to file" to save encryption keys securely
- Share Securely: Distribute key files through secure channels (encrypted email, secure file sharing)
- Import Keys: Team members can use "Import key from file" to access shared sessions
- Backup Strategy: Always export and securely store encryption keys before making changes
- Admin Only: Only space admins can modify these settings
- Space-wide Effect: Changes apply to all projects and users within the space
- Desktop App Required: These settings are not available in browser-based sessions
- Key Security: Encryption keys are generated automatically and should be kept secure
- ✅ CLI (Local Development): Full privacy mode support
- ✅ Native Desktop App: Full privacy mode support
- ❌ Cloud/Web Interface: Not supported
Privacy Mode is not available in cloud deployments because:
- Key management: Encryption keys must remain client-side to maintain privacy guarantees
- Infrastructure limitations: Cloud services cannot access client-generated keys
- Security architecture: Server-side key storage would compromise the entire privacy model
When Privacy Mode is active:
- No Cloud backup: session data is not backed up to cloud storage systems
- No Fly.io deployment: cloud deployment features are automatically disabled
- Local persistence: data persists only in local storage systems
- Independent sessions: each session uses unique, isolated encryption keys
- Builder.io engineering staff: No access to raw code during normal operations
- Builder.io infrastructure: Temporary access only during request processing
- LLM providers: Access to code content as part of model inference
- MCP servers (if enabled): May access unencrypted data during tool execution
- Builder.io staff: Cannot decrypt stored session data without client keys
- Database administrators: Can see encrypted blobs but not content
- Backup systems: Store encrypted data only
- Client with encryption key: Full access to session data
- Client-controlled encryption: Only you have the keys to decrypt stored sessions
- Processing isolation: Code access is limited to active request processing
- Key isolation: Encryption keys never persist on Builder.io servers
- Session independence: Each session uses unique encryption parameters
- Processing-time exposure: Code is temporarily accessible during LLM processing
- Third-party LLM access: External AI providers process your code content
- MCP server risks: External tools may access unencrypted data if enabled
- Metadata visibility: Session identifiers and usage patterns remain visible
- Duration: Only while the request is being processed (typically seconds to minutes)
- Purpose: LLM inference, tool execution, response generation
- Destruction: Automatically cleared from memory after request completion
- Duration: Until manually deleted or session expires
- Purpose: Session continuity and conversation threading
- Access: Requires client to provide encryption key for each retrieval
- Key Management: Generate unique keys per project or session
- Access Control: Limit who has access to encryption keys
- MCP Servers: Only enable trusted external tools
- Session Hygiene: Regularly clean up old encrypted sessions
- Local Security: Secure the machines where CLI/native apps run
- Encryption: Adds minimal latency to session storage
- Decryption: Required for each session retrieval
- Storage: Encrypted data is approximately 33% larger
- Key Loss: Lost encryption keys make sessions permanently inaccessible
- Backup Strategy: No cloud backup available for encrypted sessions
- Monitoring: Limited visibility into encrypted session content for debugging
- Existing sessions remain unencrypted and accessible
- New sessions automatically use encryption
- No migration required for historical data
- Previously encrypted sessions require keys for access
- New sessions store data unencrypted
- Consider data retention policies for encrypted sessions
- Privacy mode works consistently across CLI and native applications
- Encryption keys are portable between different client environments
- Session data can be accessed from any authorized client with the correct key
Was this article helpful?