diff --git a/src/content/docs/agents/getting-started/faqs.mdx b/src/content/docs/agents/getting-started/faqs.mdx index 63d1c1d31..2804b5d0b 100644 --- a/src/content/docs/agents/getting-started/faqs.mdx +++ b/src/content/docs/agents/getting-started/faqs.mdx @@ -21,7 +21,9 @@ Agent Mode has replaced the previous AI chat panel. Agent Mode is more powerful ### Is my data used for model training? -Warp reserves the right to use data collected to train models and improve Warp. Warp has Zero Data Retention with all its model providers (e.g. Anthropic, OpenAI, xAI, etc.). Learn more about telemetry on our [Privacy page](/support-and-community/privacy-and-security/privacy/). +Warp may use collected data to train and improve models that support its AI features, as described in the [Privacy Notice](https://www.warp.dev/legal/privacy-policy). Turning off the **Help improve Warp** toggle stops analytics and eligible content collection for service improvement, subject to organization-enforced settings. + +When a request falls under Warp's [provider ZDR agreements](/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr), the AI provider cannot use its prompts or responses for training. Some models require provider retention and are excluded from ZDR. See the [model exceptions](/agents/inference/model-choice/#models-requiring-provider-retention) and the [separate controls for Warp's analytics and storage](/support-and-community/privacy-and-security/privacy/#provider-retention-analytics-and-storage). ### What model are you using for Agent Mode? diff --git a/src/content/docs/agents/index.mdx b/src/content/docs/agents/index.mdx index 3949b97b9..dc9a4cb96 100644 --- a/src/content/docs/agents/index.mdx +++ b/src/content/docs/agents/index.mdx @@ -70,7 +70,7 @@ To automate more of your team’s software development, use Warp Factories, the ## Privacy and security -Warp is **SOC 2 compliant** and has **Zero Data Retention** policies with all contracted LLM providers. No customer AI data is retained, stored, or used for training. +Warp is **SOC 2 compliant**. Provider ZDR governs what AI providers retain. Warp's [analytics and conversation-storage settings](/support-and-community/privacy-and-security/privacy/#provider-retention-analytics-and-storage) are separate controls. Review the [provider ZDR policy](/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr) and [models that require retention](/agents/inference/model-choice/#models-requiring-provider-retention) before choosing a model. For factory runs, start with [factory ZDR guidance](/factories/zero-data-retention/). You can disable Warp's AI features entirely in **Settings** > **Agents** > **Warp Agent**. diff --git a/src/content/docs/agents/inference/bring-your-own-api-key.mdx b/src/content/docs/agents/inference/bring-your-own-api-key.mdx index d49011bf5..eee898098 100644 --- a/src/content/docs/agents/inference/bring-your-own-api-key.mdx +++ b/src/content/docs/agents/inference/bring-your-own-api-key.mdx @@ -105,15 +105,11 @@ You can update or replace your keys anytime by opening **Settings** and searchin ### Zero Data Retention (ZDR) and BYOK -Warp is **SOC 2 compliant** and has **Zero Data Retention (ZDR)** policies with all of its contracted LLM providers. No customer AI data is retained, stored, or used for training by the model providers. +Warp has a [SOC 2 Type 2 attestation](https://www.warp.dev/legal/security). Its [provider ZDR policy](/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr) applies to supported models accessed through Warp's provider accounts, but not to requests made through your own key. -BYOK prompts and responses transit Warp's backend (see [How BYOK works](#how-byok-works)). Warp does not use this content for training; retention and analytics handling follow the same account-level privacy and telemetry settings that apply to Warp-billed traffic. +Provider-side retention for BYOK depends on your provider account settings. Verify ZDR with your provider for the specific account, model, and configuration. Warp cannot enforce provider ZDR for BYOK. -However, when you use your own API key: - -* Data retention policies on the **provider side** depend on your provider’s account settings. -* Warp cannot enforce ZDR for requests sent through your API keys. -* If your Anthropic, OpenAI, or Google account does not have ZDR enabled, your requests may be retained by the provider according to their terms. +BYOK prompts and responses [pass through Warp's backend](#how-byok-works). Warp applies your account's privacy settings to this content, including any settings enforced by your organization. **Help improve Warp** controls collection for analytics and improvement. **Store AI conversations in the cloud** controls [cloud storage of your personal Terminal conversations](/agents/local-agents/cloud-conversations/). Neither setting changes your provider's retention rules. See the [analytics and storage controls](/support-and-community/privacy-and-security/privacy/#provider-retention-analytics-and-storage) for details. ### BYOK on Business and Enterprise plans diff --git a/src/content/docs/agents/inference/custom-inference-endpoint.mdx b/src/content/docs/agents/inference/custom-inference-endpoint.mdx index 768d9e2c2..acff4b8ae 100644 --- a/src/content/docs/agents/inference/custom-inference-endpoint.mdx +++ b/src/content/docs/agents/inference/custom-inference-endpoint.mdx @@ -83,17 +83,9 @@ Other features use their own inference configuration and are unaffected by a per ## Zero Data Retention (ZDR) -Warp is **SOC 2 compliant** and has **Zero Data Retention (ZDR)** agreements with all of its contracted LLM providers. +Warp cannot enforce provider ZDR for your endpoint. You'll need to verify retention with the endpoint provider and any upstream model providers for your specific account, model, and configuration. Those providers' terms apply to these requests. -Custom inference endpoint prompts and responses transit Warp's backend (see [How it works](#how-it-works)). Warp does not use this content for training; retention and analytics handling follow the same account-level privacy and telemetry settings that apply to Warp-billed traffic. - -When you use a custom inference endpoint: - -* Data retention on the **provider side** is determined by your endpoint provider and any upstream model providers they route to. -* Warp **cannot enforce ZDR** for requests sent through a custom inference endpoint. -* If your endpoint provider does not have ZDR with the underlying model provider, your requests may be retained according to their terms. - -Review your endpoint provider's data handling and retention policies before routing sensitive prompts through a custom inference endpoint. +Prompts and responses still [transit Warp's backend](#how-it-works). Review [Warp's separate analytics and storage controls](/support-and-community/privacy-and-security/privacy/#provider-retention-analytics-and-storage). These controls don't change your provider's terms. ## Centrally managed configuration diff --git a/src/content/docs/agents/inference/model-choice.mdx b/src/content/docs/agents/inference/model-choice.mdx index e5261cd93..0eb7ef1c4 100644 --- a/src/content/docs/agents/inference/model-choice.mdx +++ b/src/content/docs/agents/inference/model-choice.mdx @@ -73,7 +73,7 @@ Suffixes select effort level. `xhigh-fast` enables fast mode, and `thinking` ena Claude Haiku 5.5 has no fixed default `model_id`; choose one of its effort-specific IDs. :::caution -Anthropic requires data retention for Claude Fable 5, Claude Fable 5.1, and Claude Fable 5.2 for safety, abuse monitoring, and compliance reasons, so these models are **not available under Zero Data Retention (ZDR)**. This requirement is specific to the Claude Fable models and doesn't change the ZDR behavior of any other supported model. For Enterprise teams, these models are off by default and a workspace admin must enable them — see the [Admin Panel](/enterprise/team-management/admin-panel/#models-settings) and the [Security overview](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr). +Some Anthropic models require data retention regardless of your **Help improve Warp** setting. Check [models requiring provider retention](#models-requiring-provider-retention) before selecting a model. ::: #### Google @@ -155,23 +155,31 @@ You can configure the base model for each [Agent Profile](/agents/capabilities/a Edit your default profile or any other profile directly in **Settings** > **Agents** > **Profiles**. +### Reviewing inference and privacy in Terminal + +Before sending sensitive content through Warp Terminal: + +1. In the Warp app's prompt input, click the model name and choose a model outside the [exception list](#models-requiring-provider-retention). +2. In **Settings** > **Agents** > **Profiles**, review the active profile's base model. For a [custom router](/agents/inference/custom-routers/), review every target and its default. +3. In **Settings** > **Agents** > **Warp Agent**, review personal keys, endpoints, and subscriptions, plus any [team configuration](/enterprise/enterprise-features/team-managed-keys-and-endpoints/). Search Settings for `API keys` to find personal keys. For customer-managed inference, verify provider ZDR; review [BYOK fallback](/agents/inference/bring-your-own-api-key/#failover-and-fallback-behavior) if enabled. +4. In **Settings** > **Privacy**, review **Help improve Warp**, **Send crash reports**, and **Store AI conversations in the cloud** separately. See [analytics and storage controls](/support-and-community/privacy-and-security/privacy/#provider-retention-analytics-and-storage). + +Confirm the model displayed before your next prompt. For factories, use [factory ZDR guidance](/factories/zero-data-retention/) instead. + ### Zero data retention policies -Warp integrates with multiple large language model (LLM) providers to power its AI-driven features. +Warp has provider Zero Data Retention (ZDR) agreements for supported Warp-managed models on all plans. See [Privacy and data control](/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr) for the policy. -**These providers include, but are not limited to:** +Current Auto selections and fallback chains for other models don't introduce the exceptions below. For separate model settings and coverage limits in factories, use [factory ZDR guidance](/factories/zero-data-retention/). -* OpenAI -* Anthropic -* Google -* xAI -* Fireworks AI +#### Models requiring provider retention -Warp has executed **Zero Data Retention (ZDR)** agreements with these providers. This means that, by default across all plans: +Anthropic requires data retention for safety, abuse monitoring, and compliance. This requirement applies to the following models at every effort level: -* LLM providers commit not to train their models on any customer-generated data processed through Warp’s services. -* LLM providers commit to delete inputs and outputs after generating the relevant output, within a fixed time period. +* Claude Fable 5 +* Claude Fable 5.1 +* Claude Fable 5.2 -Warp enforces these commitments through both technical measures and contractual safeguards with the LLM providers. +These models aren't covered by provider ZDR even when **Help improve Warp** is off. For Enterprise teams, they are disabled by default and a workspace admin must enable them in the [Admin Panel](/enterprise/team-management/admin-panel/#models-settings). -Zero data retention is available for supported models. Model availability may vary where providers require data retention for safety, abuse monitoring, or compliance reasons. +If you use your own provider account, [verify retention with your provider](/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr). Choosing a model outside this list doesn't mean your account has ZDR. diff --git a/src/content/docs/agents/local-agents/cloud-conversations.mdx b/src/content/docs/agents/local-agents/cloud-conversations.mdx index c6443e6ac..36189c4a4 100644 --- a/src/content/docs/agents/local-agents/cloud-conversations.mdx +++ b/src/content/docs/agents/local-agents/cloud-conversations.mdx @@ -20,15 +20,15 @@ Warp can sync your [agent conversations](/agents/local-agents/interacting-with-a ## Enabling cloud conversations -Cloud conversation sync is controlled by a setting in Warp: +To control whether your personal Warp Terminal conversations sync to the cloud: -1. Open **Settings** > **Privacy** -2. Enable **Store AI conversations in the cloud** +1. In the Warp app, open **Settings** > **Privacy**. +2. Toggle **Store AI conversations in the cloud** on or off. -When enabled, your Agent conversations automatically sync to the cloud as you interact with the Agent. When disabled, conversations are stored locally on your machine only. +When **Store AI conversations in the cloud** is on, your personal Terminal conversations sync as you interact with the agent. When it's off, those conversations are stored only on your device. The **Help improve Warp** toggle controls collection for analytics and improvement, not conversation sync. See [analytics and storage controls](/support-and-community/privacy-and-security/privacy/#provider-retention-analytics-and-storage). :::caution -If cloud conversations are disabled, conversation data is lost when you log out and cannot be shared with others. Cloud agent conversations are always stored in the cloud regardless of this setting. +If personal cloud conversation sync is disabled, local conversation data is lost when you log out and cannot be shared with others. Factory and other cloud agent runs still store their transcripts, attachments, and artifacts independently of this setting. ::: ## How it works @@ -93,7 +93,7 @@ Cloud-synced conversations store snapshots of conversation data. For real-time c ## Cloud agent conversations -[Cloud agents](/platform/) run in the cloud, and their conversations are automatically stored regardless of your local cloud conversations setting. +Conversations from [cloud agents](/platform/), including factory agents, are stored even if you turn off personal conversation sync or analytics. By default, run data is stored by Warp. Enterprise admins can instead configure [self-hosted agent data storage](/factories/self-hosting/data-storage/). Provider ZDR does not prevent storage of these conversations. ### Accessing cloud agent conversations @@ -110,13 +110,12 @@ This is useful when a cloud agent completes a task and you want to review what i ### Enterprise controls -Enterprise administrators can disable cloud conversation storage for their organization through the [Admin Panel](/knowledge-and-collaboration/admin-panel/). +Enterprise administrators can disable cloud sync for personal Warp Terminal conversations through the [Admin Panel](/enterprise/team-management/admin-panel/#privacy-settings). -When cloud conversation storage is disabled by your organization: +When your organization disables this setting: -* Conversations are stored locally only and not synced to the cloud -* You cannot share conversations or access them across devices -* Cloud agent conversations are still accessible through the Warp dashboard +* Your personal Terminal conversations remain on your device and cannot be shared or accessed across devices. +* Cloud agent conversations remain accessible through the Warp dashboard. ### Storage limits diff --git a/src/content/docs/enterprise/enterprise-features/architecture-and-deployment.mdx b/src/content/docs/enterprise/enterprise-features/architecture-and-deployment.mdx index 9fb4e1224..310b63e1b 100644 --- a/src/content/docs/enterprise/enterprise-features/architecture-and-deployment.mdx +++ b/src/content/docs/enterprise/enterprise-features/architecture-and-deployment.mdx @@ -27,7 +27,7 @@ The [stack overview](/platform/architecture/#stack-overview) reference describes * **Warp terminal (client)** ↔ **Warp backend (control plane)** ↔ **LLM providers** * The Warp backend handles task orchestration, observability, and LLM inference routing. -* LLM providers operate under **Zero Data Retention (ZDR)** agreements. They do not store or train on your data. +* What your AI provider retains depends on the [model and provider account you use](/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr), not where the agent runs. * The **execution plane** is where source code is accessed, commands run, and build artifacts are produced. This can run on Warp's infrastructure or yours. ## Warp-hosted (SaaS) @@ -53,11 +53,11 @@ Warp-hosted agents can be triggered by: * You want the simplest path to scalable cloud agent execution. * You need to run many tasks in parallel without building sandboxing infrastructure. -* Your security requirements are met by Warp's SOC 2 Type II certified infrastructure with ZDR. +* Your security requirements permit Warp-hosted compute after a separate review of [inference and storage](/factories/zero-data-retention/). ## Self-hosted execution -For organizations that need agent execution and source code to remain within their own network boundary, Warp supports self-hosted execution. +For organizations that need repository checkouts and command execution on their own infrastructure, Warp supports self-hosted execution. Prompts and run records can still include code from your repository and pass through Warp's servers. :::note Self-hosted execution is available exclusively on Warp's **Enterprise** plan. @@ -67,8 +67,8 @@ Self-hosted execution is available exclusively on Warp's **Enterprise** plan. Self-hosted deployments use a split architecture: -* **Execution plane (customer-hosted)** - Source code repositories, build artifacts, shell commands, and runtime secrets stay on your infrastructure. Note that during agent interactions, code context is included in LLM prompts and session transcripts that route through Warp's servers under ZDR agreements (see [What transits Warp's servers](#what-transits-warps-servers)). -* **Control plane (Warp-hosted)** - Task orchestration, observability data, and LLM inference route through Warp's servers under Zero Data Retention (ZDR) agreements. +* **Execution plane (customer-hosted)** - Repository checkouts, commands, and workspaces stay on your infrastructure. Code context, tool output, and uploaded files can still become prompts or stored run data (see [What transits Warp's servers](#what-transits-warps-servers)). +* **Control plane (Warp-hosted)** - Warp coordinates runs and sends the Warp Agent's model requests to the configured provider. See [What transits Warp's servers](#what-transits-warps-servers) for the data it receives. ### Deployment modes @@ -96,8 +96,7 @@ Self-hosted agents require **outbound-only** network access. No inbound network ### When to use * Compliance or security requirements prevent using Warp-hosted compute. -* Source code and execution must stay within your network boundary. -* You want {VARS.WARP_AUTOMATION_PLATFORM} orchestration and visibility without sending code to Warp's infrastructure. +* You need to keep repository checkouts on your infrastructure while allowing prompts and run records that include code to pass through Warp's servers. ## Hybrid deployments @@ -121,18 +120,19 @@ Understanding what data stays where is critical for security and compliance deci ### What stays on customer infrastructure (self-hosted) -* **Source code** - Repository contents and version history -* **Build artifacts** - Compiled outputs and generated files -* **Shell commands** - Terminal commands and their output +* **Source code** - Repository checkouts and version history remain on your infrastructure. Code excerpts can still appear in prompts and transcripts. +* **Build artifacts** - Compiled outputs and generated files unless uploaded as run artifacts +* **Shell commands** - Commands run on your infrastructure. Their output can appear in stored transcripts. * **Runtime secrets** - Environment variables and credentials -* **Execution logs** - Agent run logs and diagnostics +* **Execution logs** - Runtime logs remain on your infrastructure unless uploaded as diagnostics or included in run records. ### What transits Warp's servers * **Task orchestration** - Scheduling, routing, and lifecycle management * **Observability data** - Run status, duration, and metadata -* **LLM inference** - Prompts and responses (which include code context from agent interactions) routed through Warp to contracted LLM providers under ZDR agreements -* **Session sharing data** - Session transcripts, which include code context from agent interactions, when session sharing is enabled for monitoring and collaboration +* **LLM inference** - The Warp Agent routes prompts and responses through Warp to the configured provider. Claude Code and Codex call their providers directly. +* **Run data** - Transcripts, prompt attachments, and uploaded artifacts remain stored after the execution workspace is removed. Enterprise admins can configure where this data is stored through [self-hosted agent data storage](/factories/self-hosting/data-storage/). +* **Session sharing data** - Live session sharing has its own [retention and access rules](/agents/local-agents/session-sharing/#data-retention-and-access) ## Choosing a deployment model @@ -142,11 +142,11 @@ Consider the following when selecting a deployment model: **Warp-hosted** is right if: * You want zero infrastructure management for agent execution. -* Your security team is comfortable with SOC 2 Type II certified, ZDR-covered infrastructure. +* Your security requirements permit Warp-hosted compute. * You need maximum parallelization and scalability. **Self-hosted** is right if: -* Compliance requirements mandate that code stays within your network. +* Compliance requirements mandate repository checkouts and command execution on your infrastructure while allowing prompts and stored run records to include code. * You need to integrate with existing CI/CD or infrastructure tooling. * You want full control over the execution environment. @@ -154,7 +154,7 @@ Consider the following when selecting a deployment model: * Different teams or repositories have different security requirements. * You want the convenience of Warp-hosted for most work but need self-hosted for sensitive workloads. -## Related resources +## Related pages * [Architecture reference](/platform/architecture/) - Diagrams of the stack, the run lifecycle, self-hosted execution, and data boundaries * [Deployment Patterns](/factories/deployment-patterns/) - Detailed patterns for CLI-only, {VARS.WARP_AUTOMATION_PLATFORM}-hosted, and self-hosted setups diff --git a/src/content/docs/enterprise/enterprise-features/team-managed-keys-and-endpoints.mdx b/src/content/docs/enterprise/enterprise-features/team-managed-keys-and-endpoints.mdx index b2eb89570..1f65dd195 100644 --- a/src/content/docs/enterprise/enterprise-features/team-managed-keys-and-endpoints.mdx +++ b/src/content/docs/enterprise/enterprise-features/team-managed-keys-and-endpoints.mdx @@ -108,11 +108,9 @@ Warp uses the stored credentials to call your provider without delivering them t ### Zero Data Retention (ZDR) -Warp is **SOC 2 compliant** and has **Zero Data Retention (ZDR)** agreements with its contracted LLM providers. When you route through your own keys or endpoints: +Requests sent through your team's keys or endpoints are subject to your providers' terms, not Warp's ZDR agreements. You'll need to verify retention with your provider for your specific account, model, and configuration. If your endpoint uses other model providers, verify their retention policies too. Warp cannot enforce provider ZDR for these requests. -* Data retention on the **provider side** is determined by your provider's account settings. -* Warp **cannot enforce ZDR** for requests sent through your keys or endpoints. -* If your provider account doesn't have ZDR enabled, your requests may be retained according to their terms. +Turning off collection of user-generated content does not stop cloud agent transcripts, attachments, and artifacts from being stored. Review [Warp's analytics and storage controls](/support-and-community/privacy-and-security/privacy/#provider-retention-analytics-and-storage). For factory runs, follow [factory ZDR guidance](/factories/zero-data-retention/). diff --git a/src/content/docs/enterprise/index.mdx b/src/content/docs/enterprise/index.mdx index 8522a77f4..6c87e65d5 100644 --- a/src/content/docs/enterprise/index.mdx +++ b/src/content/docs/enterprise/index.mdx @@ -32,7 +32,7 @@ Warp Enterprise serves three primary audiences: ### Security and compliance * **SOC 2 Type II certified** - Meets enterprise security and compliance requirements -* **Zero Data Retention (ZDR)** - No customer data is retained, stored, or used for training by contracted LLM providers +* **Provider Zero Data Retention (ZDR)** - See the [provider policy and storage boundaries](/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr) and [model-specific exceptions](/agents/inference/model-choice/#models-requiring-provider-retention) * **Open source client** - Warp's client code is published under [AGPL v3](https://github.com/warpdotdev/warp/blob/master/LICENSE-AGPL) at [`warpdotdev/warp`](https://github.com/warpdotdev/warp) for security review and audit * **Bring Your Own LLM (BYOLLM)** - Route inference through your own cloud infrastructure (AWS Bedrock or Google Cloud via Gemini Enterprise) * **Team-managed API keys and endpoints** - Share provider API keys and custom endpoints across your Business or Enterprise team for both interactive sessions and cloud agents diff --git a/src/content/docs/enterprise/security-and-compliance/security-overview.mdx b/src/content/docs/enterprise/security-and-compliance/security-overview.mdx index e0518bb26..2e02e7104 100644 --- a/src/content/docs/enterprise/security-and-compliance/security-overview.mdx +++ b/src/content/docs/enterprise/security-and-compliance/security-overview.mdx @@ -1,13 +1,12 @@ --- title: Security overview description: >- - Understand Warp's security architecture, data handling practices, and - compliance certifications to ensure your organization's requirements are - met. + Review Warp's enterprise security architecture, organization controls, + and deployment boundaries. --- import { VARS } from '@data/vars'; -Warp builds security and compliance into its core, keeping **developers in control** while enabling powerful agent workflows. This overview explains how Warp handles your data, what security controls are available, and how Warp meets enterprise security standards. +Evaluate Warp's security architecture, organization controls, and deployment boundaries for your team. For the Warp-wide policy on provider retention, analytics, and product storage, see [Privacy and data control](/support-and-community/privacy-and-security/privacy/#provider-retention-analytics-and-storage). ## Transparency and control @@ -19,51 +18,25 @@ Warp's security philosophy centers on **transparency and developer control**: * **Team-level enforcement** - Admins can configure telemetry and data collection policies for the entire organization * **Open source client** - Warp's client code is published under [AGPL v3](https://github.com/warpdotdev/warp/blob/master/LICENSE-AGPL) at [`warpdotdev/warp`](https://github.com/warpdotdev/warp), so security teams can audit the codebase directly. See [Contributing to Warp](/support-and-community/community/contributing/) for the source repository and the security reporting process. -## What telemetry does Warp collect and why? + -### Zero Data Retention (ZDR) - -Warp has **Zero Data Retention (ZDR)** agreements with its contracted LLM providers (Anthropic, OpenAI, Google, xAI), meaning they do not store or train on your data. ZDR applies across all Warp plans. - -How data collection works by plan: - -* **Free tier** - Individual users can disable data collection in **Settings** > **Privacy**. -* **Paid teams** - Team admins can enforce data collection settings for the entire team. Data collection is enabled by default. -* **Business and Enterprise** - Team admins can enforce data collection settings for the entire team. Data collection is **disabled by default**. - -:::note -Some product features — including cloud conversations and {VARS.PLATFORM_RUN}s — require storing conversation data to function. This data is stored to power the product experience and is separate from analytics or telemetry data collection. -::: +## Provider retention, analytics, and storage -Some models carry provider-specific data retention requirements and are therefore not covered by ZDR. For Enterprise teams, these models are **off by default**; a workspace admin must explicitly enable them in the [Admin Panel](/enterprise/team-management/admin-panel/#models-settings). - -Enterprise subscriptions also include: - -* **Team-level enforcement** - Admins configure data collection and telemetry policies for the entire organization through the Admin Panel -* **Secret redaction** - Admins can enable [Secret Redaction](/support-and-community/privacy-and-security/secret-redaction/) for the organization and configure patterns for sensitive data +### Zero Data Retention (ZDR) -### Telemetry categories +Provider ZDR concerns what AI providers retain, not what Warp stores. See the [Warp-wide provider ZDR policy](/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr) for its scope and the boundary for requests through your own provider account. [Model choice](/agents/inference/model-choice/#models-requiring-provider-retention) lists the model exceptions. -When telemetry is enabled, Warp collects: +### Warp analytics and improvement collection -1. **Product usage analytics** - High-level metrics on feature adoption and usage patterns (e.g., "Agent Mode was opened," "workflow was executed"). -2. **Performance and stability** - Crash reports, error tracking, and performance metrics to identify and fix issues. +Review [Warp's analytics and improvement controls](/support-and-community/privacy-and-security/privacy/#warp-analytics-and-improvement-collection) separately from provider retention and storage. Admins manage organization-enforced settings through the [Admin Panel](/enterprise/team-management/admin-panel/#privacy-settings). -When data collection is disabled, Warp does not collect: +### Product storage -* Personally identifiable information beyond user IDs and email addresses -* Network traffic or external API calls +See [product storage boundaries](/support-and-community/privacy-and-security/privacy/#product-storage) for Terminal conversations, factory run history, shared sessions, and snapshots. Enterprise admins can configure [self-hosted agent data storage](/factories/self-hosting/data-storage/) separately from execution hosting. ### Disabling telemetry -Users can opt out of telemetry individually: - -1. Navigate to **Settings** > **Privacy**. -2. Toggle off **Help improve Warp** and/or **Send crash reports**. - -With telemetry disabled, Warp stops collecting usage and interaction data for analytics purposes. - -Team admins can enforce telemetry settings organization-wide through the Admin Panel. On Business and Enterprise plans, data collection is disabled by default. +Follow [Privacy and data control](/support-and-community/privacy-and-security/privacy/#how-to-disable-telemetry-and-crash-reporting) to change your collection preferences. If your organization manages a control, ask an admin to review the [Admin Panel privacy settings](/enterprise/team-management/admin-panel/#privacy-settings). ## Data handling and privacy @@ -71,10 +44,10 @@ Team admins can enforce telemetry settings organization-wide through the Admin P * **Code and files** - Stay on your machine unless you explicitly use features that transmit them (e.g., Codebase Context indexing, session sharing, Warp Drive team resources) * **Codebase Context** - During indexing, code is sent to Warp's servers to generate embeddings; the raw code is not stored, only the resulting embeddings are retained -* **Agent requests** - Warp sends requests to contracted LLM providers (Anthropic, OpenAI, Google, xAI) with Zero Data Retention agreements for Enterprise teams -* **BYOLLM** - Requests are proxied through Warp's servers to your cloud infrastructure, where inference runs. Warp does not store the content of these requests. +* **Agent requests** - Provider retention depends on the model and provider account. See the [provider ZDR policy](/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr). +* **BYOLLM** - Requests are proxied through Warp's servers to your cloud infrastructure, where inference runs. See [retention for requests through your provider account](/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr). * **Team-managed API keys and endpoints** - When an admin configures [team-managed API keys and endpoints](/enterprise/enterprise-features/team-managed-keys-and-endpoints/), the keys are encrypted and stored server-side, never synced to member devices, and never delivered to cloud agent environments. They're decrypted only in memory when serving a request. -* **Self-hosted cloud agent execution** - Repository clones, build artifacts, runtime secrets, and execution workspaces stay on your infrastructure. Orchestration metadata, session transcripts, and LLM inference requests and responses route through Warp under ZDR, and can include code context from agent interactions. +* **Self-hosted cloud agent execution** - Repository checkouts and execution workspaces stay on your infrastructure. Prompts, transcripts, attachments, and uploaded artifacts can contain code context. Inference and run-data storage have [separate boundaries](/factories/infrastructure-and-security/). ### Encryption @@ -96,7 +69,7 @@ See [Secret Redaction documentation](/support-and-community/privacy-and-security ### Data retention -* **ZDR** - Warp's contracted LLM providers do not retain or train on your data +* **Inference and product data** - See [provider retention](/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr) and [feature-specific storage](/support-and-community/privacy-and-security/privacy/#product-storage) * **Telemetry data** - When collected, Warp retains telemetry data indefinitely for analytics and debugging * **User accounts** - Data deletion requests are processed securely within 30 days at no cost, following verified authentication and compliance with legal and contractual obligations @@ -130,7 +103,7 @@ Enterprise teams can self-host cloud agent execution to control where agents run Self-hosted deployments use a split architecture: * **Execution plane (customer-hosted)** - Repository clones, build artifacts, runtime secrets, and container filesystem state stay on your infrastructure -* **Control plane (Warp-hosted)** - Session transcripts (which include code context from agent interactions), orchestration metadata, and LLM inference route through Warp's servers under Zero Data Retention (ZDR) agreements. Warp does not persistently store your source code or use it for model training +* **Control plane (Warp-hosted)** - Warp coordinates runs and routes Warp Agent inference. Transcripts can contain code context and persist as product data independently of [provider ZDR](/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr). Claude Code and Codex call their providers directly. Two deployment modes are available: * **Unmanaged** - Use `oz agent run` to run agents in your existing orchestrator or CI environment. Supports Linux, macOS, and Windows with no Docker dependency. @@ -187,7 +160,7 @@ Isolate agent execution in containerized environments: * **Process isolation** - Agents run in separate Docker containers, isolated from your host system * **Resource limits** - Configure CPU, memory, and disk quotas per sandbox * **Network controls** - Restrict outbound network access from sandboxes -* **Ephemeral environments** - Sandboxes are destroyed after use, leaving no trace +* **Ephemeral environments** - Sandboxes are destroyed after use; saved snapshots and run data have separate storage behavior ### Agent permissions @@ -219,7 +192,7 @@ Enterprise customers receive priority security support: * **Incident assistance** - Support during security incidents or breach investigations * **Compliance assistance** - Help with compliance questionnaires and audits -## Additional resources +## Related pages * [Warp privacy policy](https://www.warp.dev/legal/privacy-policy) * [Warp Trust Center](https://trust.warp.dev) — security documentation and compliance reports. See also [Trust Center](/enterprise/security-and-compliance/trust-center/) for details on requesting SOC 2 reports, subprocessors, and vendor security assessments. diff --git a/src/content/docs/enterprise/security-and-compliance/trust-center.mdx b/src/content/docs/enterprise/security-and-compliance/trust-center.mdx index c4aefffd5..8342bcb6f 100644 --- a/src/content/docs/enterprise/security-and-compliance/trust-center.mdx +++ b/src/content/docs/enterprise/security-and-compliance/trust-center.mdx @@ -29,7 +29,7 @@ Warp publishes a list of subprocessors — third-party service providers that pr View the current list of subprocessors at [Warp subprocessors list](https://www.warp.dev/legal/subprocessors). :::note -Warp maintains **Zero Data Retention (ZDR)** agreements with its contracted LLM providers (Anthropic, OpenAI, Google, xAI), meaning they do not store or train on your data. +See [Privacy and data control](/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr) for Warp's provider Zero Data Retention (ZDR) policy and [Agent model choice](/agents/inference/model-choice/#models-requiring-provider-retention) for model exceptions. Factory customers can review [coverage and configuration steps](/factories/zero-data-retention/) separately from analytics and storage. ::: ## Security documentation diff --git a/src/content/docs/enterprise/team-management/admin-panel.mdx b/src/content/docs/enterprise/team-management/admin-panel.mdx index a47140d88..a524ed1d8 100644 --- a/src/content/docs/enterprise/team-management/admin-panel.mdx +++ b/src/content/docs/enterprise/team-management/admin-panel.mdx @@ -33,7 +33,7 @@ Access the Admin Panel in two ways: **Option 1: Direct URL** 1. Navigate to the [Warp Admin Panel](https://app.warp.dev/admin/). -2. Log in with your SSO credentials. +2. Sign in to your Warp account. 3. The Admin Panel opens with all organization settings. **Option 2: From Warp Settings** @@ -65,7 +65,7 @@ In multi-team workspaces, workspace admins can enforce supported settings across **Respect user setting** * Allows individual team members to control the setting themselves * Admins set a default, but users can customize -* Use for preferences that don't impact security or compliance (e.g., AI model selection) +* Use when members are allowed to choose their own preference; this doesn't restrict model availability **Tier restricted** * Setting is locked based on billing plan @@ -129,7 +129,7 @@ Configure how agents behave across your organization, including autonomy levels **Prompt summarization caching** * When conversations become long, the LLM provider caches summaries temporarily * Improves performance for extended agent interactions -* Zero Data Retention agreements cover caching (short-lived) +* Provider retention follows the selected model and inference configuration; see [model retention policies](/agents/inference/model-choice/#zero-data-retention-policies) #### Autonomy settings @@ -184,11 +184,27 @@ Manage data collection and security policies to meet your organization's complia **User-generated content (UGC) data collection** Controls how Warp collects and uses user-generated content to improve the service: -* **Disabled** - Warp collects no UGC data from your organization +* **Disabled** - Warp doesn't collect UGC for service improvement * **Enabled** - Allow data collection for service improvement * **Respect User Setting** - Let individual users decide -Enterprise teams with Zero Data Retention agreements can disable this completely. +This controls team content collection for service improvement. Personal analytics and crash-report preferences are separate. It doesn't change [provider retention requirements](/agents/inference/model-choice/#models-requiring-provider-retention) or disable product storage. + +{/* TODO(factory-plans): Revisit browser collection controls with the factory plans documentation update. Confirm plan eligibility, team-wide versus individual opt-out scope, and the browser route for customers without Terminal. Keep Factory plan names distinct from Terminal plan names. */} + +#### Changing improvement collection in a browser + +Business and Enterprise team admins can configure the team's content collection without installing Warp Terminal: + +1. Open the [Admin Panel](https://app.warp.dev/admin/) for the team and go to **Privacy**. +2. In the "UGC Data Collection" dropdown, choose **Disabled** to stop team content collection for improvement, or **Respect User Setting** to defer to individual preferences. +3. After the update succeeds, reload the page and confirm the selected value persists. + +If the control is locked by a workspace policy, ask a workspace admin to review it. If your plan doesn't permit changes, or you need a personal browser-only opt-out, contact [privacy@warp.dev](mailto:privacy@warp.dev) to confirm the available options. This isn't a provider ZDR control or a way to delete saved runs. + +**Cloud conversation storage** + +Controls cloud sync of personal Terminal conversations. Disabling it doesn't disable factory or other cloud agent run storage. See [product storage](/support-and-community/privacy-and-security/privacy/#product-storage) for run-data categories and storage options. **Enterprise secret redaction** Automatically detects and redacts sensitive information before sending data to LLM providers: @@ -216,15 +232,17 @@ When enabled, agents understand your code patterns, architecture, and convention ### Models settings -Control which LLM models are available to your team and how inference is routed. From the **Models** page, admins can enable or disable individual models and configure [Bring Your Own LLM (BYOLLM)](/enterprise/enterprise-features/bring-your-own-llm/) routing through AWS Bedrock or [Gemini Enterprise (Vertex AI)](/enterprise/enterprise-features/byollm-gemini-enterprise/). +Use the **Models** page for the controls included in your plan: -From the **Models** page, admins can also configure [team-managed API keys and endpoints](/enterprise/enterprise-features/team-managed-keys-and-endpoints/) in the **Bring Your Own Keys & Endpoints** card, sharing provider keys and custom endpoints across the team for both interactive sessions and cloud agents. - -From the **Models** page, admins can also create team-synced [custom routers](/agents/inference/custom-routers/) that route each task to a model based on complexity or rules. Team-synced routers appear in the model picker for every team member. +* **Enterprise model restrictions** - Admins can enable or disable individual models and configure [BYOLLM routing](/enterprise/enterprise-features/bring-your-own-llm/). Self-serve plans don't include a team-wide model-blocking control. +* **Business and Enterprise provider credentials** - Configure [team-managed API keys and endpoints](/enterprise/enterprise-features/team-managed-keys-and-endpoints/) for local and cloud Warp Agent runs. Sharing credentials isn't a model restriction. +* **Enterprise custom routers** - Share [routing rules](/agents/inference/custom-routers/#team-synced-routers) with the team. A router's choices are separate from enforced model availability. **Models with provider-specific data retention requirements** -Some models require data retention from the model provider and are therefore not available under [Zero Data Retention (ZDR)](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr). For Enterprise teams, these models are **disabled by default**. A workspace admin must explicitly enable them before team members can use them. +Some models require provider retention and aren't covered by [Zero Data Retention (ZDR)](/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr), even when UGC collection is disabled. Review the complete [exception list on the model-choice page](/agents/inference/model-choice/#models-requiring-provider-retention). For Enterprise teams, these models are **disabled by default**. A workspace admin must explicitly enable them before team members can use them. + +Disabling UGC collection isn't a model restriction. Self-serve customers must review their selected models and overrides using the [Terminal procedure](/agents/inference/model-choice/#reviewing-inference-and-privacy-in-terminal) or [factory ZDR guidance](/factories/zero-data-retention/). ### Billing settings diff --git a/src/content/docs/factories/factory-agents/configuration.mdx b/src/content/docs/factories/factory-agents/configuration.mdx index 97fbbbcb5..d326ffdde 100644 --- a/src/content/docs/factories/factory-agents/configuration.mdx +++ b/src/content/docs/factories/factory-agents/configuration.mdx @@ -59,7 +59,68 @@ The model picker also includes custom routers from factories you can access. See For team-managed inference in definition files, see [custom endpoint and BYOK model values](/factories/factory-as-code/#custom-inference-endpoints-and-byok), including factory defaults and per-agent overrides. -### Configuring a third-party harness +## Reviewing inference for provider ZDR + +Avoid [retention-required models](/agents/inference/model-choice/#models-requiring-provider-retention) in the settings you control. Read [factory ZDR coverage and its limits](/factories/zero-data-retention/) first. Both paths work in a browser without Warp Terminal. + +Ask an admin whose [provider account](/factories/infrastructure-and-security/#inference-options-for-factory-runs) serves your models. For customer-owned accounts or third-party harnesses, [verify retention with the provider](/factories/zero-data-retention/#choose-inference-covered-by-provider-zdr). Don't switch credentials or harnesses solely to follow these steps. + +Choose by [where the definition is managed](/factories/factory-as-code/#where-the-definition-lives): follow the GitHub repository link in **Settings**, or use **Factory definition** for a Warp-managed definition. Ask an admin if the mode is unclear; API-managed factories have no definition files. + +Defaults apply only where inherited; agent and automation overrides can select another model. + +### Reviewing a dashboard-managed factory + +You need [editing access](#prerequisites). Read-only controls don't identify the management mode; ask an admin to confirm your access. + +1. Open the {VARS.FACTORY_WEB_APP}, expand your factory, and click **Factory definition**. Open the existing `factory.yaml`. +2. Set the Warp Agent default (`type: oz`) outside the exception list using `agentDefaults.model` or `agentDefaults.harness.model`. Keep one form; see [model syntax](/factories/factory-as-code/#agentdefaultsmodel). For third-party harnesses, verify provider retention instead. Click **Save** and resolve validation errors. +3. In **Agents**, open each agent's **Settings**. Check the "Harness" and "Model" selections, including the foreman and agents it dispatches. For agents using the Warp Agent, choose a model outside the exception list and click **Save**. +4. Complete [additional model checks](#checking-separate-model-settings), then save. Reopen changed agent settings and compare their model and harness with your intended values before [testing](#checking-new-runs). Saved files alone don't prove application. + +### Reviewing a GitHub-backed factory + +You need permission to propose and merge changes in the definition's GitHub repository. The dashboard editors are read-only. + +1. In the {VARS.FACTORY_WEB_APP}, expand your factory and open **Settings**. Follow the definition repository link, then create a branch for the changes. +2. In `factory.yaml`, set the Warp Agent default (`type: oz`) outside the exception list using `agentDefaults.model` or `agentDefaults.harness.model`. Keep one form; see [model syntax](/factories/factory-as-code/#agentdefaultsmodel). Verify third-party harness choices with their provider. +3. In each existing `agents//agent.md`, including the foreman, replace exception models in Warp Agent `model` or `harness.model` overrides. Preserve unrelated settings and instructions. +4. Complete the applicable [additional model checks](#checking-separate-model-settings) in the definition files. +5. Pass the [factory-definition PR checks](/factories/factory-as-code/#pull-request-checks) and merge into the connected production branch. Reopen changed agents in the dashboard and compare their model and harness with the merged values before [testing](#checking-new-runs). PR checks validate proposed changes, not post-merge application. + +### Checking separate model settings + +Complete each check that applies to your factory rather than assuming every feature uses the foreman's model. + +| If you use… | Check before starting work | +| --- | --- | +| Automations | In `automations//automation.md`, replace exception models in `model` or `harness.model`; these override the target agent. Dashboard-managed factories use **Factory definition**, not the **Automations** editor, for these settings. | +| Computer Use | Check `agentDefaults.computerUseModel` in `factory.yaml` and `computerUseModel` overrides in agent and automation files. Replace exception models. Omitted values inherit or use automatic selection; see [Computer Use inheritance](/factories/factory-as-code/#agentdefaultscomputerusemodel). | +| Scorers | In **Scorers**, change exceptions in each "Judge model" and save. For GitHub-backed definitions, edit `model` in `scorers//scorer.md`. | +| Custom routers | Inspect every target and default in the [router definition](/factories/factory-as-code/#routersnameyaml). If another factory owns it, ask its editor or admin to verify the choices, or select an inspectable concrete model. Access to this factory doesn't grant access elsewhere. | +| Benchmarks | Before launching, check each trial's harness, model, selected Scorers, and any supplied overrides. See [running a benchmark](/factories/benchmarks/#create-and-run-a-benchmark). | +| API, CLI, or agent-started runs | Check supplied model, harness, and Computer Use overrides before dispatching the run. | + +Self-improvement analyzes run data with a separate model, not the foreman's model. Before using it with sensitive data, ask Warp to confirm that model and its provider coverage. + +### Checking new runs + +Use a test factory with non-sensitive repositories and inputs. Resolve validation errors first. If changes remain pending or fail to apply, don't send sensitive work; [contact support](/support-and-community/troubleshooting-and-support/sending-us-feedback/) with the factory link and, for GitHub, the merge commit. + +1. In the web app, click **New Chat**, choose your factory, and send: “Reply with a greeting. Don't read repository files or call tools.” This is a basic run check, not a test of every agent or feature. +2. In **Runs**, open the new run and inspect its model and harness. If it dispatches child runs, check those separately. If a selection differs from your configuration, check agent, automation, and run overrides before sending sensitive work. + +Exercise changed paths separately: + +* Agents and automations: request a greeting from each changed agent or send a matching test event; inspect the receiving agent and child runs. +* Computer Use: request the page title from `https://example.com`; check for Computer Use in the session. +* Scorers: score a non-sensitive completed run; inspect the judge configuration and result. +* Routers: test representative routing rules or complexity levels; inspect resolved models, not only the router name. +* Benchmarks and caller overrides: run a non-sensitive trial or request with the reviewed choices; inspect resulting runs. + +Record settings inspected and paths exercised separately. These checks don't prove provider contracts or every background request. Existing runs keep their model; recheck new runs after configuration changes. + +## Configuring a third-party harness Change an agent's harness to Claude Code or Codex to run it with that provider's own coding tool. diff --git a/src/content/docs/factories/factory-dashboard.mdx b/src/content/docs/factories/factory-dashboard.mdx index 4a5c54aa1..beeccec01 100644 --- a/src/content/docs/factories/factory-dashboard.mdx +++ b/src/content/docs/factories/factory-dashboard.mdx @@ -20,7 +20,7 @@ Select a factory in the sidebar to open its pages. **Runs**, **MCPs and apps**, To send work to a factory's foreman, click **New Chat** in the sidebar. In the dropdown below the prompt input, choose your factory, enter a request, then click the send arrow. -A factory opens on its **Dashboard** page, covered next. **Factory definition** appears only on Warp-managed factories, since a factory whose definition lives in your own repository is edited there instead. +A factory opens on its **Dashboard** page, covered next. Use **Factory definition** to edit a Warp-managed definition; edit a GitHub-backed definition in its repository instead. See [where the definition lives](/factories/factory-as-code/#where-the-definition-lives). To create credentials or grant agents access, see [managing secrets for factory agents](/factories/secrets/). @@ -69,7 +69,7 @@ The automation editor doesn't change execution settings; an automation only over **Factory definition** is the factory dashboard's view of the definition files that [definitions as code](/factories/factory-as-code/) describes in full. Where the definition lives decides what you get: * **Warp-managed** - Browse and edit the definition files. Saving validates the definition and commits all changes together. -* **Managed in GitHub** - The tab doesn't appear. Edit the definition through pull requests in your repository, and **Settings** links back to it. +* **Managed in GitHub** - Edit the definition through pull requests in your repository; **Settings** links back to it. * **Live-managed** - The factory is managed through the API, so there are no definition files to browse. When an agent proposes a change to a Warp-managed definition, a spec review for the branch appears on [Home](/factories/factory-home/) when the **Waiting on you** filter is selected. Open the spec review to comment on the diff, select **Request changes** to send feedback to the agent, or select **Approve & merge** to merge the change. diff --git a/src/content/docs/factories/index.mdx b/src/content/docs/factories/index.mdx index 573e30488..56c6701da 100644 --- a/src/content/docs/factories/index.mdx +++ b/src/content/docs/factories/index.mdx @@ -14,6 +14,8 @@ Warp Factories is open, flexible infrastructure for building your own software f Your factory puts agents to work on your team’s development tasks. For example, it can take an issue from Slack, GitHub, Linear, or Jira, investigate it, implement a change, and return a pull request for review. You define how the work moves between agents and where people need to make decisions. +Before sending sensitive work, review [ZDR, data collection, and storage for factory runs](/factories/zero-data-retention/). + + +## Provider retention + + + + + +Provider retention is separate from execution hosting and saved run data. For coverage limits, collection controls, and browser setup procedures, see [Zero data retention (ZDR) for factory inference](/factories/zero-data-retention/). ## Control plane and execution plane @@ -70,7 +80,6 @@ The worker backend sets isolation and scheduling on your infrastructure: For backend selection guidance, including Command and one-shot Direct options, see [Choosing a managed backend](/factories/self-hosting/#choosing-a-managed-backend). - ## Choose inference independently Execution hosting doesn't select inference. Configure that boundary separately. @@ -86,7 +95,9 @@ Factory agents execute as cloud agents. For runs using the Warp Agent, support v | **[BYOLLM: AWS Bedrock](/enterprise/enterprise-features/byollm-aws-bedrock/)** | Supported on Enterprise | The AWS account, IAM role, available Claude models, and provider billing | Warp assumes your IAM role through OIDC; inference runs in your AWS account | | **[BYOLLM: Gemini Enterprise](/enterprise/enterprise-features/byollm-gemini-enterprise/)** | Not supported for factory runs | Interactive inference in your Google Cloud project | Gemini Enterprise BYOLLM currently supports interactive agent requests only | -Personal BYOK and personal custom inference endpoints are stored on a member's device and don't apply to factory runs. With team-managed keys and endpoints, select a specific provider model or endpoint. Auto continues to use Warp-managed inference. Your provider's retention follows your account and contract. Warp can't enforce ZDR for that provider. +Personal BYOK and personal custom inference endpoints are stored on a member's device and don't apply to factory runs. With team-managed keys and endpoints, select a specific provider model or endpoint. Auto continues to use Warp-managed inference. Check [provider ZDR coverage](/factories/zero-data-retention/#choose-inference-covered-by-provider-zdr) separately, including any upstream providers behind a gateway. + +Claude Code and Codex call their providers directly from the execution environment using their own [harness authentication](/factories/harnesses/authentication/), not the Warp Agent's inference configuration. ### Networking for BYO inference endpoints @@ -138,6 +149,7 @@ Warp meters hosted compute, Warp-provided inference, and [platform usage](/suppo ## Related pages +* [Zero data retention (ZDR) for factory inference](/factories/zero-data-retention/) - Review coverage, collection, and saved run data * [Deployment patterns for Warp Factories](/factories/deployment-patterns/) - Compare execution models * [Runners for Warp Factories](/factories/runners/) - Configure compute and worker compatibility * [Self-hosting overview](/factories/self-hosting/) - Review managed backends and setup requirements diff --git a/src/content/docs/factories/self-hosting/security-and-networking.mdx b/src/content/docs/factories/self-hosting/security-and-networking.mdx index 343c8e1c6..7b556482d 100644 --- a/src/content/docs/factories/self-hosting/security-and-networking.mdx +++ b/src/content/docs/factories/self-hosting/security-and-networking.mdx @@ -22,7 +22,7 @@ Self-hosted factory workers run repository checkouts and agent workloads on your * Run attachments and artifacts. * The Warp Agent's LLM inference requests and responses, which include code context from the agent's interactions. -Code content can appear in transcripts, artifacts, and LLM prompts even though repository checkouts stay on your infrastructure. Run data is stored separately from the execution workspace; see [Self-hosted agent data storage](/factories/self-hosting/data-storage/). For retention and provider boundaries, see [Security overview](/enterprise/security-and-compliance/security-overview/) and [LLM inference and BYOLLM](#llm-inference-and-byollm). +Code content can appear in transcripts, artifacts, and LLM prompts even though repository checkouts stay on your infrastructure. Run data is stored separately from the execution workspace; see [Self-hosted agent data storage](/factories/self-hosting/data-storage/). For retention and provider boundaries, see [Privacy and data control](/support-and-community/privacy-and-security/privacy/#provider-retention-analytics-and-storage) and [LLM inference and BYOLLM](#llm-inference-and-byollm). --- @@ -117,11 +117,13 @@ See [GitLab](/platform/integrations/gitlab/) and [Bitbucket](/platform/integrati ## LLM inference and BYOLLM -The Warp Agent sends inference requests through Warp. With Warp-managed inference, requests go to contracted providers covered by [ZDR](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) agreements. With customer-supplied inference, provider-side retention follows your team's agreement with that provider. +The Warp Agent sends inference requests through Warp. Review [factory ZDR coverage and configuration](/factories/zero-data-retention/) independently of where commands run. + +For customer-supplied inference, verify ZDR with your provider for the specific account, model, and configuration. Self-hosting execution doesn't establish ZDR or move run data. Teams that want inference routed and billed through their own accounts can use [team-managed model keys and endpoints](/enterprise/enterprise-features/team-managed-keys-and-endpoints/) or [Bring Your Own LLM (BYOLLM)](/enterprise/enterprise-features/bring-your-own-llm/). Plan requirements and cloud agent support vary by option; see [inference options for factory runs](/factories/infrastructure-and-security/#inference-options-for-factory-runs). -Claude Code and Codex send inference requests directly to their providers under your provider agreement. Their [authentication](/factories/harnesses/authentication/) and network access are separate from the Warp Agent's inference configuration. +Claude Code and Codex send inference requests directly to their providers under your provider agreement. Verify retention for the account, model, and configuration used by their [authentication](/factories/harnesses/authentication/), separately from the Warp Agent's inference configuration. --- @@ -131,6 +133,6 @@ Claude Code and Codex send inference requests directly to their providers under * [Unmanaged execution](/platform/unmanaged-execution/) - Run standalone agents from your own CI or scheduler * [About factory infrastructure and security](/factories/infrastructure-and-security/) - Choose execution, inference, and credential boundaries * [Data security and boundaries](/platform/architecture/#data-security-and-boundaries) - Review where each class of data lives and travels -* [Security overview](/enterprise/security-and-compliance/security-overview/) - Review Warp's security model and ZDR +* [Privacy and data control](/support-and-community/privacy-and-security/privacy/) - Review provider ZDR, analytics, and storage * [Bring Your Own LLM](/enterprise/enterprise-features/bring-your-own-llm/) - Route inference through your own cloud provider accounts * [Self-hosted worker reference](/factories/self-hosting/reference/) - Look up worker flags and configuration diff --git a/src/content/docs/factories/zero-data-retention.mdx b/src/content/docs/factories/zero-data-retention.mdx new file mode 100644 index 000000000..9a74bde78 --- /dev/null +++ b/src/content/docs/factories/zero-data-retention.mdx @@ -0,0 +1,49 @@ +--- +title: Zero data retention (ZDR) for factory inference +description: >- + Provider ZDR, improvement collection, and saved factory runs are separate. + Review coverage and controls before sending sensitive work. +sidebar: + label: "Zero data retention (ZDR)" +--- + +Provider Zero Data Retention (ZDR) covers whether the AI provider keeps your prompts and responses. For factory inference, coverage depends on the model and whose provider account serves the request, not where the agent runs commands. For example, self-hosting execution does not establish provider ZDR or move saved run data. + +Warp's [provider ZDR policy](/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr) applies to supported models on every plan when Warp supplies the provider account. This is called Warp-managed inference. + +## Choose inference covered by provider ZDR + +* **Warp-managed inference** - Choose models outside the [retention-required exception list](/agents/inference/model-choice/#models-requiring-provider-retention). Apply that choice to each agent and any separate model settings or overrides, not only the foreman. +* **Your provider account** - For team-managed keys and endpoints, BYOLLM, or direct Claude Code or Codex calls, you'll need to verify ZDR with the provider for your specific account, model, and configuration. Warp's agreements don't establish ZDR for those requests, even if you avoid the listed models. For an endpoint that uses other model providers, verify their retention policies too. + +Current Auto selections, fallback chains for models outside the exception list, and automatic Computer Use selection avoid the listed exceptions, but routes can change. Coverage of every background AI request remains unconfirmed. If your policy requires ZDR for every request, ask Warp to confirm coverage for your configuration before sending sensitive work. + +See [inference options for factory runs](/factories/infrastructure-and-security/#inference-options-for-factory-runs) for supported providers, credentials, and harnesses. Personal keys and endpoints stored on your device do not apply to factory runs. + +## Understand collection and storage + +Provider ZDR doesn't stop Warp from saving data needed to operate your factory: + +* **Improvement collection** - The **Help improve Warp** toggle controls Warp's analytics and eligible content collection for service improvement. It doesn't change provider retention. +* **Run history** - Warp stores transcripts, prompt attachments, and uploaded artifacts so you can revisit runs, even with analytics off. Destroying a sandbox doesn't delete these records. +* **Personal Terminal sync** - **Store AI conversations in the cloud** controls personal Terminal conversations, not factory run storage. + +For team content collection, follow the [browser procedure in the Admin Panel](/enterprise/team-management/admin-panel/#changing-improvement-collection-in-a-browser), including plan and workspace restrictions. Personal analytics and crash preferences are separate. See [analytics and storage controls](/support-and-community/privacy-and-security/privacy/#provider-retention-analytics-and-storage). + +Enterprise admins can configure [self-hosted storage](/factories/self-hosting/data-storage/) separately for transcripts, prompt attachments, and artifacts. Categories without a self-hosted storage configuration remain with Warp. + +## Configure your factory + +Self-serve teams can change models and overrides manually, but don't have a team-wide model-blocking control. Business supports shared provider keys and endpoints. Enterprise adds [model restrictions in the Admin Panel](/enterprise/team-management/admin-panel/#models-settings). + +Choose the procedure for where your definition is managed. Both work in a browser without installing Warp Terminal and include checks for defaults, overrides, and new runs: + +* [Reviewing a dashboard-managed factory](/factories/factory-agents/configuration/#reviewing-a-dashboard-managed-factory) +* [Reviewing a GitHub-backed factory](/factories/factory-agents/configuration/#reviewing-a-github-backed-factory) + +## Related pages + +* [Privacy and data control](/support-and-community/privacy-and-security/privacy/) - Review the shared provider policy and collection controls +* [Agent model choice](/agents/inference/model-choice/) - Find models that require provider retention +* [About factory infrastructure and security](/factories/infrastructure-and-security/) - Review hosting, inference, networking, and credential boundaries +* [Self-hosted agent data storage](/factories/self-hosting/data-storage/) - Configure where run data is stored diff --git a/src/content/docs/platform/architecture.mdx b/src/content/docs/platform/architecture.mdx index 3d05fd887..b8ee16939 100644 --- a/src/content/docs/platform/architecture.mdx +++ b/src/content/docs/platform/architecture.mdx @@ -19,7 +19,7 @@ The platform has five layers: clients, the Warp-operated control plane that coor * **Clients** - The surfaces that start and observe work, like the Warp app, the {VARS.WARP_AGENT_CLI}, the web app, the [factory dashboard](/factories/factory-dashboard/), and clients connected through the [Factory MCP](/factories/factory-mcp/). All clients talk to the same control plane APIs. * **APIs** - The control plane's entry points: the [{VARS.WARP_PLATFORM_API} and SDKs](/factories/developer-tools/), a webhook receiver for [integration](/platform/integrations/) events, and the hosted Factory MCP endpoint. * **Control plane** - Warp coordinates runs, manages shared configuration, routes model calls, and records run history. -* **Data plane** - Run data (transcripts, artifacts, and attachments) lives in Warp-managed storage, independent of where runs execute. +* **Data plane** - Run data (transcripts, artifacts, and attachments) uses Warp-managed storage unless you configure [self-hosted agent data storage](/factories/self-hosting/data-storage/), independent of where runs execute. * **Warp-hosted execution** - By default, each cloud agent run gets an isolated sandbox prepared from its environment. See [Warp-hosted execution](/factories/warp-hosting/). * **Self-hosted execution** - On Enterprise, a managed worker runs tasks on your infrastructure. Unmanaged setups run the {VARS.WARP_AGENT_CLI} in your CI or orchestrator. See [Managed self-hosting](/factories/self-hosting/) and [unmanaged execution](/platform/unmanaged-execution/). * **External systems** - The platform connects to identity providers, source control, integration providers, model providers, and a payment provider. @@ -34,7 +34,7 @@ Every cloud agent run follows the same lifecycle, no matter what started it or w 2. **The task is created** - The control plane opens a run record that tracks the task's state, inputs, and provenance. 3. **Configuration is resolved** - The platform picks the run's [environment](/factories/environments/), [runner](/factories/runners/), execution host, and [model and harness](/factories/harnesses/). 4. **The sandbox is provisioned** - The execution host clones the environment's repositories, runs setup commands, and injects only the [secrets](/platform/secrets/) the run is allowed to use. -5. **The agent loop runs** - The harness gathers context, calls the model, and runs tools until the task is done. Tools run in the sandbox. With the Warp Agent, model calls route through Warp to providers under [Zero Data Retention](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr); Claude Code and Codex call their provider directly. +5. **The agent loop runs** - The harness gathers context, calls the model, and runs tools until the task is done. Tools run in the sandbox. The Warp Agent routes model calls through Warp; Claude Code and Codex call their providers directly. See [data security and boundaries](#data-security-and-boundaries) for retention and storage. 6. **Outputs land at their targets** - The agent pushes branches, opens pull requests, and replies to the Slack thread, Linear issue, or Jira work item that started the task. 7. **The run record persists** - Transcripts, artifacts, and cost data attach to the run record. 8. **The team has visibility** - Authorized users follow the run in the {VARS.DASHBOARD} or attach to it with [Agent Session Sharing](/agents/local-agents/session-sharing/). @@ -60,7 +60,7 @@ Self-hosted execution keeps checkout, commands, and the workspace on your infras 2. **Warp assigns the task** - When a trigger targets your worker, the control plane sends the task, its resolved configuration, and scoped runtime credentials over that connection. 3. **The agent runs on your backend** - The worker clones repositories, runs setup, injects allowed [secrets](/platform/secrets/), and executes in a Docker container, a Kubernetes Job, or directly on the host, depending on the [managed backend](/factories/self-hosting/#managed-architecture) you chose. Code, build artifacts, and workspaces stay on your machines. 4. **Run data returns to Warp** - Status, transcripts, artifacts, attachments, and telemetry flow back for the run record. Content the agent puts into prompts or results can include code context; see [execution security](/factories/self-hosting/security-and-networking/). -5. **Warp routes inference** - With the Warp Agent, model calls go from your worker through Warp to LLM providers under [Zero Data Retention](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr), or through your own provider account with [team-managed keys and endpoints](/enterprise/enterprise-features/team-managed-keys-and-endpoints/) or [Bring Your Own LLM](/enterprise/enterprise-features/bring-your-own-llm/). Claude Code and Codex call their provider directly from your infrastructure. +5. **Warp routes inference** - With the Warp Agent, model calls go from your worker through Warp using the [configured inference provider](/factories/infrastructure-and-security/#inference-options-for-factory-runs). Claude Code and Codex call their providers directly from your infrastructure. 6. **Your team monitors the run** - Runs on self-hosted workers appear in the {VARS.DASHBOARD} and support [Agent Session Sharing](/agents/local-agents/session-sharing/), the same as Warp-hosted runs. ### Self-hosted sequence view @@ -73,7 +73,7 @@ This sequence diagram shows the requests and responses exchanged among a trigger 2. **Assign task** - The control plane delivers the task over the worker's authenticated connection, with resolved configuration and scoped runtime credentials. 3. **Prepare workspace** - The worker clones repositories, runs setup commands, and injects allowed secrets. 4. **Prompt and context** - The agent gathers context inside the sandbox and sends it for inference. -5. **Inference** - Model calls from the Warp Agent route through Warp to LLM providers under ZDR, or through your own provider account with team-managed keys and endpoints or Bring Your Own LLM. +5. **Inference** - Model calls from the Warp Agent route through Warp to the configured provider. 6. **Run tools** - Tool calls execute locally: files, commands, internal services, and MCP servers. 7. **Results** - Transcripts, tool outputs, and lifecycle updates return to the run record. 8. **Outputs** - The agent pushes a branch, opens a pull request, and replies to the integration that started the run. @@ -93,9 +93,9 @@ Every run moves a few distinct classes of data, and each class has its own bound ![Warp-hosted data security and boundaries diagram showing repositories, clients, and integrations in customer infrastructure, the per-run sandbox and control plane on the Warp platform, model providers, and Warp-managed run-data storage](../../../assets/agent-platform/warp-hosted-data-boundaries.png) -* **Source code** - For Warp-hosted runs, repositories are cloned into an isolated per-run sandbox and destroyed with it; Warp does not persistently store repository clones or train on your code. For [managed self-hosting](/factories/self-hosting/), checkout and the workspace stay on your infrastructure. Either way, code context the agent puts into prompts, transcripts, or artifacts transits Warp and may persist as run data. -* **Prompts and context** - With the Warp Agent, model calls route through Warp to LLM providers under [Zero Data Retention](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) agreements: providers don't retain or train on the traffic. [Team-managed keys and endpoints](/enterprise/enterprise-features/team-managed-keys-and-endpoints/) and [Bring Your Own LLM](/enterprise/enterprise-features/bring-your-own-llm/) keep the same route but use your provider account. Claude Code and Codex call their provider directly from the execution environment, under your provider agreement rather than Warp's. -* **Run data** - Transcripts, artifacts, and run attachments are stored in Warp-managed storage, encrypted at rest and access-controlled by your team's roles. +* **Source code** - For Warp-hosted runs, repositories are cloned into an isolated per-run sandbox and destroyed with it. For [managed self-hosting](/factories/self-hosting/), checkout and the workspace stay on your infrastructure. Either way, code context the agent puts into prompts, transcripts, or artifacts transits Warp and may persist as run data. +* **Prompts and context** - Provider retention depends on the model and whose account serves the request. See the [provider ZDR policy](/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr), including model exceptions and customer-managed inference. +* **Run data** - Transcripts, artifacts, and prompt attachments persist independently of provider ZDR, analytics preferences, and personal Terminal conversation-sync settings. They use Warp-managed storage unless you configure [self-hosted agent data storage](/factories/self-hosting/data-storage/). * **Control-plane data** - Warp always retains what it needs to operate the platform: user and organization settings, agent and factory configuration, orchestration and lifecycle metadata, trigger and integration metadata, operational logs, and usage and billing. * **Execution secrets** - Secrets you inject locally never transit Warp. [Managed secrets](/platform/secrets/) are stored encrypted and fetched just-in-time by the execution environment with a run-scoped token, and each delivery is audit-logged. Agents can also obtain short-lived cloud credentials at runtime through [workload identity federation](/platform/integrations/cloud-providers/) instead of holding long-lived secrets. [Secret redaction](/support-and-community/privacy-and-security/secret-redaction/) at output boundaries is a backstop, not a substitute for narrow scopes and rotation. * **Inference credentials** - With the Warp Agent, team-managed keys, and Bring Your Own LLM, provider credentials are used only at the Warp–provider boundary and never enter the sandbox. Claude Code and Codex use your provider credentials inside the execution environment, delivered as managed secrets or injected locally. @@ -106,6 +106,8 @@ Every run moves a few distinct classes of data, and each class has its own bound [Managed self-hosting](/factories/self-hosting/) moves the execution boundary: checkout, builds, and command execution stay on your infrastructure, and no Warp-hosted sandbox is involved. The control plane still coordinates runs, holds control-plane data, routes inference for the Warp Agent, and stores run data. +Moving compute doesn't automatically move run-data storage. For factory configuration, follow [factory ZDR guidance](/factories/zero-data-retention/). + ![Self-hosted data security and boundaries diagram showing what stays in customer infrastructure, what Warp retains, Warp-managed run-data storage, and what transits Warp to model providers](../../../assets/agent-platform/data-security-boundaries.png) ## Related pages diff --git a/src/content/docs/support-and-community/plans-and-billing/pricing-faqs.mdx b/src/content/docs/support-and-community/plans-and-billing/pricing-faqs.mdx index c2a43dab4..79255db09 100644 --- a/src/content/docs/support-and-community/plans-and-billing/pricing-faqs.mdx +++ b/src/content/docs/support-and-community/plans-and-billing/pricing-faqs.mdx @@ -41,7 +41,7 @@ Warp offers two options for larger teams and organizations: If you’d like to explore Enterprise, [contact our sales team](https://www.warp.dev/contact-sales) and someone from Warp will follow up. ::: -For Warp-managed model traffic (requests Warp routes to OpenAI, Anthropic, Google, or xAI on your behalf), all plans are covered by Warp's Zero Data Retention (ZDR) agreements with the underlying model providers. Traffic you route through your own API key or a custom inference endpoint is governed by that provider's data-retention policies, not Warp's agreements. Admin-configurable data controls — including team-wide retention policies and training opt-outs — are available on Business and Enterprise. +Provider ZDR and analytics opt-out are separate from your plan's model controls. See [Warp's provider ZDR policy](/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr) and [factory ZDR guidance](/factories/zero-data-retention/) for coverage, exceptions, and what self-serve teams can configure. ### What counts as a team member and how does billing work for members? @@ -242,25 +242,13 @@ Yes. Warp has obtained a SOC 2 Type 2 attestation from an accredited third party ### Does Warp have Zero Data Retention policies with LLM providers? -Warp integrates with multiple LLM providers — including Anthropic, OpenAI, Google, xAI, and Fireworks AI — to power its AI features. Warp has executed Zero Data Retention (ZDR) agreements with these providers. Across all plans, these agreements mean: - -* LLM providers commit not to train their models on any customer-generated data processed through Warp's services. -* LLM providers commit to delete inputs and outputs after generating the relevant output, within a fixed time period. - -Warp enforces these commitments through both technical measures and contractual safeguards with the LLM providers. - -Zero data retention is available for supported models. Model availability may vary where providers require data retention for safety, abuse monitoring, or compliance reasons. +Yes. Warp has provider Zero Data Retention (ZDR) agreements for supported Warp-managed models across plans, with [model-specific exceptions](/agents/inference/model-choice/#models-requiring-provider-retention). See [Privacy and data control](/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr) for the policy, including customer-managed inference. ### How can I enable Zero Data Retention in Warp? -Zero Data Retention (ZDR) can be enabled in two ways: - -* **Individual level** — Any user can enable full ZDR for their own account by disabling **Help Improve Warp** in **Settings** > **Privacy**. -* **Organization-wide** — On Business and Enterprise plans, admins can enforce ZDR for all members from the [Admin Panel](/enterprise/team-management/admin-panel/), so team-wide compliance doesn't rely on individual settings. - -To discuss organization-wide ZDR for your team, [contact our sales team](https://www.warp.dev/contact-sales). +Provider ZDR isn't enabled by turning off analytics. Choose covered inference and review the [Terminal settings](/agents/inference/model-choice/#reviewing-inference-and-privacy-in-terminal) or [factory ZDR guidance](/factories/zero-data-retention/) for your workflow. -Regardless of plan, Warp never allows OpenAI, Anthropic, Google, xAI, or other model providers to store, retain, or train their models on your data — see [Does Warp have Zero Data Retention policies with LLM providers?](#does-warp-have-zero-data-retention-policies-with-llm-providers) for details. +**Help improve Warp** controls analytics and improvement collection. Turning it off doesn't change provider retention requirements or disable product storage, including factory transcripts, attachments, and artifacts. Start with [Privacy and data control](/support-and-community/privacy-and-security/privacy/#provider-retention-analytics-and-storage) to review these three separate controls. ### Can I bring my own API key? diff --git a/src/content/docs/support-and-community/privacy-and-security/privacy.mdx b/src/content/docs/support-and-community/privacy-and-security/privacy.mdx index f705e3097..aa09b0432 100644 --- a/src/content/docs/support-and-community/privacy-and-security/privacy.mdx +++ b/src/content/docs/support-and-community/privacy-and-security/privacy.mdx @@ -1,15 +1,46 @@ --- title: Privacy and data control sidebar: - label: "Privacy" + label: "Privacy and ZDR" description: >- - Warp's approach to privacy and your control over your data + Review Warp's provider Zero Data Retention policy, analytics controls, and + conversation storage across Terminal, cloud agents, and factories. --- +Provider retention, Warp's improvement collection, and conversation storage are separate. For example, turning off analytics doesn't stop a factory from saving its run history. + :::note If you have questions, reach out at [privacy@warp.dev](mailto:privacy@warp.dev). For security-related issues, email [security@warp.dev](mailto:security@warp.dev). ::: +## Provider retention, analytics, and storage + +### Zero Data Retention (ZDR) + +Provider Zero Data Retention (ZDR) governs whether an AI provider retains prompts and responses. Warp has provider ZDR agreements for supported Warp-managed models across all plans. Providers covered by these agreements don't use those prompts and responses for model training. Some models require retention. [Model choice](/agents/inference/model-choice/#models-requiring-provider-retention) lists the model exceptions. + +Warp-managed inference uses Warp's provider account, not your own. Turning off **Help improve Warp** doesn't change a model provider's retention requirements. + +For [personal API keys](/agents/inference/bring-your-own-api-key/), [custom endpoints](/agents/inference/custom-inference-endpoint/), [team-managed inference](/enterprise/enterprise-features/team-managed-keys-and-endpoints/), connected provider subscriptions, and [BYOLLM](/enterprise/enterprise-features/bring-your-own-llm/), you'll need to verify ZDR with your provider for your specific account, model, and configuration. Warp's agreements don't establish ZDR for requests through your provider account. Claude Code and Codex calls made directly to their providers also use your provider terms, not Warp's. + +For configuration steps and coverage limits, follow the [factory ZDR guidance](/factories/zero-data-retention/) or the [Warp Terminal procedure](/agents/inference/model-choice/#reviewing-inference-and-privacy-in-terminal). The factory procedures work in a browser without installing Warp Terminal. + +### Warp analytics and improvement collection + +The **Help improve Warp** toggle controls product analytics and eligible collection of AI interactions and console content for service improvement. Turning it off stops that analytics and improvement collection, subject to [organization-enforced settings](/enterprise/team-management/admin-panel/#privacy-settings). **Send crash reports** is a separate control. + +Neither setting changes a model provider's retention requirements or turns off product storage. See [what Warp collects](#what-telemetry-data-does-warp-collect-and-why) and [how to change collection preferences](#how-to-disable-telemetry-and-crash-reporting). + +### Product storage + +Product features store data independently of provider ZDR and analytics preferences: + +* **Terminal conversations** - **Store AI conversations in the cloud** controls cloud sync of your personal Terminal conversations. Turning it off doesn't disable factory or other cloud agent run storage. See [Cloud-synced conversations](/agents/local-agents/cloud-conversations/). +* **Factory run data** - Warp stores transcripts, prompt attachments, and uploaded artifacts so you can inspect past runs. Enterprise admins can configure [self-hosted agent data storage](/factories/self-hosting/data-storage/) separately for each category. Categories without a self-hosted storage configuration remain with Warp. +* **Shared sessions and snapshots** - Sharing a live session and saving a workspace snapshot have their own storage behavior. See [shared-session retention and access](/agents/local-agents/session-sharing/#data-retention-and-access) and [workspace snapshot controls](/platform/handoff/snapshots/). + +Self-hosting factory execution changes where commands run, not the provider's retention rules or where run data is stored. Review [factory inference and storage separately](/factories/zero-data-retention/). + ## Transparency and control Our philosophy is complete transparency and control over any data leaving your machine. This means you can: @@ -24,31 +55,26 @@ Our philosophy is complete transparency and control over any data leaving your m Warp collects high-level telemetry and usage data to discover product quality issues and guide feature prioritization. -If you haven't opted out of "Help improve Warp", we may collect: +If you haven't opted out of **Help improve Warp**, Warp may collect: 1. High level product usage and analytics data to analyze feature uptake and usage patterns. See the full list of tracked events in the [exhaustive telemetry table](/support-and-community/privacy-and-security/privacy/#exhaustive-telemetry-table) below. These are all high level metrics and do not include any user generated content. 2. AI interactions and console inputs that power our [AI features](/agents/). Configurable [Secret Redaction](/support-and-community/privacy-and-security/secret-redaction/) is disabled by default and masks content that matches your patterns before AI requests are sent. Telemetry payload redaction is separate and applies built-in patterns to telemetry regardless of the Secret Redaction setting. -:::note -Telemetry must be enabled to use AI features on the Free plan, while paid plans can opt out at any time and continue using Warp, including AI. -::: - -:::caution -Business and Enterprise plans are covered by our Zero Data Retention (ZDR) agreement. No AI interaction or console data is ever collected. -::: - Selling usage data will never be part of Warp's business model. This data is used solely to improve the end-user experience. Warp uses Sentry for crash reporting and Rudderstack for app analytics. You can read our [full privacy policy](https://www.warp.dev/legal/privacy-policy) as well as [how Warp handles security](https://www.warp.dev/legal/security). ### How to disable telemetry and crash reporting -1. Navigate to **Settings** > **Privacy**, or open the [Command Palette](/terminal/command-palette/) and search for "privacy" -2. Toggle off "Help improve Warp", "Send crash reports", or both +Without the Warp app, Business and Enterprise admins can change [team content collection for improvement in a browser](/enterprise/team-management/admin-panel/#changing-improvement-collection-in-a-browser). That control is separate from personal analytics and crash preferences. For a personal browser-only opt-out or a plan-locked control, ask [privacy@warp.dev](mailto:privacy@warp.dev) which options are available. + +1. In the Warp app, open **Settings** > **Privacy**. +2. Toggle off **Help improve Warp** to stop analytics and improvement collection. Review **Send crash reports** separately. +3. Review **Store AI conversations in the cloud** for personal Terminal conversation sync. If your organization manages a control, ask an admin to review it. ![Privacy Settings](../../../../assets/support-and-community/privacy-settings-after-signup-1.png) -With telemetry disabled, no console interactions are ever persisted on Warp's servers. Each request contains a `X-Warp-Telemetry-Enabled` header to specify whether telemetry is disabled, and even if this is missing from the request, our server assumes it's disabled. +These settings don't disable product storage. Personal Terminal conversations follow the separate [cloud conversation setting](/agents/local-agents/cloud-conversations/); factory run history follows [factory storage boundaries](/factories/zero-data-retention/#understand-collection-and-storage). Shared sessions have their own [retention and access rules](/agents/local-agents/session-sharing/#data-retention-and-access). ### Delete your account and data diff --git a/src/sidebar.ts b/src/sidebar.ts index 9894ed93d..7b034ffe5 100644 --- a/src/sidebar.ts +++ b/src/sidebar.ts @@ -441,6 +441,7 @@ export const sidebarTopics: StarlightSidebarTopicsUserConfig = [ label: 'Infrastructure', items: [ { slug: 'factories/infrastructure-and-security', label: 'About infrastructure and security' }, + { slug: 'factories/zero-data-retention', label: 'Zero data retention (ZDR)' }, { slug: 'factories/self-hosting/security-and-networking', label: 'Security and networking' }, { slug: 'factories/deployment-patterns', label: 'Deployment patterns' }, { slug: 'factories/warp-hosting', label: 'Warp-hosted execution' },