From 686bd58c216f00a0c67787417efaf7c086b306b0 Mon Sep 17 00:00:00 2001 From: "warp-agent-staging[bot]" <240773466+warp-agent-staging[bot]@users.noreply.github.com> Date: Wed, 11 Nov 2026 19:28:16 +0000 Subject: [PATCH 1/8] docs: Reconcile provider ZDR, analytics, and product storage --- .../docs/agents/getting-started/faqs.mdx | 2 +- src/content/docs/agents/index.mdx | 2 +- .../inference/bring-your-own-api-key.mdx | 10 +-- .../inference/custom-inference-endpoint.mdx | 12 +--- .../docs/agents/inference/model-choice.mdx | 56 ++++++++--------- .../local-agents/cloud-conversations.mdx | 16 ++--- .../architecture-and-deployment.mdx | 32 +++++----- .../team-managed-keys-and-endpoints.mdx | 6 +- src/content/docs/enterprise/index.mdx | 2 +- .../security-overview.mdx | 61 ++++++++----------- .../security-and-compliance/trust-center.mdx | 2 +- .../team-management/admin-panel.mdx | 14 +++-- .../factory-agents/configuration.mdx | 17 ++++++ .../factories/infrastructure-and-security.mdx | 14 ++++- .../self-hosting/security-and-networking.mdx | 6 +- src/content/docs/platform/architecture.mdx | 14 +++-- .../plans-and-billing/pricing-faqs.mdx | 18 +----- .../privacy-and-security/privacy.mdx | 17 +++--- 18 files changed, 148 insertions(+), 153 deletions(-) diff --git a/src/content/docs/agents/getting-started/faqs.mdx b/src/content/docs/agents/getting-started/faqs.mdx index 63d1c1d31..e5eeb077b 100644 --- a/src/content/docs/agents/getting-started/faqs.mdx +++ b/src/content/docs/agents/getting-started/faqs.mdx @@ -21,7 +21,7 @@ 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/). +**Help improve Warp** controls analytics and eligible content collection for service improvement. Covered Warp-managed inference isn't used by the provider for training, but some models require provider retention. See the [model exceptions](/agents/inference/model-choice/#models-requiring-provider-retention) and the [separate analytics and storage controls](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why). ### 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 f1b10abe2..2e0ce490f 100644 --- a/src/content/docs/agents/index.mdx +++ b/src/content/docs/agents/index.mdx @@ -62,7 +62,7 @@ The {VARS.WARP_AUTOMATION_PLATFORM} tab covers the platform in full. ## 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**. Warp-managed inference has provider Zero Data Retention coverage with [model-specific exceptions](/agents/inference/model-choice/#models-requiring-provider-retention). [Analytics and product storage](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why) are separate controls; provider ZDR doesn't disable conversation or run storage. 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..867b27651 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,9 @@ 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's [provider ZDR agreements](/agents/inference/model-choice/#zero-data-retention-policies) apply to covered Warp-managed inference, not requests through your own key. Verify ZDR with your provider for the specific account, model, and configuration; Warp cannot enforce provider ZDR for BYOK. -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. - -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 transit Warp's backend (see [How BYOK works](#how-byok-works)). Warp analytics and product storage remain separate controls; turning off **Help improve Warp** doesn't change your provider's terms or disable [conversation storage](/enterprise/security-and-compliance/security-overview/#product-storage). ### 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..0302bef33 100644 --- a/src/content/docs/agents/inference/custom-inference-endpoint.mdx +++ b/src/content/docs/agents/inference/custom-inference-endpoint.mdx @@ -83,17 +83,11 @@ 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's [provider ZDR agreements](/agents/inference/model-choice/#zero-data-retention-policies) don't establish ZDR for your endpoint. Verify ZDR with the endpoint provider and any upstream model providers for the specific account, model, and configuration. -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. +Custom inference endpoint prompts and responses transit Warp's backend (see [How it works](#how-it-works)). Turning off **Help improve Warp** stops analytics and improvement collection, not provider retention or [product storage](/enterprise/security-and-compliance/security-overview/#product-storage). -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. +Warp cannot enforce provider ZDR for a custom endpoint. Without provider ZDR, requests may be retained according to the endpoint and upstream providers' 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..cfd39c621 100644 --- a/src/content/docs/agents/inference/model-choice.mdx +++ b/src/content/docs/agents/inference/model-choice.mdx @@ -8,14 +8,10 @@ description: >- --- import { VARS } from '@data/vars'; -Warp lets you choose from a curated set of large language models to power your agents, or let Warp auto-select the best model for each task. Models from OpenAI, Anthropic, Google, and open source providers are available, with configurable reasoning levels and per-profile defaults. You can also define [custom routers](/agents/inference/custom-routers/) that pick a model for each task using your own logic. +Choose a model for your agents, use Auto for dynamic selection, or define a [custom router](/agents/inference/custom-routers/). Models support reasoning levels and per-profile defaults. ## Available models -Warp lets you choose from a curated set of large language models (LLMs) to power your Agentic Development Environment. - -**Warp supports the following models.** - The `model_id` values shown below can be used when configuring models via the [{VARS.WARP_AUTOMATION_PLATFORM}](/platform/overview/) or [CLI](/agents/cli/oz-cli/). ### Auto models @@ -27,8 +23,6 @@ The `model_id` values shown below can be used when configuring models via the [{ | Auto (Genius) | `auto-genius` | Adapts to task complexity and selects Warp's most capable model when it's worth it. Best for deep debugging, architecture decisions, and `/plan` sessions. | | Auto (Open-weights) | `auto-open` | Routes between the best open-source models available in Warp. Optimizes for low cost and fast speed using open-weights models. | -All Auto models perform well across all agent workflows and are ideal if you prefer Warp to manage model selection dynamically. - #### OpenAI The `low`, `medium`, `high`, `xhigh`, and `max` suffixes select increasing reasoning levels. @@ -73,7 +67,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 provider retention even when analytics is off. Check [models requiring provider retention](#models-requiring-provider-retention) before selecting a model. ::: #### Google @@ -111,8 +105,6 @@ To use eligible Grok models without Warp-provided inference charges, connect you #### Hosted models (via [Fireworks AI](https://fireworks.ai)) -Warp also supports leading open source models hosted via Fireworks AI, so you can run them from inside Warp without setting up your own inference infrastructure. - | Model | `model_id` | | --- | --- | | GLM 5.3 | `glm-5.3-fireworks` | @@ -124,15 +116,13 @@ Warp also supports leading open source models hosted via Fireworks AI, so you ca ### How to change models -You can use the model picker in your prompt input to quickly switch between models. The currently active model appears directly in the input editor. +In the Warp app's prompt input, click the displayed model name and choose a model. The selection persists for future prompts.
![Model selector dropdown showing available models with Intelligence, Speed, and Cost benchmarks](../../../../assets/agent-platform/model-selector-dropdown.png)
Model selector in Warp's input.
-To change models, click the displayed model name (for example, _Claude Sonnet 5_) to open a dropdown with all supported options. Your selection will automatically persist for future prompts. - ### Custom routers Beyond the built-in Auto models, you can define your own custom routers that automatically route each task to a concrete model based on task complexity or rules you write. Custom routers appear in the model picker alongside Auto and individual models. @@ -141,13 +131,7 @@ Add and manage custom routers in **Settings** > **Agents** > **Warp Agent** > ** ### Model fallback -Warp uses a model fallback system to ensure uninterrupted service if your selected model becomes temporarily unavailable due to provider outages or capacity issues. - -**How it works:** - -* If your selected model isn't available, Warp automatically uses a fallback model from a predefined chain to continue your conversation without errors. -* As soon as your originally selected model becomes available again, Warp automatically switches back to it. -* The fallback model is selected to provide comparable quality and capabilities to your original choice. +If your selected model is unavailable, Warp uses a fallback from a predefined chain with comparable quality and capabilities. Warp switches back when the selected model becomes available. ### Configuring models per Agent Profile @@ -155,23 +139,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 + +To use inference covered by provider ZDR, review the model and its inference source before sending sensitive content: + +1. In the Warp app's prompt input, click the current model name. Choose a Warp-managed model that isn't in the [provider-retention exception list](#models-requiring-provider-retention). If you use Auto, review [automatic selection and fallback](#zero-data-retention-policies); Auto isn't a pinned model. +2. In the Warp app, open **Settings** > **Agents** > **Profiles** and review the active profile's base model. If you use a [custom router](/agents/inference/custom-routers/), review every target and its default model, not only the router's name. +3. In **Settings** > **Agents** > **Warp Agent**, review personal keys, endpoints, and connected subscriptions, and check any [team-managed configuration](/enterprise/enterprise-features/team-managed-keys-and-endpoints/). Search Settings for `API keys` to find personal inference controls. For customer-managed inference, verify provider ZDR for the specific account, model, and configuration. Review [BYOK fallback](/agents/inference/bring-your-own-api-key/#failover-and-fallback-behavior) if enabled. +4. In **Settings** > **Privacy**, toggle off **Help improve Warp** if you don't want analytics and improvement collection. Review **Send crash reports** and **Store AI conversations in the cloud** separately. The storage toggle controls [personal Terminal conversation sync](/agents/local-agents/cloud-conversations/), not factory run storage. + +Before sending the next prompt, confirm the intended model is displayed in the input. Recheck these choices when switching profiles, models, or inference providers. For cloud factory runs, use the [factory review procedure](/factories/factory-agents/configuration/#reviewing-inference-for-provider-zdr) instead. + ### Zero data retention policies -Warp integrates with multiple large language model (LLM) providers to power its AI-driven features. +Warp's provider Zero Data Retention (ZDR) agreements cover Warp-managed inference on all plans, in both Terminal and factory runs, except for the models listed below. Provider ZDR concerns prompts and responses at the inference provider; it doesn't disable [Warp analytics or product storage](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why). -**These providers include, but are not limited to:** +Auto selects models dynamically, and [fallback](#model-fallback) can change the model serving a request. A primary model selection isn't a complete inventory of auxiliary inference, such as Computer Use or Scorers. Review the applicable [factory configuration](/factories/factory-agents/configuration/#reviewing-inference-for-provider-zdr) as well. -* 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 retention for these models, including their effort variants, for safety, abuse monitoring, and compliance: -* 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). Don't rely on Enterprise defaults as a self-serve model restriction. -Zero data retention is available for supported models. Model availability may vary where providers require data retention for safety, abuse monitoring, or compliance reasons. +For your own keys, endpoints, subscriptions, or direct Claude Code and Codex calls, verify ZDR with the provider for your specific account, model, and configuration rather than applying Warp's agreements to that traffic. diff --git a/src/content/docs/agents/local-agents/cloud-conversations.mdx b/src/content/docs/agents/local-agents/cloud-conversations.mdx index c6443e6ac..6f907ee21 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: +Cloud conversation sync for your personal Terminal conversations is controlled separately from analytics and provider retention: -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 enabled, your personal Terminal conversations sync to the cloud as you interact with the agent. When disabled, those conversations are stored locally only. **Help improve Warp** doesn't control this storage; see [analytics and product storage](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why). :::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. +[Cloud agents](/platform/), including factory agents, store run conversations independently of your personal cloud conversation and analytics settings. Run data uses Warp-managed storage unless an Enterprise admin configures [self-hosted agent data storage](/factories/self-hosting/data-storage/). Provider ZDR doesn't disable this product storage. ### Accessing cloud agent conversations @@ -110,11 +110,11 @@ 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 personal Terminal cloud conversation sync for their organization through the [Admin Panel](/enterprise/team-management/admin-panel/#privacy-settings). When cloud conversation storage is disabled by your organization: -* Conversations are stored locally only and not synced to the cloud +* Personal Terminal 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 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..69709b123 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. +* Warp-managed inference has [provider Zero Data Retention (ZDR) coverage with model-specific exceptions](/agents/inference/model-choice/#zero-data-retention-policies). Customer-managed inference uses your provider terms. * 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/infrastructure-and-security/#provider-retention-and-run-storage). ## 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. Code context can still transit Warp in prompts and run data. :::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 routes Warp Agent inference. Provider retention and product storage are [separate from execution hosting](/factories/infrastructure-and-security/#provider-retention-and-run-storage). ### 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 code context in prompts and run data to transit Warp. ## 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; code excerpts can still appear in prompts and transcripts +* **Build artifacts** - Compiled outputs and generated files unless uploaded as run artifacts +* **Shell commands** - Execute locally; command output can appear in stored transcripts * **Runtime secrets** - Environment variables and credentials -* **Execution logs** - Agent run logs and diagnostics +* **Execution logs** - Local runtime logs; uploaded diagnostics and run records are separate ### 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. Verify [provider ZDR coverage and exceptions](/agents/inference/model-choice/#zero-data-retention-policies) separately. Claude Code and Codex call their providers directly. +* **Run data** - Transcripts, prompt attachments, and uploaded artifacts persist independently of analytics preferences and personal Terminal sync settings. [Self-hosted agent data storage](/factories/self-hosting/data-storage/) changes storage mappings separately from compute. +* **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 team has reviewed Warp-hosted compute, inference, and product storage as separate boundaries. * You need maximum parallelization and scalability. **Self-hosted** is right if: -* Compliance requirements mandate that code stays within your network. +* Compliance requirements mandate local checkout and execution while permitting code context in prompts and stored run data. * 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..fd2de7317 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: +Warp's [provider ZDR agreements](/agents/inference/model-choice/#zero-data-retention-policies) don't establish ZDR for requests through your team's keys or endpoints. Verify ZDR with the provider for the specific account, model, and configuration, including upstream providers behind a gateway. Warp cannot enforce provider ZDR for these requests; without it, requests may be retained according to your providers' terms. -* 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. +Warp analytics and [product storage](/enterprise/security-and-compliance/security-overview/#product-storage) remain separate. Disabling UGC collection doesn't change provider retention or disable factory transcripts, prompt attachments, and uploaded artifacts. diff --git a/src/content/docs/enterprise/index.mdx b/src/content/docs/enterprise/index.mdx index 72f428ed5..ed3f1c6c7 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)** - Covers Warp-managed inference with [model-specific exceptions](/agents/inference/model-choice/#models-requiring-provider-retention), separately from analytics and product storage * **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..fd3ec9826 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 provider Zero Data Retention, analytics controls, product storage, + and security boundaries across Warp. --- 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 provider retention, Warp's analytics collection, and product storage separately when choosing how to use Warp. These controls apply to different copies of your data; turning off analytics doesn't disable storage needed for a product feature. ## Transparency and control @@ -23,47 +22,40 @@ Warp's security philosophy centers on **transparency and developer control**: ### 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. +Provider Zero Data Retention (ZDR) governs whether an inference provider retains prompts and responses. Warp's provider ZDR agreements cover Warp-managed inference across all plans, in both Terminal and factory runs, except for the [models that require provider retention](/agents/inference/model-choice/#models-requiring-provider-retention). Covered inference isn't used by the provider for model training. -How data collection works by plan: +For example, turning off **Help improve Warp** doesn't make a retention-required model ZDR-covered. Check the complete exception list on the model-choice page before choosing a model. -* **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**. +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/), verify ZDR with your provider for the specific account, model, and configuration. Warp's agreements don't establish ZDR for customer-managed inference. Claude Code and Codex calls made directly to their providers also use your provider terms, not Warp's. -:::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. -::: - -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). +Review [Terminal model and privacy settings](/agents/inference/model-choice/#reviewing-inference-and-privacy-in-terminal) or [factory inference settings](/factories/factory-agents/configuration/#reviewing-inference-for-provider-zdr) for the product you use. Factory users don't need to configure Terminal to review factory inference. -Enterprise subscriptions also include: +### Warp analytics and improvement collection -* **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 +**Help improve Warp** 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. -### Telemetry categories +Neither setting changes a model provider's retention requirements or turns off product storage. See [Privacy and data control](/support-and-community/privacy-and-security/privacy/#how-to-disable-telemetry-and-crash-reporting) for the controls and collected event types. -When telemetry is enabled, Warp collects: +### Product storage -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. +Product features store data independently of provider ZDR and analytics preferences: -When data collection is disabled, Warp does not collect: +* **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** - Transcripts, prompt attachments, and uploaded artifacts persist so you can inspect past runs. They use Warp-managed storage unless an Enterprise admin configures [self-hosted agent data storage](/factories/self-hosting/data-storage/). Categories are mapped independently; unmapped categories 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/). -* Personally identifiable information beyond user IDs and email addresses -* Network traffic or external API calls +Self-hosting factory execution changes where commands run, not whether inference is ZDR-covered or where run data is stored. Evaluate [inference and storage separately](/factories/infrastructure-and-security/#provider-retention-and-run-storage). ### 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**. +1. In the Warp app, open **Settings** > **Privacy**. +2. Toggle off **Help improve Warp** to stop analytics and improvement collection. Toggle off **Send crash reports** separately if you don't want to 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. +If a control is managed by your organization, ask an admin to review the [Admin Panel privacy settings](/enterprise/team-management/admin-panel/#privacy-settings). ## Data handling and privacy @@ -71,10 +63,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** - Warp-managed inference uses provider ZDR across plans, with the [model-specific exceptions](/agents/inference/model-choice/#models-requiring-provider-retention). Customer-managed inference uses your provider terms. +* **BYOLLM** - Requests are proxied through Warp's servers to your cloud infrastructure, where inference runs. Your provider's terms govern provider retention; conversation and run storage remain separate. * **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 +88,8 @@ 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 +* **Provider ZDR** - Applies to covered inference, not all models or product storage; see [model retention policies](/agents/inference/model-choice/#zero-data-retention-policies) +* **Product data** - Retention depends on the feature; use the [storage references above](#product-storage) rather than treating provider ZDR as a deletion policy * **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 +123,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](#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 +180,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 +212,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..83257152f 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. +Warp-managed inference has provider Zero Data Retention (ZDR) coverage with [model-specific exceptions](/agents/inference/model-choice/#models-requiring-provider-retention). See the [Security overview](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why) for the separate provider, analytics, and product-storage boundaries. ::: ## 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 47ba35307..833990f40 100644 --- a/src/content/docs/enterprise/team-management/admin-panel.mdx +++ b/src/content/docs/enterprise/team-management/admin-panel.mdx @@ -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,15 @@ 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 is the organization-level control for the collection governed by **Help improve Warp**. It doesn't change [provider retention requirements](/agents/inference/model-choice/#models-requiring-provider-retention) or disable product storage. + +**Cloud conversation storage** + +Controls cloud sync of personal Terminal conversations. Disabling it doesn't disable factory or other cloud agent run storage. Transcripts, prompt attachments, and uploaded artifacts persist independently of analytics preferences; see [product storage](/enterprise/security-and-compliance/security-overview/#product-storage) and [self-hosted agent data storage](/factories/self-hosting/data-storage/). **Enterprise secret redaction** Automatically detects and redacts sensitive information before sending data to LLM providers: @@ -224,7 +228,9 @@ From the **Models** page, admins can also create team-synced [custom routers](/a **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)](/enterprise/security-and-compliance/security-overview/#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 procedure](/factories/factory-agents/configuration/#reviewing-inference-for-provider-zdr). ### Billing settings diff --git a/src/content/docs/factories/factory-agents/configuration.mdx b/src/content/docs/factories/factory-agents/configuration.mdx index 97fbbbcb5..83a72ddab 100644 --- a/src/content/docs/factories/factory-agents/configuration.mdx +++ b/src/content/docs/factories/factory-agents/configuration.mdx @@ -59,6 +59,23 @@ 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. +### Reviewing inference for provider ZDR + +Review every inference choice used by your workflow, not only the foreman's model. Warp-managed inference is covered by provider Zero Data Retention (ZDR) across plans except for the [models requiring provider retention](/agents/inference/model-choice/#models-requiring-provider-retention). Turning off analytics doesn't remove those exceptions. + +For a Warp-managed factory, use the factory dashboard's **Agents** and **Scorers** pages for their settings, and **Factory definition** for defaults and overrides that aren't exposed in those editors. For a GitHub-backed factory, edit the existing files in the connected repository; dashboard settings are read-only. Both use the [Factory definition syntax](/factories/factory-as-code/). + +1. Review the factory default in `factory.yaml`: `agentDefaults.model`, or the model and type under `agentDefaults.harness`. Review each agent's "Harness" and "Model" in **Agents** > the agent's **Settings**, or its existing `agents//agent.md` frontmatter. An agent override can differ from the default. +2. Review **Automations** to identify the target agent for each trigger. In `automations//automation.md`, check [execution overrides](/factories/factory-as-code/#execution-overrides), especially `model` or `harness`. The automation editor doesn't expose execution overrides. +3. Review the separate [Computer Use model](/factories/factory-as-code/#agentdefaultscomputerusemodel): `agentDefaults.computerUseModel` and any agent or automation `computerUseModel` override. An omitted value uses the documented inheritance or automatic selection, not necessarily the primary model. +4. If a selected model is a custom router, inspect every target and its default against the exception list. Review each Scorer's "Judge model" on **Scorers**, or `scorers//scorer.md`. Also review the factory's "Analysis model" for [Self-improvement](/factories/measure-and-improve/self-improvement/). These are separate inference choices from the agent's primary model. +5. Before launching [benchmarks](/factories/benchmarks/#create-and-run-a-benchmark), review every trial's harness and model and the selected Scorers. For runs started through the CLI, API, or another agent, review any supplied model or harness override rather than assuming the saved agent settings apply. +6. Save dashboard changes, including definition edits. For a GitHub-backed factory, merge through your normal review process into its connected production branch and confirm a successful definition sync. Start a new run and inspect its model and harness in **Runs**. Existing runs keep their selected model; a completed test run doesn't prove the provider's contractual retention policy. + +For customer-managed keys or endpoints, BYOLLM, and direct Claude Code or Codex calls, verify ZDR with the provider for the specific account, model, and configuration. Use [factory inference options](/factories/infrastructure-and-security/#inference-options-for-factory-runs) to identify the credential and provider route. + +Auto, fallback, and auxiliary inference aren't an immutable model pin. Recheck configurations when models or workflows change. Provider ZDR and analytics settings don't disable [factory transcript, attachment, or artifact storage](/factories/infrastructure-and-security/#provider-retention-and-run-storage). + ### 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/infrastructure-and-security.mdx b/src/content/docs/factories/infrastructure-and-security.mdx index 386c669bd..be268c571 100644 --- a/src/content/docs/factories/infrastructure-and-security.mdx +++ b/src/content/docs/factories/infrastructure-and-security.mdx @@ -75,6 +75,16 @@ For backend selection guidance, including Command and one-shot Direct options, s Execution hosting doesn't select inference. Configure that boundary separately. +### Provider retention and run storage + +Warp-managed inference in factory runs has the same provider Zero Data Retention (ZDR) coverage as Terminal, across plans, except for the [models requiring provider retention](/agents/inference/model-choice/#models-requiring-provider-retention). **Help improve Warp** controls Warp analytics and improvement collection, not provider retention. Start with the [Warp-wide security guidance](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why) for the distinction. + +Before sending sensitive work, follow [Reviewing inference for provider ZDR](/factories/factory-agents/configuration/#reviewing-inference-for-provider-zdr). The procedure covers dashboard-managed and GitHub-backed factories without requiring Terminal settings. + +Factory transcripts, prompt attachments, and uploaded artifacts persist for viewing past runs even when analytics is off. **Store AI conversations in the cloud** is a personal Terminal setting, not a switch for factory run storage. Run data uses Warp-managed storage unless an Enterprise admin maps the categories through [self-hosted agent data storage](/factories/self-hosting/data-storage/). A sandbox's teardown doesn't delete those stored records. + +Self-hosting execution doesn't establish provider ZDR or move run data automatically. Evaluate the inference route and storage mappings independently. + ### Inference options for factory runs Factory agents execute as cloud agents. For runs using the Warp Agent, support varies by inference option: @@ -86,7 +96,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. For customer-managed keys, endpoints, and BYOLLM, verify ZDR with your provider for the specific account, model, and configuration, including any upstream providers behind a gateway. Warp can't enforce provider ZDR for those requests. + +Claude Code and Codex call their providers directly from the execution environment. Verify retention under the account and configuration used by the harness's authentication, separately from Warp-managed inference. ### Networking for BYO inference endpoints 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..175f86a13 100644 --- a/src/content/docs/factories/self-hosting/security-and-networking.mdx +++ b/src/content/docs/factories/self-hosting/security-and-networking.mdx @@ -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. Warp-managed inference has [provider Zero Data Retention (ZDR) coverage with model-specific exceptions](/agents/inference/model-choice/#zero-data-retention-policies). Turning off analytics doesn't remove provider retention requirements or disable stored run transcripts, attachments, and artifacts. + +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; review [inference and storage boundaries](/factories/infrastructure-and-security/#provider-retention-and-run-storage) independently. 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. --- diff --git a/src/content/docs/platform/architecture.mdx b/src/content/docs/platform/architecture.mdx index 3d05fd887..af8b510ae 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. Provider retention depends on the [model and inference configuration](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr); Claude Code and Codex call their providers directly under your provider terms. 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 Warp-managed inference or your [team-managed keys and endpoints](/enterprise/enterprise-features/team-managed-keys-and-endpoints/) or [BYOLLM](/enterprise/enterprise-features/bring-your-own-llm/) account. [Provider ZDR and its exceptions](/agents/inference/model-choice/#zero-data-retention-policies) apply to Warp-managed inference; verify your own provider account's terms separately. 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 using the [configured inference option](/factories/infrastructure-and-security/#inference-options-for-factory-runs). Self-hosting doesn't establish provider ZDR. 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. @@ -94,8 +94,8 @@ 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. +* **Prompts and context** - The Warp Agent routes model calls through Warp. Warp-managed inference has [provider ZDR coverage with model-specific exceptions](/agents/inference/model-choice/#zero-data-retention-policies). For customer-managed keys, endpoints, BYOLLM, and direct Claude Code or Codex calls, verify ZDR with the provider for the specific account, model, and configuration. +* **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. +Review [provider retention and run storage](/factories/infrastructure-and-security/#provider-retention-and-run-storage) separately from the execution host. Moving compute doesn't change the inference provider's terms or automatically move stored transcripts, attachments, and artifacts. + ![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..7aac480c9 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 @@ -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. Provider Zero Data Retention (ZDR) covers Warp-managed inference across plans, in both Terminal and factory runs, except for the [models requiring provider retention](/agents/inference/model-choice/#models-requiring-provider-retention). For your own keys, endpoints, or direct Claude Code and Codex calls, verify ZDR with the provider for your specific account, model, and configuration. ### 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 settings](/factories/factory-agents/configuration/#reviewing-inference-for-provider-zdr) 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 the [Security overview](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why) 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 16c047343..5c9db54be 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 @@ -24,18 +24,14 @@ 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. -::: +Turning off **Help improve Warp** stops analytics and eligible AI interaction and console-content collection for service improvement, subject to [organization-enforced settings](/enterprise/team-management/admin-panel/#privacy-settings). **Send crash reports** controls crash reporting separately. -:::caution -Business and Enterprise plans are covered by our Zero Data Retention (ZDR) agreement. No AI interaction or console data is ever collected. -::: +Provider Zero Data Retention (ZDR) is separate: it applies to covered Warp-managed inference across plans, with [model-specific exceptions](/agents/inference/model-choice/#models-requiring-provider-retention). Turning off analytics doesn't change a provider's retention requirements. For the Warp-wide distinction between inference, analytics, and storage, start with the [Security overview](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why). 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. @@ -43,12 +39,13 @@ You can read our [full privacy policy](https://www.warp.dev/legal/privacy-policy ### 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 +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. +With analytics off, product data can still persist. Personal Terminal conversations follow the separate [cloud conversation setting](/agents/local-agents/cloud-conversations/). Factory transcripts, prompt attachments, and uploaded artifacts remain available for past runs independently of both settings; see [factory storage boundaries](/factories/infrastructure-and-security/#provider-retention-and-run-storage). Shared sessions follow their own [retention and access rules](/agents/local-agents/session-sharing/#data-retention-and-access). ### Delete your account and data From ea28fdbe8884f3c7f2721ec3727b9f8f88417d2f Mon Sep 17 00:00:00 2001 From: "warp-agent-staging[bot]" <240773466+warp-agent-staging[bot]@users.noreply.github.com> Date: Thu, 12 Nov 2026 02:52:42 +0000 Subject: [PATCH 2/8] docs: clarify training answer and restore BYOK privacy context Address review feedback without restoring universal retention or unsupported BYOK training assurances. Preserve model exceptions and the Engineering/Security publication hold. Co-Authored-By: Oz --- src/content/docs/agents/getting-started/faqs.mdx | 4 +++- .../docs/agents/inference/bring-your-own-api-key.mdx | 6 ++++-- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/src/content/docs/agents/getting-started/faqs.mdx b/src/content/docs/agents/getting-started/faqs.mdx index e5eeb077b..bf8fde2ed 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? -**Help improve Warp** controls analytics and eligible content collection for service improvement. Covered Warp-managed inference isn't used by the provider for training, but some models require provider retention. See the [model exceptions](/agents/inference/model-choice/#models-requiring-provider-retention) and the [separate analytics and storage controls](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why). +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 **Help improve Warp** stops analytics and eligible content collection for service improvement, subject to organization-enforced settings. + +Separately, covered Warp-managed inference isn't used by the provider for training, but some models require provider retention. See the [model exceptions](/agents/inference/model-choice/#models-requiring-provider-retention) and the [separate analytics and storage controls](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why). ### What model are you using for Agent Mode? 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 867b27651..73d7cc859 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,9 +105,11 @@ You can update or replace your keys anytime by opening **Settings** and searchin ### Zero Data Retention (ZDR) and BYOK -Warp's [provider ZDR agreements](/agents/inference/model-choice/#zero-data-retention-policies) apply to covered Warp-managed inference, not requests through your own key. Verify ZDR with your provider for the specific account, model, and configuration; Warp cannot enforce provider ZDR for BYOK. +Warp has a [SOC 2 Type 2 attestation](https://www.warp.dev/legal/security). Warp's [ZDR agreements with contracted LLM providers](/agents/inference/model-choice/#zero-data-retention-policies) apply to covered Warp-managed inference, with [model-specific exceptions](/agents/inference/model-choice/#models-requiring-provider-retention), not requests through your own key. -BYOK prompts and responses transit Warp's backend (see [How BYOK works](#how-byok-works)). Warp analytics and product storage remain separate controls; turning off **Help improve Warp** doesn't change your provider's terms or disable [conversation storage](/enterprise/security-and-compliance/security-overview/#product-storage). +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. + +BYOK prompts and responses transit Warp's backend (see [How BYOK works](#how-byok-works)). Warp-side retention and analytics handling follow the same account-level privacy and telemetry settings as Warp-billed traffic, including organization-enforced settings. Turning off **Help improve Warp** doesn't change your provider's terms or disable [conversation storage](/enterprise/security-and-compliance/security-overview/#product-storage). ### BYOK on Business and Enterprise plans From 46376dc080cd0ec9f8d9fd054cda05e881a228f1 Mon Sep 17 00:00:00 2001 From: "warp-agent-staging[bot]" <240773466+warp-agent-staging[bot]@users.noreply.github.com> Date: Thu, 12 Nov 2026 03:07:18 +0000 Subject: [PATCH 3/8] docs: clarify factory ZDR conditions and browser configuration paths Narrow unconfirmed auxiliary coverage, restore requested BYOK context, and answer training directly. Keep provider-contract and Self-improvement deployment questions explicit in PR evidence. Co-Authored-By: Oz --- .../docs/agents/getting-started/faqs.mdx | 2 +- src/content/docs/agents/index.mdx | 2 +- .../inference/bring-your-own-api-key.mdx | 6 ++- .../docs/agents/inference/model-choice.mdx | 40 ++++++++++++------ .../architecture-and-deployment.mdx | 4 +- src/content/docs/enterprise/index.mdx | 2 +- .../security-overview.mdx | 8 ++-- .../security-and-compliance/trust-center.mdx | 2 +- .../team-management/admin-panel.mdx | 2 +- .../factory-agents/configuration.mdx | 41 ++++++++++++++----- .../factories/infrastructure-and-security.mdx | 31 +++++++++----- .../self-hosting/security-and-networking.mdx | 4 +- src/content/docs/platform/architecture.mdx | 2 +- .../plans-and-billing/pricing-faqs.mdx | 6 +-- .../privacy-and-security/privacy.mdx | 4 +- 15 files changed, 102 insertions(+), 54 deletions(-) diff --git a/src/content/docs/agents/getting-started/faqs.mdx b/src/content/docs/agents/getting-started/faqs.mdx index e5eeb077b..90a1c7ea5 100644 --- a/src/content/docs/agents/getting-started/faqs.mdx +++ b/src/content/docs/agents/getting-started/faqs.mdx @@ -21,7 +21,7 @@ Agent Mode has replaced the previous AI chat panel. Agent Mode is more powerful ### Is my data used for model training? -**Help improve Warp** controls analytics and eligible content collection for service improvement. Covered Warp-managed inference isn't used by the provider for training, but some models require provider retention. See the [model exceptions](/agents/inference/model-choice/#models-requiring-provider-retention) and the [separate analytics and storage controls](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why). +Warp may use eligible data collected with **Help improve Warp** for model training and service improvement. Turning that setting off stops analytics and improvement collection, not storage needed for conversations or factory runs. Providers don't train on prompts and responses covered by Warp's provider ZDR agreements; some models [require provider retention](/agents/inference/model-choice/#models-requiring-provider-retention). See the [Privacy Notice](https://www.warp.dev/legal/privacy-policy) and [separate analytics and storage controls](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why). ### 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 2e0ce490f..aa1e03224 100644 --- a/src/content/docs/agents/index.mdx +++ b/src/content/docs/agents/index.mdx @@ -62,7 +62,7 @@ The {VARS.WARP_AUTOMATION_PLATFORM} tab covers the platform in full. ## Privacy and security -Warp is **SOC 2 compliant**. Warp-managed inference has provider Zero Data Retention coverage with [model-specific exceptions](/agents/inference/model-choice/#models-requiring-provider-retention). [Analytics and product storage](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why) are separate controls; provider ZDR doesn't disable conversation or run storage. +Warp is **SOC 2 compliant**. Review the [provider Zero Data Retention policy](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr), [model exceptions](/agents/inference/model-choice/#models-requiring-provider-retention), and separate analytics and product-storage controls. For factory runs, start with [factory ZDR guidance](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). 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 867b27651..755dd1b31 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,9 +105,11 @@ You can update or replace your keys anytime by opening **Settings** and searchin ### Zero Data Retention (ZDR) and BYOK -Warp's [provider ZDR agreements](/agents/inference/model-choice/#zero-data-retention-policies) apply to covered Warp-managed inference, not requests through your own key. Verify ZDR with your provider for the specific account, model, and configuration; Warp cannot enforce provider ZDR for BYOK. +Warp is **SOC 2 compliant** and has provider Zero Data Retention (ZDR) agreements with its contracted LLM providers for supported Warp-managed inference. Some models [require provider retention](/agents/inference/model-choice/#models-requiring-provider-retention). Warp's agreements don't establish ZDR for requests through your own key. -BYOK prompts and responses transit Warp's backend (see [How BYOK works](#how-byok-works)). Warp analytics and product storage remain separate controls; turning off **Help improve Warp** doesn't change your provider's terms or disable [conversation storage](/enterprise/security-and-compliance/security-overview/#product-storage). +BYOK prompts and responses transit Warp's backend (see [How BYOK works](#how-byok-works)). Warp does not use this content for training. Warp's account-level privacy and telemetry settings still apply; [conversation storage](/enterprise/security-and-compliance/security-overview/#product-storage) is separate from analytics. + +On the provider side, retention depends on your provider account's settings, the model, and the request configuration. Verify ZDR for that specific combination. Warp cannot enforce provider ZDR for your keys. If your provider account doesn't have ZDR enabled, the provider may retain requests under its terms, even when **Help improve Warp** is off. ### BYOK on Business and Enterprise plans diff --git a/src/content/docs/agents/inference/model-choice.mdx b/src/content/docs/agents/inference/model-choice.mdx index cfd39c621..2ca44b727 100644 --- a/src/content/docs/agents/inference/model-choice.mdx +++ b/src/content/docs/agents/inference/model-choice.mdx @@ -8,10 +8,14 @@ description: >- --- import { VARS } from '@data/vars'; -Choose a model for your agents, use Auto for dynamic selection, or define a [custom router](/agents/inference/custom-routers/). Models support reasoning levels and per-profile defaults. +Warp lets you choose from a curated set of large language models to power your agents, or let Warp auto-select the best model for each task. Models from OpenAI, Anthropic, Google, and open source providers are available, with configurable reasoning levels and per-profile defaults. You can also define [custom routers](/agents/inference/custom-routers/) that pick a model for each task using your own logic. ## Available models +Warp lets you choose from a curated set of large language models (LLMs) to power your Agentic Development Environment. + +**Warp supports the following models.** + The `model_id` values shown below can be used when configuring models via the [{VARS.WARP_AUTOMATION_PLATFORM}](/platform/overview/) or [CLI](/agents/cli/oz-cli/). ### Auto models @@ -23,6 +27,8 @@ The `model_id` values shown below can be used when configuring models via the [{ | Auto (Genius) | `auto-genius` | Adapts to task complexity and selects Warp's most capable model when it's worth it. Best for deep debugging, architecture decisions, and `/plan` sessions. | | Auto (Open-weights) | `auto-open` | Routes between the best open-source models available in Warp. Optimizes for low cost and fast speed using open-weights models. | +All Auto models perform well across all agent workflows and are ideal if you prefer Warp to manage model selection dynamically. + #### OpenAI The `low`, `medium`, `high`, `xhigh`, and `max` suffixes select increasing reasoning levels. @@ -105,6 +111,8 @@ To use eligible Grok models without Warp-provided inference charges, connect you #### Hosted models (via [Fireworks AI](https://fireworks.ai)) +Warp also supports leading open source models hosted via Fireworks AI, so you can run them from inside Warp without setting up your own inference infrastructure. + | Model | `model_id` | | --- | --- | | GLM 5.3 | `glm-5.3-fireworks` | @@ -116,13 +124,15 @@ To use eligible Grok models without Warp-provided inference charges, connect you ### How to change models -In the Warp app's prompt input, click the displayed model name and choose a model. The selection persists for future prompts. +You can use the model picker in your prompt input to quickly switch between models. The currently active model appears directly in the input editor.
![Model selector dropdown showing available models with Intelligence, Speed, and Cost benchmarks](../../../../assets/agent-platform/model-selector-dropdown.png)
Model selector in Warp's input.
+To change models, click the displayed model name (for example, _Claude Sonnet 5_) to open a dropdown with all supported options. Your selection will automatically persist for future prompts. + ### Custom routers Beyond the built-in Auto models, you can define your own custom routers that automatically route each task to a concrete model based on task complexity or rules you write. Custom routers appear in the model picker alongside Auto and individual models. @@ -131,7 +141,13 @@ Add and manage custom routers in **Settings** > **Agents** > **Warp Agent** > ** ### Model fallback -If your selected model is unavailable, Warp uses a fallback from a predefined chain with comparable quality and capabilities. Warp switches back when the selected model becomes available. +Warp uses a model fallback system to ensure uninterrupted service if your selected model becomes temporarily unavailable due to provider outages or capacity issues. + +**How it works:** + +* If your selected model isn't available, Warp automatically uses a fallback model from a predefined chain to continue your conversation without errors. +* As soon as your originally selected model becomes available again, Warp automatically switches back to it. +* The fallback model is selected to provide comparable quality and capabilities to your original choice. ### Configuring models per Agent Profile @@ -141,20 +157,20 @@ Edit your default profile or any other profile directly in **Settings** > **Agen ### Reviewing inference and privacy in Terminal -To use inference covered by provider ZDR, review the model and its inference source before sending sensitive content: +Before sending sensitive content: -1. In the Warp app's prompt input, click the current model name. Choose a Warp-managed model that isn't in the [provider-retention exception list](#models-requiring-provider-retention). If you use Auto, review [automatic selection and fallback](#zero-data-retention-policies); Auto isn't a pinned model. -2. In the Warp app, open **Settings** > **Agents** > **Profiles** and review the active profile's base model. If you use a [custom router](/agents/inference/custom-routers/), review every target and its default model, not only the router's name. -3. In **Settings** > **Agents** > **Warp Agent**, review personal keys, endpoints, and connected subscriptions, and check any [team-managed configuration](/enterprise/enterprise-features/team-managed-keys-and-endpoints/). Search Settings for `API keys` to find personal inference controls. For customer-managed inference, verify provider ZDR for the specific account, model, and configuration. Review [BYOK fallback](/agents/inference/bring-your-own-api-key/#failover-and-fallback-behavior) if enabled. -4. In **Settings** > **Privacy**, toggle off **Help improve Warp** if you don't want analytics and improvement collection. Review **Send crash reports** and **Store AI conversations in the cloud** separately. The storage toggle controls [personal Terminal conversation sync](/agents/local-agents/cloud-conversations/), not factory run storage. +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](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why). -Before sending the next prompt, confirm the intended model is displayed in the input. Recheck these choices when switching profiles, models, or inference providers. For cloud factory runs, use the [factory review procedure](/factories/factory-agents/configuration/#reviewing-inference-for-provider-zdr) instead. +Confirm the model displayed before your next prompt. For factories, use [factory ZDR guidance](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) instead. ### Zero data retention policies -Warp's provider Zero Data Retention (ZDR) agreements cover Warp-managed inference on all plans, in both Terminal and factory runs, except for the models listed below. Provider ZDR concerns prompts and responses at the inference provider; it doesn't disable [Warp analytics or product storage](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why). +Warp has provider Zero Data Retention (ZDR) agreements for supported Warp-managed models on all plans. The [Security overview](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) explains the policy. -Auto selects models dynamically, and [fallback](#model-fallback) can change the model serving a request. A primary model selection isn't a complete inventory of auxiliary inference, such as Computer Use or Scorers. Review the applicable [factory configuration](/factories/factory-agents/configuration/#reviewing-inference-for-provider-zdr) as well. +Current Auto selections and fallback chains for other models don't introduce these exceptions. Routes can change, and a primary model selection doesn't control every auxiliary request. For Computer Use, Scorers, Self-improvement, and the limits of confirmed factory coverage, use [factory ZDR guidance](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). #### Models requiring provider retention @@ -164,6 +180,6 @@ Anthropic requires retention for these models, including their effort variants, * Claude Fable 5.1 * Claude Fable 5.2 -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). Don't rely on Enterprise defaults as a self-serve model restriction. +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). For your own keys, endpoints, subscriptions, or direct Claude Code and Codex calls, verify ZDR with the provider for your specific account, model, and configuration rather than applying Warp's agreements to that traffic. 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 69709b123..36550ea09 100644 --- a/src/content/docs/enterprise/enterprise-features/architecture-and-deployment.mdx +++ b/src/content/docs/enterprise/enterprise-features/architecture-and-deployment.mdx @@ -53,7 +53,7 @@ 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 permit Warp-hosted compute after a separate review of [inference and storage](/factories/infrastructure-and-security/#provider-retention-and-run-storage). +* Your security requirements permit Warp-hosted compute after a separate review of [inference and storage](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). ## Self-hosted execution @@ -68,7 +68,7 @@ Self-hosted execution is available exclusively on Warp's **Enterprise** plan. Self-hosted deployments use a split architecture: * **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 routes Warp Agent inference. Provider retention and product storage are [separate from execution hosting](/factories/infrastructure-and-security/#provider-retention-and-run-storage). +* **Control plane (Warp-hosted)** - Warp coordinates runs and routes Warp Agent inference. Provider retention and product storage are [separate from execution hosting](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). ### Deployment modes diff --git a/src/content/docs/enterprise/index.mdx b/src/content/docs/enterprise/index.mdx index ed3f1c6c7..f7bd95eb7 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 -* **Provider Zero Data Retention (ZDR)** - Covers Warp-managed inference with [model-specific exceptions](/agents/inference/model-choice/#models-requiring-provider-retention), separately from analytics and product storage +* **Provider Zero Data Retention (ZDR)** - See the [provider policy and storage boundaries](/enterprise/security-and-compliance/security-overview/#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 fd3ec9826..92607033c 100644 --- a/src/content/docs/enterprise/security-and-compliance/security-overview.mdx +++ b/src/content/docs/enterprise/security-and-compliance/security-overview.mdx @@ -22,13 +22,13 @@ Warp's security philosophy centers on **transparency and developer control**: ### Zero Data Retention (ZDR) -Provider Zero Data Retention (ZDR) governs whether an inference provider retains prompts and responses. Warp's provider ZDR agreements cover Warp-managed inference across all plans, in both Terminal and factory runs, except for the [models that require provider retention](/agents/inference/model-choice/#models-requiring-provider-retention). Covered inference isn't used by the provider for model training. +Provider Zero Data Retention (ZDR) governs whether an inference provider retains prompts and responses. Warp has provider ZDR agreements for supported Warp-managed models across all plans. Covered providers 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 every known model exception. For example, turning off **Help improve Warp** doesn't make a retention-required model ZDR-covered. Check the complete exception list on the model-choice page before choosing a model. 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/), verify ZDR with your provider for the specific account, model, and configuration. Warp's agreements don't establish ZDR for customer-managed inference. Claude Code and Codex calls made directly to their providers also use your provider terms, not Warp's. -Review [Terminal model and privacy settings](/agents/inference/model-choice/#reviewing-inference-and-privacy-in-terminal) or [factory inference settings](/factories/factory-agents/configuration/#reviewing-inference-for-provider-zdr) for the product you use. Factory users don't need to configure Terminal to review factory inference. +Review [Terminal model and privacy settings](/agents/inference/model-choice/#reviewing-inference-and-privacy-in-terminal) for local use. For factory defaults, manual controls on self-serve plans, and limits on confirmed coverage for auxiliary requests, use [factory ZDR guidance](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). A selected model alone doesn't establish coverage for every request. ### Warp analytics and improvement collection @@ -44,7 +44,7 @@ Product features store data independently of provider ZDR and analytics preferen * **Factory run data** - Transcripts, prompt attachments, and uploaded artifacts persist so you can inspect past runs. They use Warp-managed storage unless an Enterprise admin configures [self-hosted agent data storage](/factories/self-hosting/data-storage/). Categories are mapped independently; unmapped categories 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 whether inference is ZDR-covered or where run data is stored. Evaluate [inference and storage separately](/factories/infrastructure-and-security/#provider-retention-and-run-storage). +Self-hosting factory execution changes where commands run, not whether inference is ZDR-covered or where run data is stored. Evaluate [inference and storage separately](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). ### Disabling telemetry @@ -63,7 +63,7 @@ If a control is managed by your organization, ask an admin to review the [Admin * **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-managed inference uses provider ZDR across plans, with the [model-specific exceptions](/agents/inference/model-choice/#models-requiring-provider-retention). Customer-managed inference uses your provider terms. +* **Agent requests** - Provider retention depends on the model and inference configuration described [above](#zero-data-retention-zdr). * **BYOLLM** - Requests are proxied through Warp's servers to your cloud infrastructure, where inference runs. Your provider's terms govern provider retention; conversation and run storage remain separate. * **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 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/). 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 83257152f..6ee234c56 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-managed inference has provider Zero Data Retention (ZDR) coverage with [model-specific exceptions](/agents/inference/model-choice/#models-requiring-provider-retention). See the [Security overview](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why) for the separate provider, analytics, and product-storage boundaries. +See the [Security overview](/enterprise/security-and-compliance/security-overview/#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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) 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 833990f40..5fab9882d 100644 --- a/src/content/docs/enterprise/team-management/admin-panel.mdx +++ b/src/content/docs/enterprise/team-management/admin-panel.mdx @@ -230,7 +230,7 @@ From the **Models** page, admins can also create team-synced [custom routers](/a Some models require provider retention and aren't covered by [Zero Data Retention (ZDR)](/enterprise/security-and-compliance/security-overview/#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 procedure](/factories/factory-agents/configuration/#reviewing-inference-for-provider-zdr). +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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). ### Billing settings diff --git a/src/content/docs/factories/factory-agents/configuration.mdx b/src/content/docs/factories/factory-agents/configuration.mdx index 83a72ddab..dc4496326 100644 --- a/src/content/docs/factories/factory-agents/configuration.mdx +++ b/src/content/docs/factories/factory-agents/configuration.mdx @@ -59,22 +59,41 @@ 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. -### Reviewing inference for provider ZDR +## Reviewing inference for provider ZDR -Review every inference choice used by your workflow, not only the foreman's model. Warp-managed inference is covered by provider Zero Data Retention (ZDR) across plans except for the [models requiring provider retention](/agents/inference/model-choice/#models-requiring-provider-retention). Turning off analytics doesn't remove those exceptions. +Start with [factory ZDR coverage and its limits](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). The procedures below remove known model exceptions from settings you control; they don't certify coverage for every auxiliary request. Both work in a browser without Warp Terminal. -For a Warp-managed factory, use the factory dashboard's **Agents** and **Scorers** pages for their settings, and **Factory definition** for defaults and overrides that aren't exposed in those editors. For a GitHub-backed factory, edit the existing files in the connected repository; dashboard settings are read-only. Both use the [Factory definition syntax](/factories/factory-as-code/). +Before using Self-improvement with sensitive run data, ask Warp to confirm its separate analysis model and provider coverage. It doesn't inherit the foreman's model. -1. Review the factory default in `factory.yaml`: `agentDefaults.model`, or the model and type under `agentDefaults.harness`. Review each agent's "Harness" and "Model" in **Agents** > the agent's **Settings**, or its existing `agents//agent.md` frontmatter. An agent override can differ from the default. -2. Review **Automations** to identify the target agent for each trigger. In `automations//automation.md`, check [execution overrides](/factories/factory-as-code/#execution-overrides), especially `model` or `harness`. The automation editor doesn't expose execution overrides. -3. Review the separate [Computer Use model](/factories/factory-as-code/#agentdefaultscomputerusemodel): `agentDefaults.computerUseModel` and any agent or automation `computerUseModel` override. An omitted value uses the documented inheritance or automatic selection, not necessarily the primary model. -4. If a selected model is a custom router, inspect every target and its default against the exception list. Review each Scorer's "Judge model" on **Scorers**, or `scorers//scorer.md`. Also review the factory's "Analysis model" for [Self-improvement](/factories/measure-and-improve/self-improvement/). These are separate inference choices from the agent's primary model. -5. Before launching [benchmarks](/factories/benchmarks/#create-and-run-a-benchmark), review every trial's harness and model and the selected Scorers. For runs started through the CLI, API, or another agent, review any supplied model or harness override rather than assuming the saved agent settings apply. -6. Save dashboard changes, including definition edits. For a GitHub-backed factory, merge through your normal review process into its connected production branch and confirm a successful definition sync. Start a new run and inspect its model and harness in **Runs**. Existing runs keep their selected model; a completed test run doesn't prove the provider's contractual retention policy. +### Reviewing a dashboard-managed factory -For customer-managed keys or endpoints, BYOLLM, and direct Claude Code or Codex calls, verify ZDR with the provider for the specific account, model, and configuration. Use [factory inference options](/factories/infrastructure-and-security/#inference-options-for-factory-runs) to identify the credential and provider route. +For a Warp-managed definition, you need the [editing access listed above](#prerequisites). Use the [model exception list](/agents/inference/model-choice/#models-requiring-provider-retention) when making each selection. -Auto, fallback, and auxiliary inference aren't an immutable model pin. Recheck configurations when models or workflows change. Provider ZDR and analytics settings don't disable [factory transcript, attachment, or artifact storage](/factories/infrastructure-and-security/#provider-retention-and-run-storage). +1. Open the {VARS.FACTORY_WEB_APP} and expand your factory in the sidebar. In **Agents**, open each agent's **Settings**. In the "Harness" and "Model" dropdowns, choose the Warp Agent and a model outside the exception list. Click **Save** for each changed agent. +2. In the factory's **Factory definition** tab, open `factory.yaml`. Set `agentDefaults.model`, or the model under `agentDefaults.harness`, outside the exception list. Don't keep both `model` and `harness`. This default applies where an agent doesn't override it; see [model and harness syntax](/factories/factory-as-code/#agentdefaultsmodel). +3. In **Factory definition**, review each `automations//automation.md`. Change any `model` or `harness` [execution override](/factories/factory-as-code/#execution-overrides) that selects an exception. The **Automations** editor doesn't expose these overrides. +4. In **Factory definition**, review `agentDefaults.computerUseModel` and any `computerUseModel` in agent or automation files. Remove listed exceptions from these choices too. Omitted values inherit or use automatic selection; see [Computer Use model inheritance](/factories/factory-as-code/#agentdefaultscomputerusemodel). +5. In **Scorers**, open each Scorer and review its "Judge model." Change any exception and save. If an agent selects a custom router, review every router target and its default model, not only the router's name. +6. Save the definition changes. Before starting work, complete [the run-level checks below](#checking-new-runs). + +### Reviewing a GitHub-backed factory + +You need permission to propose and merge definition changes in the connected GitHub repository. Dashboard editors are read-only for a GitHub-backed factory. + +1. Open the {VARS.FACTORY_WEB_APP}, expand your factory, and open **Settings**. Follow its repository link to the connected definition. In GitHub, open the existing `factory.yaml` and create a branch for your edits. +2. In `factory.yaml`, set `agentDefaults.model`, or the model under `agentDefaults.harness`, outside the [model exception list](/agents/inference/model-choice/#models-requiring-provider-retention). Use the Warp Agent harness (`type: oz`) for Warp-managed inference. Don't keep both `model` and `harness`. +3. Edit each existing `agents//agent.md` and `automations//automation.md`. Replace exception models in their frontmatter's `model` or `harness` settings. Agent overrides replace the factory default; [automation overrides](/factories/factory-as-code/#execution-overrides) can replace the selected agent's settings. +4. Review `agentDefaults.computerUseModel` in `factory.yaml` and `computerUseModel` in agent and automation files. Remove listed exceptions from these separate choices. Check [inheritance and automatic selection](/factories/factory-as-code/#agentdefaultscomputerusemodel) when a value is omitted. +5. Review the `model` in each `scorers//scorer.md`. Replace exceptions there too. If any selection uses a custom router, inspect every target and its default model in the connected router definition. +6. Open a pull request in GitHub, pass the [factory-definition checks](/factories/factory-as-code/#pull-request-checks), and merge through your normal review process into the factory's connected production branch. Confirm the definition synced successfully before starting a new run. + +### Checking new runs + +Team-managed keys can change whose provider account serves a named model. Review the [inference options and credentials](/factories/infrastructure-and-security/#inference-options-for-factory-runs), even when a model's name hasn't changed. For your own keys or endpoints, BYOLLM, or direct Claude Code or Codex calls, verify provider retention for the specific account, model, and configuration. + +Before launching a [benchmark](/factories/benchmarks/#create-and-run-a-benchmark), check every trial's harness, model, and selected Scorers. For runs started by an API, CLI, or another agent, check supplied model or harness overrides too. + +Start a new run with non-sensitive test input. In the factory dashboard's **Runs**, open the run and inspect its model and harness. Check child runs separately. Existing runs keep their selected model. This confirms the visible configuration, not the provider contract or every auxiliary call. Recheck when models, credentials, or workflows change. ### Configuring a third-party harness diff --git a/src/content/docs/factories/infrastructure-and-security.mdx b/src/content/docs/factories/infrastructure-and-security.mdx index be268c571..a5911ed79 100644 --- a/src/content/docs/factories/infrastructure-and-security.mdx +++ b/src/content/docs/factories/infrastructure-and-security.mdx @@ -9,6 +9,27 @@ sidebar: Warp Factories separates execution, inference, and credential boundaries. You choose where code runs, which providers serve inference, and which credentials each agent receives. Warp coordinates the work. Transcripts and artifacts use Warp-managed storage unless you configure [self-hosted agent data storage](/factories/self-hosting/data-storage/). +## Zero Data Retention (ZDR) for factory inference + +Warp provides provider Zero Data Retention (ZDR) for supported Warp-managed models by default on every plan. The model you choose and the provider account serving the request affect that coverage. On self-serve plans, you can change factory models and overrides manually, but you don't have a team-wide control that blocks models requiring retention. + +Avoiding Claude Fable 5, 5.1, and 5.2 removes the [known model exceptions](/agents/inference/model-choice/#models-requiring-provider-retention), including their effort variants. This requires avoiding them in every agent, automation, Computer Use, Scorer, and run-level override, not only the foreman's model. If you use your own provider account or a third-party harness, avoiding those models doesn't establish ZDR: verify retention for that account, model, and configuration. + +Current Auto selections, fallback chains for other models, and automatic Computer Use selection don't introduce the listed Fable models. Auto and fallback can change over time; selecting a model isn't a permanent pin for every request. Coverage of every auxiliary inference path hasn't been confirmed. If your policy requires every inference request to have provider ZDR, ask Warp to confirm the routing and provider coverage for your configuration before sending sensitive work. Avoiding Fable alone isn't that confirmation. + +Review and save your configuration without installing Warp Terminal: + +* [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). + +Business supports shared provider keys and endpoints, but that isn't a team-wide model restriction. Enterprise has separate [model restrictions in the Admin Panel](/enterprise/team-management/admin-panel/#models-settings). + +### Provider retention, Warp analytics, and run storage + +Provider ZDR covers prompts and responses at the inference provider. **Help improve Warp** controls Warp's analytics and improvement collection, not provider retention. See the [Security overview](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why) for Warp-wide policy and [Agent model choice](/agents/inference/model-choice/#models-requiring-provider-retention) for the complete model exception list. + +Warp stores factory transcripts, prompt attachments, and uploaded artifacts so you can revisit runs, even with analytics off. **Store AI conversations in the cloud** controls personal Terminal conversation sync, not factory run storage. An Enterprise admin can map run-data categories to [self-hosted agent data storage](/factories/self-hosting/data-storage/); unmapped categories remain with Warp. Destroying a sandbox doesn't delete these records. + ## Control plane and execution plane Warp manages coordination, while a Warp-hosted sandbox or a worker on your infrastructure executes the work. These responsibilities form the control plane and execution plane: @@ -75,16 +96,6 @@ For backend selection guidance, including Command and one-shot Direct options, s Execution hosting doesn't select inference. Configure that boundary separately. -### Provider retention and run storage - -Warp-managed inference in factory runs has the same provider Zero Data Retention (ZDR) coverage as Terminal, across plans, except for the [models requiring provider retention](/agents/inference/model-choice/#models-requiring-provider-retention). **Help improve Warp** controls Warp analytics and improvement collection, not provider retention. Start with the [Warp-wide security guidance](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why) for the distinction. - -Before sending sensitive work, follow [Reviewing inference for provider ZDR](/factories/factory-agents/configuration/#reviewing-inference-for-provider-zdr). The procedure covers dashboard-managed and GitHub-backed factories without requiring Terminal settings. - -Factory transcripts, prompt attachments, and uploaded artifacts persist for viewing past runs even when analytics is off. **Store AI conversations in the cloud** is a personal Terminal setting, not a switch for factory run storage. Run data uses Warp-managed storage unless an Enterprise admin maps the categories through [self-hosted agent data storage](/factories/self-hosting/data-storage/). A sandbox's teardown doesn't delete those stored records. - -Self-hosting execution doesn't establish provider ZDR or move run data automatically. Evaluate the inference route and storage mappings independently. - ### Inference options for factory runs Factory agents execute as cloud agents. For runs using the Warp Agent, support varies by inference option: 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 175f86a13..6836d3cdd 100644 --- a/src/content/docs/factories/self-hosting/security-and-networking.mdx +++ b/src/content/docs/factories/self-hosting/security-and-networking.mdx @@ -117,9 +117,9 @@ See [GitLab](/platform/integrations/gitlab/) and [Bitbucket](/platform/integrati ## LLM inference and BYOLLM -The Warp Agent sends inference requests through Warp. Warp-managed inference has [provider Zero Data Retention (ZDR) coverage with model-specific exceptions](/agents/inference/model-choice/#zero-data-retention-policies). Turning off analytics doesn't remove provider retention requirements or disable stored run transcripts, attachments, and artifacts. +The Warp Agent sends inference requests through Warp. Review [factory ZDR coverage and configuration](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) 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; review [inference and storage boundaries](/factories/infrastructure-and-security/#provider-retention-and-run-storage) independently. +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). diff --git a/src/content/docs/platform/architecture.mdx b/src/content/docs/platform/architecture.mdx index af8b510ae..c762cd538 100644 --- a/src/content/docs/platform/architecture.mdx +++ b/src/content/docs/platform/architecture.mdx @@ -106,7 +106,7 @@ 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. -Review [provider retention and run storage](/factories/infrastructure-and-security/#provider-retention-and-run-storage) separately from the execution host. Moving compute doesn't change the inference provider's terms or automatically move stored transcripts, attachments, and artifacts. +Review [provider retention and run storage](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) separately from the execution host. Moving compute doesn't change the inference provider's terms or automatically move stored transcripts, attachments, and artifacts. ![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) 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 7aac480c9..cca743b0f 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 security policy](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) and [factory ZDR guidance](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) for coverage, exceptions, and what self-serve teams can configure. ### What counts as a team member and how does billing work for members? @@ -242,11 +242,11 @@ 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? -Yes. Provider Zero Data Retention (ZDR) covers Warp-managed inference across plans, in both Terminal and factory runs, except for the [models requiring provider retention](/agents/inference/model-choice/#models-requiring-provider-retention). For your own keys, endpoints, or direct Claude Code and Codex calls, verify ZDR with the provider for your specific account, model, and configuration. +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 the [Security overview](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) for the policy, including customer-managed inference. ### How can I enable Zero Data Retention in Warp? -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 settings](/factories/factory-agents/configuration/#reviewing-inference-for-provider-zdr) for your workflow. +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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) for your workflow. **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 the [Security overview](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why) to review these three separate controls. 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 5c9db54be..2558f2fad 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 @@ -31,7 +31,7 @@ If you haven't opted out of **Help improve Warp**, Warp may collect: Turning off **Help improve Warp** stops analytics and eligible AI interaction and console-content collection for service improvement, subject to [organization-enforced settings](/enterprise/team-management/admin-panel/#privacy-settings). **Send crash reports** controls crash reporting separately. -Provider Zero Data Retention (ZDR) is separate: it applies to covered Warp-managed inference across plans, with [model-specific exceptions](/agents/inference/model-choice/#models-requiring-provider-retention). Turning off analytics doesn't change a provider's retention requirements. For the Warp-wide distinction between inference, analytics, and storage, start with the [Security overview](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why). +Turning off analytics doesn't change a provider's retention requirements. See the [Security overview](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why) for the separate provider ZDR, analytics, and storage policies, or [factory ZDR guidance](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) for factory configuration. 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. @@ -45,7 +45,7 @@ You can read our [full privacy policy](https://www.warp.dev/legal/privacy-policy ![Privacy Settings](../../../../assets/support-and-community/privacy-settings-after-signup-1.png) -With analytics off, product data can still persist. Personal Terminal conversations follow the separate [cloud conversation setting](/agents/local-agents/cloud-conversations/). Factory transcripts, prompt attachments, and uploaded artifacts remain available for past runs independently of both settings; see [factory storage boundaries](/factories/infrastructure-and-security/#provider-retention-and-run-storage). Shared sessions follow their own [retention and access rules](/agents/local-agents/session-sharing/#data-retention-and-access). +With analytics off, product data can still persist. Personal Terminal conversations follow the separate [cloud conversation setting](/agents/local-agents/cloud-conversations/). Factory transcripts, prompt attachments, and uploaded artifacts remain available for past runs independently of both settings; see [factory storage boundaries](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). Shared sessions follow their own [retention and access rules](/agents/local-agents/session-sharing/#data-retention-and-access). ### Delete your account and data From e3184261bff6509b7224798cee7aa8f5f0781afa Mon Sep 17 00:00:00 2001 From: Rachael Rose Renk <91027132+rachaelrenk@users.noreply.github.com> Date: Fri, 13 Nov 2026 12:50:42 -0700 Subject: [PATCH 4/8] docs: clarify factory ZDR setup and consolidate policy guidance Organize the factory entry point around provider coverage, collection and storage, and plan controls. Restructure browser procedures around defaults, applicable overrides, and fresh-run checks while preserving policy qualifications and canonical anchors. Co-Authored-By: Warp --- .../inference/bring-your-own-api-key.mdx | 4 +- .../inference/custom-inference-endpoint.mdx | 6 +- .../docs/agents/inference/model-choice.mdx | 4 +- .../architecture-and-deployment.mdx | 10 ++-- .../team-managed-keys-and-endpoints.mdx | 4 +- .../security-overview.mdx | 22 +++----- .../team-management/admin-panel.mdx | 2 +- .../factory-agents/configuration.mdx | 55 ++++++++++++------- .../factories/infrastructure-and-security.mdx | 33 +++++++---- src/content/docs/platform/architecture.mdx | 12 ++-- .../privacy-and-security/privacy.mdx | 4 +- 11 files changed, 86 insertions(+), 70 deletions(-) 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 73d7cc859..5ad1aa837 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,11 +105,11 @@ You can update or replace your keys anytime by opening **Settings** and searchin ### Zero Data Retention (ZDR) and BYOK -Warp has a [SOC 2 Type 2 attestation](https://www.warp.dev/legal/security). Warp's [ZDR agreements with contracted LLM providers](/agents/inference/model-choice/#zero-data-retention-policies) apply to covered Warp-managed inference, with [model-specific exceptions](/agents/inference/model-choice/#models-requiring-provider-retention), not requests through your own key. +Warp has a [SOC 2 Type 2 attestation](https://www.warp.dev/legal/security). Its [provider ZDR policy](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) covers supported Warp-managed inference, not requests through your own key. 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. -BYOK prompts and responses transit Warp's backend (see [How BYOK works](#how-byok-works)). Warp-side retention and analytics handling follow the same account-level privacy and telemetry settings as Warp-billed traffic, including organization-enforced settings. Turning off **Help improve Warp** doesn't change your provider's terms or disable [conversation storage](/enterprise/security-and-compliance/security-overview/#product-storage). +BYOK prompts and responses [transit Warp's backend](#how-byok-works). Warp applies the same account-level privacy settings as for Warp-billed traffic, including organization-enforced settings. Review [analytics and conversation storage](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why) separately from provider retention. ### 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 0302bef33..863f8d137 100644 --- a/src/content/docs/agents/inference/custom-inference-endpoint.mdx +++ b/src/content/docs/agents/inference/custom-inference-endpoint.mdx @@ -83,11 +83,9 @@ Other features use their own inference configuration and are unaffected by a per ## Zero Data Retention (ZDR) -Warp's [provider ZDR agreements](/agents/inference/model-choice/#zero-data-retention-policies) don't establish ZDR for your endpoint. Verify ZDR with the endpoint provider and any upstream model providers for the specific account, model, and configuration. +Warp cannot enforce provider ZDR for your endpoint. Verify retention with the endpoint provider and any upstream model providers for the specific account, model, and configuration; their terms apply to those requests. -Custom inference endpoint prompts and responses transit Warp's backend (see [How it works](#how-it-works)). Turning off **Help improve Warp** stops analytics and improvement collection, not provider retention or [product storage](/enterprise/security-and-compliance/security-overview/#product-storage). - -Warp cannot enforce provider ZDR for a custom endpoint. Without provider ZDR, requests may be retained according to the endpoint and upstream providers' terms. +Prompts and responses still [transit Warp's backend](#how-it-works). Review [Warp's separate analytics and storage controls](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why); they 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 2ca44b727..39023d663 100644 --- a/src/content/docs/agents/inference/model-choice.mdx +++ b/src/content/docs/agents/inference/model-choice.mdx @@ -170,7 +170,7 @@ Confirm the model displayed before your next prompt. For factories, use [factory Warp has provider Zero Data Retention (ZDR) agreements for supported Warp-managed models on all plans. The [Security overview](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) explains the policy. -Current Auto selections and fallback chains for other models don't introduce these exceptions. Routes can change, and a primary model selection doesn't control every auxiliary request. For Computer Use, Scorers, Self-improvement, and the limits of confirmed factory coverage, use [factory ZDR guidance](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). +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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). #### Models requiring provider retention @@ -182,4 +182,4 @@ Anthropic requires retention for these models, including their effort variants, 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). -For your own keys, endpoints, subscriptions, or direct Claude Code and Codex calls, verify ZDR with the provider for your specific account, model, and configuration rather than applying Warp's agreements to that traffic. +For your own provider account, [verify retention with your provider](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr); selecting a model outside this list doesn't establish ZDR for that account. 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 36550ea09..2e5c14034 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. -* Warp-managed inference has [provider Zero Data Retention (ZDR) coverage with model-specific exceptions](/agents/inference/model-choice/#zero-data-retention-policies). Customer-managed inference uses your provider terms. +* Provider retention follows the [model and provider-account configuration](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr), not the execution host. * 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) @@ -68,7 +68,7 @@ Self-hosted execution is available exclusively on Warp's **Enterprise** plan. Self-hosted deployments use a split architecture: * **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 routes Warp Agent inference. Provider retention and product storage are [separate from execution hosting](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). +* **Control plane (Warp-hosted)** - Warp coordinates runs and routes Warp Agent inference. See [What transits Warp's servers](#what-transits-warps-servers) for the data it receives. ### Deployment modes @@ -130,8 +130,8 @@ Understanding what data stays where is critical for security and compliance deci * **Task orchestration** - Scheduling, routing, and lifecycle management * **Observability data** - Run status, duration, and metadata -* **LLM inference** - The Warp Agent routes prompts and responses through Warp to the configured provider. Verify [provider ZDR coverage and exceptions](/agents/inference/model-choice/#zero-data-retention-policies) separately. Claude Code and Codex call their providers directly. -* **Run data** - Transcripts, prompt attachments, and uploaded artifacts persist independently of analytics preferences and personal Terminal sync settings. [Self-hosted agent data storage](/factories/self-hosting/data-storage/) changes storage mappings separately from compute. +* **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 persist independently of the execution workspace. Configure their location 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,7 +142,7 @@ Consider the following when selecting a deployment model: **Warp-hosted** is right if: * You want zero infrastructure management for agent execution. -* Your security team has reviewed Warp-hosted compute, inference, and product storage as separate boundaries. +* Your security requirements permit Warp-hosted compute. * You need maximum parallelization and scalability. **Self-hosted** is right if: 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 fd2de7317..067bb84f0 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,9 +108,9 @@ Warp uses the stored credentials to call your provider without delivering them t ### Zero Data Retention (ZDR) -Warp's [provider ZDR agreements](/agents/inference/model-choice/#zero-data-retention-policies) don't establish ZDR for requests through your team's keys or endpoints. Verify ZDR with the provider for the specific account, model, and configuration, including upstream providers behind a gateway. Warp cannot enforce provider ZDR for these requests; without it, requests may be retained according to your providers' terms. +Your provider's terms govern requests through your team's keys or endpoints, not Warp's ZDR agreements. Verify retention for the specific account, model, and configuration, including upstream providers behind a gateway. Warp cannot enforce provider ZDR for these requests. -Warp analytics and [product storage](/enterprise/security-and-compliance/security-overview/#product-storage) remain separate. Disabling UGC collection doesn't change provider retention or disable factory transcripts, prompt attachments, and uploaded artifacts. +Disabling UGC collection doesn't disable run storage. See the [separate analytics and storage controls](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why) or [factory ZDR guidance](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). 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 92607033c..827a6169c 100644 --- a/src/content/docs/enterprise/security-and-compliance/security-overview.mdx +++ b/src/content/docs/enterprise/security-and-compliance/security-overview.mdx @@ -18,17 +18,19 @@ 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? + + +## Provider retention, analytics, and storage ### Zero Data Retention (ZDR) Provider Zero Data Retention (ZDR) governs whether an inference provider retains prompts and responses. Warp has provider ZDR agreements for supported Warp-managed models across all plans. Covered providers 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 every known model exception. -For example, turning off **Help improve Warp** doesn't make a retention-required model ZDR-covered. Check the complete exception list on the model-choice page before choosing a model. +Warp-managed inference uses Warp's provider account, not your own. Turning off **Help improve Warp** doesn't make a retention-required model ZDR-covered. 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/), verify ZDR with your provider for the specific account, model, and configuration. Warp's agreements don't establish ZDR for customer-managed inference. Claude Code and Codex calls made directly to their providers also use your provider terms, not Warp's. -Review [Terminal model and privacy settings](/agents/inference/model-choice/#reviewing-inference-and-privacy-in-terminal) for local use. For factory defaults, manual controls on self-serve plans, and limits on confirmed coverage for auxiliary requests, use [factory ZDR guidance](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). A selected model alone doesn't establish coverage for every request. +Follow the [Terminal procedure](/agents/inference/model-choice/#reviewing-inference-and-privacy-in-terminal) or [factory ZDR guidance](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) for configuration steps, plan controls, and coverage limits. ### Warp analytics and improvement collection @@ -48,14 +50,7 @@ Self-hosting factory execution changes where commands run, not whether inference ### Disabling telemetry -Users can opt out of telemetry individually: - -1. In the Warp app, open **Settings** > **Privacy**. -2. Toggle off **Help improve Warp** to stop analytics and improvement collection. Toggle off **Send crash reports** separately if you don't want to send crash reports. - -With telemetry disabled, Warp stops collecting usage and interaction data for analytics purposes. - -If a control is managed by your organization, ask an admin to review the [Admin Panel privacy settings](/enterprise/team-management/admin-panel/#privacy-settings). +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 @@ -64,7 +59,7 @@ If a control is managed by your organization, ask an admin to review the [Admin * **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** - Provider retention depends on the model and inference configuration described [above](#zero-data-retention-zdr). -* **BYOLLM** - Requests are proxied through Warp's servers to your cloud infrastructure, where inference runs. Your provider's terms govern provider retention; conversation and run storage remain separate. +* **BYOLLM** - Requests are proxied through Warp's servers to your cloud infrastructure, where inference runs. See [customer-managed inference](#zero-data-retention-zdr) for retention. * **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 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/). @@ -88,8 +83,7 @@ See [Secret Redaction documentation](/support-and-community/privacy-and-security ### Data retention -* **Provider ZDR** - Applies to covered inference, not all models or product storage; see [model retention policies](/agents/inference/model-choice/#zero-data-retention-policies) -* **Product data** - Retention depends on the feature; use the [storage references above](#product-storage) rather than treating provider ZDR as a deletion policy +* **Inference and product data** - See [provider retention](#zero-data-retention-zdr) and [feature-specific storage](#product-storage) above * **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 diff --git a/src/content/docs/enterprise/team-management/admin-panel.mdx b/src/content/docs/enterprise/team-management/admin-panel.mdx index e0c11a5a1..59978330d 100644 --- a/src/content/docs/enterprise/team-management/admin-panel.mdx +++ b/src/content/docs/enterprise/team-management/admin-panel.mdx @@ -192,7 +192,7 @@ This is the organization-level control for the collection governed by **Help imp **Cloud conversation storage** -Controls cloud sync of personal Terminal conversations. Disabling it doesn't disable factory or other cloud agent run storage. Transcripts, prompt attachments, and uploaded artifacts persist independently of analytics preferences; see [product storage](/enterprise/security-and-compliance/security-overview/#product-storage) and [self-hosted agent data storage](/factories/self-hosting/data-storage/). +Controls cloud sync of personal Terminal conversations. Disabling it doesn't disable factory or other cloud agent run storage. See [product storage](/enterprise/security-and-compliance/security-overview/#product-storage) for run-data categories and storage options. **Enterprise secret redaction** Automatically detects and redacts sensitive information before sending data to LLM providers: diff --git a/src/content/docs/factories/factory-agents/configuration.mdx b/src/content/docs/factories/factory-agents/configuration.mdx index dc4496326..f0120a67f 100644 --- a/src/content/docs/factories/factory-agents/configuration.mdx +++ b/src/content/docs/factories/factory-agents/configuration.mdx @@ -61,41 +61,56 @@ For team-managed inference in definition files, see [custom endpoint and BYOK mo ## Reviewing inference for provider ZDR -Start with [factory ZDR coverage and its limits](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). The procedures below remove known model exceptions from settings you control; they don't certify coverage for every auxiliary request. Both work in a browser without Warp Terminal. +Configure your factory to avoid [models requiring provider retention](/agents/inference/model-choice/#models-requiring-provider-retention) in the settings you control. Both paths below work in a browser without Warp Terminal. First, read [factory ZDR coverage and its limits](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). -Before using Self-improvement with sensitive run data, ask Warp to confirm its separate analysis model and provider coverage. It doesn't inherit the foreman's model. +Before editing, review [inference credentials](/factories/infrastructure-and-security/#inference-options-for-factory-runs) with your admin. A team provider key can change whose account serves a model without changing its name. For your own account or direct Claude Code or Codex calls, [verify provider retention](/factories/infrastructure-and-security/#choose-inference-covered-by-provider-zdr); don't switch credentials or harnesses solely to follow these steps. + +Factory defaults apply to agents that inherit them. Explicit agent settings and automation overrides can select a different model, so changing the default alone isn't enough. ### Reviewing a dashboard-managed factory -For a Warp-managed definition, you need the [editing access listed above](#prerequisites). Use the [model exception list](/agents/inference/model-choice/#models-requiring-provider-retention) when making each selection. +Use this path for a Warp-managed definition. You need [factory editing access](#prerequisites). If the definition is read-only, use the [GitHub path](#reviewing-a-github-backed-factory). -1. Open the {VARS.FACTORY_WEB_APP} and expand your factory in the sidebar. In **Agents**, open each agent's **Settings**. In the "Harness" and "Model" dropdowns, choose the Warp Agent and a model outside the exception list. Click **Save** for each changed agent. -2. In the factory's **Factory definition** tab, open `factory.yaml`. Set `agentDefaults.model`, or the model under `agentDefaults.harness`, outside the exception list. Don't keep both `model` and `harness`. This default applies where an agent doesn't override it; see [model and harness syntax](/factories/factory-as-code/#agentdefaultsmodel). -3. In **Factory definition**, review each `automations//automation.md`. Change any `model` or `harness` [execution override](/factories/factory-as-code/#execution-overrides) that selects an exception. The **Automations** editor doesn't expose these overrides. -4. In **Factory definition**, review `agentDefaults.computerUseModel` and any `computerUseModel` in agent or automation files. Remove listed exceptions from these choices too. Omitted values inherit or use automatic selection; see [Computer Use model inheritance](/factories/factory-as-code/#agentdefaultscomputerusemodel). -5. In **Scorers**, open each Scorer and review its "Judge model." Change any exception and save. If an agent selects a custom router, review every router target and its default model, not only the router's name. -6. Save the definition changes. Before starting work, complete [the run-level checks below](#checking-new-runs). +1. Open the {VARS.FACTORY_WEB_APP}, expand your factory, and click **Factory definition**. Open the existing `factory.yaml`. +2. For a Warp Agent default (`type: oz`), set `agentDefaults.model` or `agentDefaults.harness.model` outside the exception list. Keep only one form; see [model syntax](/factories/factory-as-code/#agentdefaultsmodel). For a third-party harness default, verify retention with its provider instead. Save changes and confirm validation succeeds. +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 the applicable [additional model checks](#checking-separate-model-settings). Use **Factory definition** for settings the dedicated editors don't expose. Save definition edits and confirm validation succeeds before [checking a new run](#checking-new-runs). ### Reviewing a GitHub-backed factory -You need permission to propose and merge definition changes in the connected GitHub repository. Dashboard editors are read-only for 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 the existing `factory.yaml`, check the default harness. For the Warp Agent (`type: oz`), set `agentDefaults.model` or `agentDefaults.harness.model` outside the exception list. Keep only one form; see [model syntax](/factories/factory-as-code/#agentdefaultsmodel). For a third-party harness, verify retention with its provider instead. +3. Open each existing `agents//agent.md`, including the foreman. For agents using the Warp Agent, replace retention-required models in explicit `model` or `harness.model` settings. Verify third-party harness choices with their provider. Keep unrelated settings and instructions. +4. Complete the applicable [additional model checks](#checking-separate-model-settings) in the definition files. +5. Open a pull request and confirm the [factory-definition checks](/factories/factory-as-code/#pull-request-checks) pass. Merge into the factory's connected production branch and confirm a successful definition sync before [checking a new run](#checking-new-runs). + +### 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 each `automations//automation.md`, replace exception models in `model` or `harness.model`. These override the target agent. Use **Factory definition** for a dashboard-managed factory; the **Automations** editor doesn't expose 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 the dashboard's **Scorers** page, open each Scorer and change any exception in "Judge model," then save. For GitHub-backed definitions, edit `model` in each `scorers//scorer.md`. | +| Custom routers | Review every target and the default model in the [router definition](/factories/factory-as-code/#routersnameyaml), including routers selected from another factory. Replace exception models; checking only the router's name isn't enough. | +| 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. | -1. Open the {VARS.FACTORY_WEB_APP}, expand your factory, and open **Settings**. Follow its repository link to the connected definition. In GitHub, open the existing `factory.yaml` and create a branch for your edits. -2. In `factory.yaml`, set `agentDefaults.model`, or the model under `agentDefaults.harness`, outside the [model exception list](/agents/inference/model-choice/#models-requiring-provider-retention). Use the Warp Agent harness (`type: oz`) for Warp-managed inference. Don't keep both `model` and `harness`. -3. Edit each existing `agents//agent.md` and `automations//automation.md`. Replace exception models in their frontmatter's `model` or `harness` settings. Agent overrides replace the factory default; [automation overrides](/factories/factory-as-code/#execution-overrides) can replace the selected agent's settings. -4. Review `agentDefaults.computerUseModel` in `factory.yaml` and `computerUseModel` in agent and automation files. Remove listed exceptions from these separate choices. Check [inheritance and automatic selection](/factories/factory-as-code/#agentdefaultscomputerusemodel) when a value is omitted. -5. Review the `model` in each `scorers//scorer.md`. Replace exceptions there too. If any selection uses a custom router, inspect every target and its default model in the connected router definition. -6. Open a pull request in GitHub, pass the [factory-definition checks](/factories/factory-as-code/#pull-request-checks), and merge through your normal review process into the factory's connected production branch. Confirm the definition synced successfully before starting a new 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 -Team-managed keys can change whose provider account serves a named model. Review the [inference options and credentials](/factories/infrastructure-and-security/#inference-options-for-factory-runs), even when a model's name hasn't changed. For your own keys or endpoints, BYOLLM, or direct Claude Code or Codex calls, verify provider retention for the specific account, model, and configuration. +After saving or syncing the changes: -Before launching a [benchmark](/factories/benchmarks/#create-and-run-a-benchmark), check every trial's harness, model, and selected Scorers. For runs started by an API, CLI, or another agent, check supplied model or harness overrides too. +1. In the web app, click **New Chat**, choose your factory below the prompt input, and send non-sensitive test input, such as: “Reply with a greeting. Don't read repository files or call tools.” +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. -Start a new run with non-sensitive test input. In the factory dashboard's **Runs**, open the run and inspect its model and harness. Check child runs separately. Existing runs keep their selected model. This confirms the visible configuration, not the provider contract or every auxiliary call. Recheck when models, credentials, or workflows change. +Saved choices apply to new runs; existing runs keep their selected model. These checks confirm visible configuration, not provider contracts or every background request. Recheck when models, credentials, or workflows change. -### Configuring a third-party harness +## 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/infrastructure-and-security.mdx b/src/content/docs/factories/infrastructure-and-security.mdx index a5911ed79..75cf7a11f 100644 --- a/src/content/docs/factories/infrastructure-and-security.mdx +++ b/src/content/docs/factories/infrastructure-and-security.mdx @@ -11,24 +11,33 @@ Warp Factories separates execution, inference, and credential boundaries. You ch ## Zero Data Retention (ZDR) for factory inference -Warp provides provider Zero Data Retention (ZDR) for supported Warp-managed models by default on every plan. The model you choose and the provider account serving the request affect that coverage. On self-serve plans, you can change factory models and overrides manually, but you don't have a team-wide control that blocks models requiring retention. +Provider Zero Data Retention (ZDR) covers whether the AI provider keeps your prompts and responses. Warp's [provider ZDR policy](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) applies to supported models on every plan when Warp supplies the provider account. This is called Warp-managed inference; it is separate from where your agent runs commands. -Avoiding Claude Fable 5, 5.1, and 5.2 removes the [known model exceptions](/agents/inference/model-choice/#models-requiring-provider-retention), including their effort variants. This requires avoiding them in every agent, automation, Computer Use, Scorer, and run-level override, not only the foreman's model. If you use your own provider account or a third-party harness, avoiding those models doesn't establish ZDR: verify retention for that account, model, and configuration. +### Choose inference covered by provider ZDR -Current Auto selections, fallback chains for other models, and automatic Computer Use selection don't introduce the listed Fable models. Auto and fallback can change over time; selecting a model isn't a permanent pin for every request. Coverage of every auxiliary inference path hasn't been confirmed. If your policy requires every inference request to have provider ZDR, ask Warp to confirm the routing and provider coverage for your configuration before sending sensitive work. Avoiding Fable alone isn't that confirmation. +* **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 your own keys, endpoints, BYOLLM, or direct Claude Code or Codex calls, verify ZDR with the provider for the specific account, model, and configuration. Warp's agreements don't establish ZDR for those requests, even if you avoid the listed models. -Review and save your configuration without installing Warp Terminal: +Current Auto selections, non-Fable fallback chains, 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. -* [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). +### Understand collection and storage + +Provider ZDR doesn't stop Warp from saving data needed to operate your factory: + +* **Improvement collection** - **Help improve Warp** 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. -Business supports shared provider keys and endpoints, but that isn't a team-wide model restriction. Enterprise has separate [model restrictions in the Admin Panel](/enterprise/team-management/admin-panel/#models-settings). +See the [separate analytics and storage controls](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why). Enterprise admins can configure [self-hosted storage](/factories/self-hosting/data-storage/) independently for each run-data category; unmapped categories remain with Warp. -### Provider retention, Warp analytics, and run storage +### Configure your factory -Provider ZDR covers prompts and responses at the inference provider. **Help improve Warp** controls Warp's analytics and improvement collection, not provider retention. See the [Security overview](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why) for Warp-wide policy and [Agent model choice](/agents/inference/model-choice/#models-requiring-provider-retention) for the complete model exception list. +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). -Warp stores factory transcripts, prompt attachments, and uploaded artifacts so you can revisit runs, even with analytics off. **Store AI conversations in the cloud** controls personal Terminal conversation sync, not factory run storage. An Enterprise admin can map run-data categories to [self-hosted agent data storage](/factories/self-hosting/data-storage/); unmapped categories remain with Warp. Destroying a sandbox doesn't delete these records. +Choose the procedure for where your definition is managed. Both work in a browser without installing Warp Terminal: + +* [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). ## Control plane and execution plane @@ -107,9 +116,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. For customer-managed keys, endpoints, and BYOLLM, verify ZDR with your provider for the specific account, model, and configuration, including any upstream providers behind a gateway. Warp can't enforce provider ZDR for those requests. +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](#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. Verify retention under the account and configuration used by the harness's authentication, separately from Warp-managed inference. +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 diff --git a/src/content/docs/platform/architecture.mdx b/src/content/docs/platform/architecture.mdx index c762cd538..8a66bdf63 100644 --- a/src/content/docs/platform/architecture.mdx +++ b/src/content/docs/platform/architecture.mdx @@ -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. The Warp Agent routes model calls through Warp. Provider retention depends on the [model and inference configuration](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr); Claude Code and Codex call their providers directly under your provider terms. +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 using Warp-managed inference or your [team-managed keys and endpoints](/enterprise/enterprise-features/team-managed-keys-and-endpoints/) or [BYOLLM](/enterprise/enterprise-features/bring-your-own-llm/) account. [Provider ZDR and its exceptions](/agents/inference/model-choice/#zero-data-retention-policies) apply to Warp-managed inference; verify your own provider account's terms separately. Claude Code and Codex call their providers 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 using the [configured inference option](/factories/infrastructure-and-security/#inference-options-for-factory-runs). Self-hosting doesn't establish provider ZDR. +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,8 +93,8 @@ 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** - The Warp Agent routes model calls through Warp. Warp-managed inference has [provider ZDR coverage with model-specific exceptions](/agents/inference/model-choice/#zero-data-retention-policies). For customer-managed keys, endpoints, BYOLLM, and direct Claude Code or Codex calls, verify ZDR with the provider for the specific account, model, and configuration. +* **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](/enterprise/security-and-compliance/security-overview/#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. @@ -106,7 +106,7 @@ 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. -Review [provider retention and run storage](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) separately from the execution host. Moving compute doesn't change the inference provider's terms or automatically move stored transcripts, attachments, and artifacts. +Moving compute doesn't automatically move run-data storage. For factory configuration, follow [factory ZDR guidance](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). ![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) 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 b4a6af2e6..6def4084b 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 @@ -31,7 +31,7 @@ If you haven't opted out of **Help improve Warp**, Warp may collect: Turning off **Help improve Warp** stops analytics and eligible AI interaction and console-content collection for service improvement, subject to [organization-enforced settings](/enterprise/team-management/admin-panel/#privacy-settings). **Send crash reports** controls crash reporting separately. -Turning off analytics doesn't change a provider's retention requirements. See the [Security overview](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why) for the separate provider ZDR, analytics, and storage policies, or [factory ZDR guidance](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) for factory configuration. +Turning off analytics doesn't change [provider retention requirements](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr). 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. @@ -45,7 +45,7 @@ You can read our [full privacy policy](https://www.warp.dev/legal/privacy-policy ![Privacy Settings](../../../../assets/support-and-community/privacy-settings-after-signup-1.png) -With analytics off, product data can still persist. Personal Terminal conversations follow the separate [cloud conversation setting](/agents/local-agents/cloud-conversations/). Factory transcripts, prompt attachments, and uploaded artifacts remain available for past runs independently of both settings; see [factory storage boundaries](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). Shared sessions follow their own [retention and access rules](/agents/local-agents/session-sharing/#data-retention-and-access). +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/infrastructure-and-security/#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 From 577dc7724527a7b11cfb0149fc7edf65de3c3f73 Mon Sep 17 00:00:00 2001 From: Rachael Rose Renk <91027132+rachaelrenk@users.noreply.github.com> Date: Fri, 13 Nov 2026 14:02:55 -0700 Subject: [PATCH 5/8] docs: close ZDR reader-journey gaps and flag plan follow-up Clarify definition management, save-versus-apply checks, feature-specific tests, and cross-factory router access. Scope admin controls, add browser collection guidance, and record the deferred factory-plan update in a source TODO. Co-Authored-By: Warp --- .../team-management/admin-panel.mdx | 26 ++++++++---- .../factory-agents/configuration.mdx | 40 ++++++++++++------- .../docs/factories/factory-dashboard.mdx | 4 +- .../factories/infrastructure-and-security.mdx | 2 +- .../privacy-and-security/privacy.mdx | 2 + 5 files changed, 49 insertions(+), 25 deletions(-) diff --git a/src/content/docs/enterprise/team-management/admin-panel.mdx b/src/content/docs/enterprise/team-management/admin-panel.mdx index 59978330d..1a29f5d1d 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 @@ -188,7 +188,19 @@ Controls how Warp collects and uses user-generated content to improve the servic * **Enabled** - Allow data collection for service improvement * **Respect User Setting** - Let individual users decide -This is the organization-level control for the collection governed by **Help improve Warp**. It doesn't change [provider retention requirements](/agents/inference/model-choice/#models-requiring-provider-retention) or disable product storage. +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** @@ -220,11 +232,11 @@ 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/). - -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. +Use the **Models** page for the controls included in your plan: -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** diff --git a/src/content/docs/factories/factory-agents/configuration.mdx b/src/content/docs/factories/factory-agents/configuration.mdx index f0120a67f..d226800ca 100644 --- a/src/content/docs/factories/factory-agents/configuration.mdx +++ b/src/content/docs/factories/factory-agents/configuration.mdx @@ -61,30 +61,32 @@ For team-managed inference in definition files, see [custom endpoint and BYOK mo ## Reviewing inference for provider ZDR -Configure your factory to avoid [models requiring provider retention](/agents/inference/model-choice/#models-requiring-provider-retention) in the settings you control. Both paths below work in a browser without Warp Terminal. First, read [factory ZDR coverage and its limits](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). +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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) first. Both paths work in a browser without Warp Terminal. -Before editing, review [inference credentials](/factories/infrastructure-and-security/#inference-options-for-factory-runs) with your admin. A team provider key can change whose account serves a model without changing its name. For your own account or direct Claude Code or Codex calls, [verify provider retention](/factories/infrastructure-and-security/#choose-inference-covered-by-provider-zdr); don't switch credentials or harnesses solely to follow these steps. +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/infrastructure-and-security/#choose-inference-covered-by-provider-zdr). Don't switch credentials or harnesses solely to follow these steps. -Factory defaults apply to agents that inherit them. Explicit agent settings and automation overrides can select a different model, so changing the default alone isn't enough. +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 -Use this path for a Warp-managed definition. You need [factory editing access](#prerequisites). If the definition is read-only, use the [GitHub path](#reviewing-a-github-backed-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. For a Warp Agent default (`type: oz`), set `agentDefaults.model` or `agentDefaults.harness.model` outside the exception list. Keep only one form; see [model syntax](/factories/factory-as-code/#agentdefaultsmodel). For a third-party harness default, verify retention with its provider instead. Save changes and confirm validation succeeds. +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 the applicable [additional model checks](#checking-separate-model-settings). Use **Factory definition** for settings the dedicated editors don't expose. Save definition edits and confirm validation succeeds before [checking a new run](#checking-new-runs). +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 the existing `factory.yaml`, check the default harness. For the Warp Agent (`type: oz`), set `agentDefaults.model` or `agentDefaults.harness.model` outside the exception list. Keep only one form; see [model syntax](/factories/factory-as-code/#agentdefaultsmodel). For a third-party harness, verify retention with its provider instead. -3. Open each existing `agents//agent.md`, including the foreman. For agents using the Warp Agent, replace retention-required models in explicit `model` or `harness.model` settings. Verify third-party harness choices with their provider. Keep unrelated settings and instructions. +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. Open a pull request and confirm the [factory-definition checks](/factories/factory-as-code/#pull-request-checks) pass. Merge into the factory's connected production branch and confirm a successful definition sync before [checking a new run](#checking-new-runs). +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 @@ -92,10 +94,10 @@ Complete each check that applies to your factory rather than assuming every feat | If you use… | Check before starting work | | --- | --- | -| Automations | In each `automations//automation.md`, replace exception models in `model` or `harness.model`. These override the target agent. Use **Factory definition** for a dashboard-managed factory; the **Automations** editor doesn't expose these settings. | +| 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 the dashboard's **Scorers** page, open each Scorer and change any exception in "Judge model," then save. For GitHub-backed definitions, edit `model` in each `scorers//scorer.md`. | -| Custom routers | Review every target and the default model in the [router definition](/factories/factory-as-code/#routersnameyaml), including routers selected from another factory. Replace exception models; checking only the router's name isn't enough. | +| 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. | @@ -103,12 +105,20 @@ Self-improvement analyzes run data with a separate model, not the foreman's mode ### Checking new runs -After saving or syncing the changes: +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 below the prompt input, and send non-sensitive test input, such as: “Reply with a greeting. Don't read repository files or call tools.” +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. -Saved choices apply to new runs; existing runs keep their selected model. These checks confirm visible configuration, not provider contracts or every background request. Recheck when models, credentials, or workflows change. +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 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/infrastructure-and-security.mdx b/src/content/docs/factories/infrastructure-and-security.mdx index 75cf7a11f..c4aed5c2e 100644 --- a/src/content/docs/factories/infrastructure-and-security.mdx +++ b/src/content/docs/factories/infrastructure-and-security.mdx @@ -28,7 +28,7 @@ Provider ZDR doesn't stop Warp from saving data needed to operate your factory: * **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. -See the [separate analytics and storage controls](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why). Enterprise admins can configure [self-hosted storage](/factories/self-hosting/data-storage/) independently for each run-data category; unmapped categories remain with Warp. +To change team content collection for improvement, 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](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why). Enterprise admins can configure [self-hosted storage](/factories/self-hosting/data-storage/) independently for each run-data category; unmapped categories remain with Warp. ### Configure your factory 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 6def4084b..424becf8c 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 @@ -39,6 +39,8 @@ You can read our [full privacy policy](https://www.warp.dev/legal/privacy-policy ### How to disable telemetry and crash reporting +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. From a688be1fa8036e13b6c39087468f3e7eb4d3abaf Mon Sep 17 00:00:00 2001 From: Rachael Rose Renk <91027132+rachaelrenk@users.noreply.github.com> Date: Fri, 13 Nov 2026 15:14:04 -0700 Subject: [PATCH 6/8] docs: clarify privacy copy and make ZDR guidance discoverable Apply editorial review revisions, move shared provider retention and storage guidance to Support, and add direct factory ZDR discovery routes. Preserve Enterprise policy anchors and leave compliance evidence and pricing follow-ups separate. Co-Authored-By: Warp --- .../docs/agents/getting-started/faqs.mdx | 4 +- src/content/docs/agents/index.mdx | 2 +- .../inference/bring-your-own-api-key.mdx | 6 +-- .../inference/custom-inference-endpoint.mdx | 4 +- .../docs/agents/inference/model-choice.mdx | 12 +++--- .../local-agents/cloud-conversations.mdx | 15 ++++--- .../architecture-and-deployment.mdx | 18 ++++----- .../team-managed-keys-and-endpoints.mdx | 4 +- src/content/docs/enterprise/index.mdx | 2 +- .../security-overview.mdx | 34 +++++----------- .../security-and-compliance/trust-center.mdx | 2 +- .../team-management/admin-panel.mdx | 4 +- src/content/docs/factories/index.mdx | 2 + .../factories/infrastructure-and-security.mdx | 4 +- .../self-hosting/security-and-networking.mdx | 4 +- src/content/docs/platform/architecture.mdx | 2 +- .../plans-and-billing/pricing-faqs.mdx | 6 +-- .../privacy-and-security/privacy.mdx | 39 ++++++++++++++++--- src/sidebar.ts | 1 + 19 files changed, 90 insertions(+), 75 deletions(-) diff --git a/src/content/docs/agents/getting-started/faqs.mdx b/src/content/docs/agents/getting-started/faqs.mdx index bf8fde2ed..2804b5d0b 100644 --- a/src/content/docs/agents/getting-started/faqs.mdx +++ b/src/content/docs/agents/getting-started/faqs.mdx @@ -21,9 +21,9 @@ Agent Mode has replaced the previous AI chat panel. Agent Mode is more powerful ### Is my data used for model training? -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 **Help improve Warp** stops analytics and eligible content collection for service improvement, subject to organization-enforced settings. +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. -Separately, covered Warp-managed inference isn't used by the provider for training, but some models require provider retention. See the [model exceptions](/agents/inference/model-choice/#models-requiring-provider-retention) and the [separate analytics and storage controls](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why). +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 a127cf4ca..212f6504a 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**. Review the [provider Zero Data Retention policy](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr), [model exceptions](/agents/inference/model-choice/#models-requiring-provider-retention), and separate analytics and product-storage controls. For factory runs, start with [factory ZDR guidance](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). +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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). 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 5ad1aa837..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,11 +105,11 @@ You can update or replace your keys anytime by opening **Settings** and searchin ### Zero Data Retention (ZDR) and BYOK -Warp has a [SOC 2 Type 2 attestation](https://www.warp.dev/legal/security). Its [provider ZDR policy](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) covers supported Warp-managed inference, not requests through your own key. +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. -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. +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. -BYOK prompts and responses [transit Warp's backend](#how-byok-works). Warp applies the same account-level privacy settings as for Warp-billed traffic, including organization-enforced settings. Review [analytics and conversation storage](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why) separately from provider retention. +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 863f8d137..acff4b8ae 100644 --- a/src/content/docs/agents/inference/custom-inference-endpoint.mdx +++ b/src/content/docs/agents/inference/custom-inference-endpoint.mdx @@ -83,9 +83,9 @@ Other features use their own inference configuration and are unaffected by a per ## Zero Data Retention (ZDR) -Warp cannot enforce provider ZDR for your endpoint. Verify retention with the endpoint provider and any upstream model providers for the specific account, model, and configuration; their terms apply to those requests. +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. -Prompts and responses still [transit Warp's backend](#how-it-works). Review [Warp's separate analytics and storage controls](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why); they don't change your provider's terms. +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 39023d663..f99631ff0 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 -Some Anthropic models require provider retention even when analytics is off. Check [models requiring provider retention](#models-requiring-provider-retention) before selecting a model. +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 @@ -157,24 +157,24 @@ Edit your default profile or any other profile directly in **Settings** > **Agen ### Reviewing inference and privacy in Terminal -Before sending sensitive content: +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](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why). +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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) instead. ### Zero data retention policies -Warp has provider Zero Data Retention (ZDR) agreements for supported Warp-managed models on all plans. The [Security overview](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) explains the policy. +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. 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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). #### Models requiring provider retention -Anthropic requires retention for these models, including their effort variants, for safety, abuse monitoring, and compliance: +Anthropic requires data retention for safety, abuse monitoring, and compliance. This requirement applies to the following models at every effort level: * Claude Fable 5 * Claude Fable 5.1 @@ -182,4 +182,4 @@ Anthropic requires retention for these models, including their effort variants, 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). -For your own provider account, [verify retention with your provider](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr); selecting a model outside this list doesn't establish ZDR for that account. +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 6f907ee21..36189c4a4 100644 --- a/src/content/docs/agents/local-agents/cloud-conversations.mdx +++ b/src/content/docs/agents/local-agents/cloud-conversations.mdx @@ -20,12 +20,12 @@ Warp can sync your [agent conversations](/agents/local-agents/interacting-with-a ## Enabling cloud conversations -Cloud conversation sync for your personal Terminal conversations is controlled separately from analytics and provider retention: +To control whether your personal Warp Terminal conversations sync to the cloud: 1. In the Warp app, open **Settings** > **Privacy**. 2. Toggle **Store AI conversations in the cloud** on or off. -When enabled, your personal Terminal conversations sync to the cloud as you interact with the agent. When disabled, those conversations are stored locally only. **Help improve Warp** doesn't control this storage; see [analytics and product storage](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why). +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 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. @@ -93,7 +93,7 @@ Cloud-synced conversations store snapshots of conversation data. For real-time c ## Cloud agent conversations -[Cloud agents](/platform/), including factory agents, store run conversations independently of your personal cloud conversation and analytics settings. Run data uses Warp-managed storage unless an Enterprise admin configures [self-hosted agent data storage](/factories/self-hosting/data-storage/). Provider ZDR doesn't disable this product storage. +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 personal Terminal cloud conversation sync for their organization through the [Admin Panel](/enterprise/team-management/admin-panel/#privacy-settings). +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: -* Personal Terminal 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 2e5c14034..b74b50420 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. -* Provider retention follows the [model and provider-account configuration](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr), not the execution host. +* 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) @@ -57,7 +57,7 @@ Warp-hosted agents can be triggered by: ## Self-hosted execution -For organizations that need repository checkouts and command execution on their own infrastructure, Warp supports self-hosted execution. Code context can still transit Warp in prompts and run data. +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. @@ -68,7 +68,7 @@ Self-hosted execution is available exclusively on Warp's **Enterprise** plan. Self-hosted deployments use a split architecture: * **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 routes Warp Agent inference. See [What transits Warp's servers](#what-transits-warps-servers) for the data it receives. +* **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,7 +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. -* You need to keep repository checkouts on your infrastructure while allowing code context in prompts and run data to transit Warp. +* 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 @@ -120,18 +120,18 @@ Understanding what data stays where is critical for security and compliance deci ### What stays on customer infrastructure (self-hosted) -* **Source code** - Repository checkouts and version history; code excerpts can still appear in prompts and transcripts +* **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** - Execute locally; command output can appear in stored transcripts +* **Shell commands** - Commands run on your infrastructure. Their output can appear in stored transcripts. * **Runtime secrets** - Environment variables and credentials -* **Execution logs** - Local runtime logs; uploaded diagnostics and run records are separate +* **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** - 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 persist independently of the execution workspace. Configure their location through [self-hosted agent data storage](/factories/self-hosting/data-storage/). +* **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 @@ -146,7 +146,7 @@ Consider the following when selecting a deployment model: * You need maximum parallelization and scalability. **Self-hosted** is right if: -* Compliance requirements mandate local checkout and execution while permitting code context in prompts and stored run data. +* 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. 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 067bb84f0..d5dc6279a 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,9 +108,9 @@ Warp uses the stored credentials to call your provider without delivering them t ### Zero Data Retention (ZDR) -Your provider's terms govern requests through your team's keys or endpoints, not Warp's ZDR agreements. Verify retention for the specific account, model, and configuration, including upstream providers behind a gateway. Warp cannot enforce provider ZDR for these requests. +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. -Disabling UGC collection doesn't disable run storage. See the [separate analytics and storage controls](/enterprise/security-and-compliance/security-overview/#what-telemetry-does-warp-collect-and-why) or [factory ZDR guidance](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). +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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). diff --git a/src/content/docs/enterprise/index.mdx b/src/content/docs/enterprise/index.mdx index 652982dda..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 -* **Provider Zero Data Retention (ZDR)** - See the [provider policy and storage boundaries](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) and [model-specific exceptions](/agents/inference/model-choice/#models-requiring-provider-retention) +* **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 827a6169c..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,12 +1,12 @@ --- title: Security overview description: >- - Review provider Zero Data Retention, analytics controls, product storage, - and security boundaries across Warp. + Review Warp's enterprise security architecture, organization controls, + and deployment boundaries. --- import { VARS } from '@data/vars'; -Evaluate provider retention, Warp's analytics collection, and product storage separately when choosing how to use Warp. These controls apply to different copies of your data; turning off analytics doesn't disable storage needed for a product feature. +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 @@ -24,29 +24,15 @@ Warp's security philosophy centers on **transparency and developer control**: ### Zero Data Retention (ZDR) -Provider Zero Data Retention (ZDR) governs whether an inference provider retains prompts and responses. Warp has provider ZDR agreements for supported Warp-managed models across all plans. Covered providers 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 every known model exception. - -Warp-managed inference uses Warp's provider account, not your own. Turning off **Help improve Warp** doesn't make a retention-required model ZDR-covered. - -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/), verify ZDR with your provider for the specific account, model, and configuration. Warp's agreements don't establish ZDR for customer-managed inference. Claude Code and Codex calls made directly to their providers also use your provider terms, not Warp's. - -Follow the [Terminal procedure](/agents/inference/model-choice/#reviewing-inference-and-privacy-in-terminal) or [factory ZDR guidance](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) for configuration steps, plan controls, and coverage limits. +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. ### Warp analytics and improvement collection -**Help improve Warp** 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 [Privacy and data control](/support-and-community/privacy-and-security/privacy/#how-to-disable-telemetry-and-crash-reporting) for the controls and collected event types. +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). ### 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** - Transcripts, prompt attachments, and uploaded artifacts persist so you can inspect past runs. They use Warp-managed storage unless an Enterprise admin configures [self-hosted agent data storage](/factories/self-hosting/data-storage/). Categories are mapped independently; unmapped categories 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 whether inference is ZDR-covered or where run data is stored. Evaluate [inference and storage separately](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). +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 @@ -58,8 +44,8 @@ Follow [Privacy and data control](/support-and-community/privacy-and-security/pr * **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** - Provider retention depends on the model and inference configuration described [above](#zero-data-retention-zdr). -* **BYOLLM** - Requests are proxied through Warp's servers to your cloud infrastructure, where inference runs. See [customer-managed inference](#zero-data-retention-zdr) for retention. +* **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 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/). @@ -83,7 +69,7 @@ See [Secret Redaction documentation](/support-and-community/privacy-and-security ### Data retention -* **Inference and product data** - See [provider retention](#zero-data-retention-zdr) and [feature-specific storage](#product-storage) above +* **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 @@ -117,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)** - Warp coordinates runs and routes Warp Agent inference. Transcripts can contain code context and persist as product data independently of [provider ZDR](#zero-data-retention-zdr). Claude Code and Codex call their providers directly. +* **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. 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 6ee234c56..8ab665f1f 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 -See the [Security overview](/enterprise/security-and-compliance/security-overview/#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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) separately from analytics and storage. +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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) 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 1a29f5d1d..8a66cbfeb 100644 --- a/src/content/docs/enterprise/team-management/admin-panel.mdx +++ b/src/content/docs/enterprise/team-management/admin-panel.mdx @@ -204,7 +204,7 @@ If the control is locked by a workspace policy, ask a workspace admin to review **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](/enterprise/security-and-compliance/security-overview/#product-storage) for run-data categories and storage options. +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: @@ -240,7 +240,7 @@ Use the **Models** page for the controls included in your plan: **Models with provider-specific data retention requirements** -Some models require provider retention and aren't covered by [Zero Data Retention (ZDR)](/enterprise/security-and-compliance/security-overview/#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. +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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). diff --git a/src/content/docs/factories/index.mdx b/src/content/docs/factories/index.mdx index 573e30488..ace91c6b7 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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). + - - 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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) 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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). + ## Transparency and control Our philosophy is complete transparency and control over any data leaving your machine. This means you can: @@ -29,10 +60,6 @@ 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. -Turning off **Help improve Warp** stops analytics and eligible AI interaction and console-content collection for service improvement, subject to [organization-enforced settings](/enterprise/team-management/admin-panel/#privacy-settings). **Send crash reports** controls crash reporting separately. - -Turning off analytics doesn't change [provider retention requirements](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr). - 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). diff --git a/src/sidebar.ts b/src/sidebar.ts index 9894ed93d..f8938ab5d 100644 --- a/src/sidebar.ts +++ b/src/sidebar.ts @@ -401,6 +401,7 @@ export const sidebarTopics: StarlightSidebarTopicsUserConfig = [ { slug: 'factories', label: 'Overview' }, { slug: 'factories/how-factories-work', label: 'How Factories work' }, { slug: 'factories/quickstart', label: 'Quickstart' }, + { label: 'Zero data retention (ZDR)', link: '/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference' }, { slug: 'platform/transitioning-from-oz', label: 'Transitioning from Oz' }, ], }, From 151e55bc3c3a8a265d8241f0f7d18e77b9e5b0a4 Mon Sep 17 00:00:00 2001 From: Rachael Rose Renk <91027132+rachaelrenk@users.noreply.github.com> Date: Fri, 13 Nov 2026 15:54:48 -0700 Subject: [PATCH 7/8] docs: group factory ZDR navigation under infrastructure Co-Authored-By: Warp --- src/sidebar.ts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/sidebar.ts b/src/sidebar.ts index f8938ab5d..736d09489 100644 --- a/src/sidebar.ts +++ b/src/sidebar.ts @@ -401,7 +401,6 @@ export const sidebarTopics: StarlightSidebarTopicsUserConfig = [ { slug: 'factories', label: 'Overview' }, { slug: 'factories/how-factories-work', label: 'How Factories work' }, { slug: 'factories/quickstart', label: 'Quickstart' }, - { label: 'Zero data retention (ZDR)', link: '/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference' }, { slug: 'platform/transitioning-from-oz', label: 'Transitioning from Oz' }, ], }, @@ -442,6 +441,7 @@ export const sidebarTopics: StarlightSidebarTopicsUserConfig = [ label: 'Infrastructure', items: [ { slug: 'factories/infrastructure-and-security', label: 'About infrastructure and security' }, + { label: 'Zero data retention (ZDR)', link: '/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference' }, { 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' }, From 97a96888d0d45576cf0b3b968bf417dad93d1789 Mon Sep 17 00:00:00 2001 From: Rachael Rose Renk <91027132+rachaelrenk@users.noreply.github.com> Date: Fri, 13 Nov 2026 21:09:49 -0700 Subject: [PATCH 8/8] docs: extract dedicated factory ZDR guidance Give factory retention guidance its own Infrastructure page, preserve the original section anchors, and retarget related documentation links. Keep shared policy in Support and detailed procedures in agent configuration. Co-Authored-By: Warp --- src/content/docs/agents/index.mdx | 2 +- .../docs/agents/inference/model-choice.mdx | 4 +- .../architecture-and-deployment.mdx | 2 +- .../team-managed-keys-and-endpoints.mdx | 2 +- .../security-and-compliance/trust-center.mdx | 2 +- .../team-management/admin-panel.mdx | 2 +- .../factory-agents/configuration.mdx | 4 +- src/content/docs/factories/index.mdx | 2 +- .../factories/infrastructure-and-security.mdx | 38 ++++---------- .../self-hosting/security-and-networking.mdx | 2 +- .../docs/factories/zero-data-retention.mdx | 49 +++++++++++++++++++ src/content/docs/platform/architecture.mdx | 2 +- .../plans-and-billing/pricing-faqs.mdx | 4 +- .../privacy-and-security/privacy.mdx | 6 +-- src/sidebar.ts | 2 +- 15 files changed, 76 insertions(+), 47 deletions(-) create mode 100644 src/content/docs/factories/zero-data-retention.mdx diff --git a/src/content/docs/agents/index.mdx b/src/content/docs/agents/index.mdx index 212f6504a..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**. 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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). +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/model-choice.mdx b/src/content/docs/agents/inference/model-choice.mdx index f99631ff0..0eb7ef1c4 100644 --- a/src/content/docs/agents/inference/model-choice.mdx +++ b/src/content/docs/agents/inference/model-choice.mdx @@ -164,13 +164,13 @@ Before sending sensitive content through Warp Terminal: 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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) instead. +Confirm the model displayed before your next prompt. For factories, use [factory ZDR guidance](/factories/zero-data-retention/) instead. ### Zero data retention policies 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. -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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). +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/). #### Models requiring provider retention 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 b74b50420..310b63e1b 100644 --- a/src/content/docs/enterprise/enterprise-features/architecture-and-deployment.mdx +++ b/src/content/docs/enterprise/enterprise-features/architecture-and-deployment.mdx @@ -53,7 +53,7 @@ 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 permit Warp-hosted compute after a separate review of [inference and storage](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). +* Your security requirements permit Warp-hosted compute after a separate review of [inference and storage](/factories/zero-data-retention/). ## Self-hosted execution 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 d5dc6279a..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 @@ -110,7 +110,7 @@ Warp uses the stored credentials to call your provider without delivering them t 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. -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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). +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/security-and-compliance/trust-center.mdx b/src/content/docs/enterprise/security-and-compliance/trust-center.mdx index 8ab665f1f..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 -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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) separately from analytics and storage. +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 8a66cbfeb..a524ed1d8 100644 --- a/src/content/docs/enterprise/team-management/admin-panel.mdx +++ b/src/content/docs/enterprise/team-management/admin-panel.mdx @@ -242,7 +242,7 @@ Use the **Models** page for the controls included in your plan: 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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). +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 d226800ca..d326ffdde 100644 --- a/src/content/docs/factories/factory-agents/configuration.mdx +++ b/src/content/docs/factories/factory-agents/configuration.mdx @@ -61,9 +61,9 @@ For team-managed inference in definition files, see [custom endpoint and BYOK mo ## 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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) first. Both paths work in a browser without Warp Terminal. +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/infrastructure-and-security/#choose-inference-covered-by-provider-zdr). Don't switch credentials or harnesses solely to follow these steps. +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. diff --git a/src/content/docs/factories/index.mdx b/src/content/docs/factories/index.mdx index ace91c6b7..56c6701da 100644 --- a/src/content/docs/factories/index.mdx +++ b/src/content/docs/factories/index.mdx @@ -14,7 +14,7 @@ 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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). +Before sending sensitive work, review [ZDR, data collection, and storage for factory runs](/factories/zero-data-retention/). -Provider Zero Data Retention (ZDR) covers whether the AI provider keeps your prompts and responses. 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; it is separate from where your agent runs commands. +## Provider retention -### 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 your own keys, endpoints, BYOLLM, or direct Claude Code or Codex calls, verify ZDR with the provider for the specific account, model, and configuration. Warp's agreements don't establish ZDR for those requests, even if you avoid the listed models. - -Current Auto selections, non-Fable fallback chains, 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. - -### Understand collection and storage - -Provider ZDR doesn't stop Warp from saving data needed to operate your factory: - -* **Improvement collection** - **Help improve Warp** 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. - -To change team content collection for improvement, 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/) independently for each run-data category; unmapped categories 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: - -* [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). +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 @@ -100,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. @@ -116,7 +95,7 @@ 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. Check [provider ZDR coverage](#choose-inference-covered-by-provider-zdr) separately, including any upstream providers behind a gateway. +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. @@ -170,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 089e7e3c6..7b556482d 100644 --- a/src/content/docs/factories/self-hosting/security-and-networking.mdx +++ b/src/content/docs/factories/self-hosting/security-and-networking.mdx @@ -117,7 +117,7 @@ See [GitLab](/platform/integrations/gitlab/) and [Bitbucket](/platform/integrati ## LLM inference and BYOLLM -The Warp Agent sends inference requests through Warp. Review [factory ZDR coverage and configuration](/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) independently of where commands run. +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. 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 b5483ed56..b8ee16939 100644 --- a/src/content/docs/platform/architecture.mdx +++ b/src/content/docs/platform/architecture.mdx @@ -106,7 +106,7 @@ 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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). +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) 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 c57a4a039..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. ::: -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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) for coverage, exceptions, and what self-serve teams can configure. +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? @@ -246,7 +246,7 @@ Yes. Warp has provider Zero Data Retention (ZDR) agreements for supported Warp-m ### How can I enable Zero Data Retention in Warp? -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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) for your workflow. +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. **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. 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 c38bf985f..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 @@ -23,7 +23,7 @@ Warp-managed inference uses Warp's provider account, not your own. Turning off * 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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference) 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. +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 @@ -39,7 +39,7 @@ Product features store data independently of provider ZDR and analytics preferen * **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/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference). +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 @@ -74,7 +74,7 @@ Without the Warp app, Business and Enterprise admins can change [team content co ![Privacy Settings](../../../../assets/support-and-community/privacy-settings-after-signup-1.png) -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/infrastructure-and-security/#understand-collection-and-storage). Shared sessions have their own [retention and access rules](/agents/local-agents/session-sharing/#data-retention-and-access). +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 736d09489..7b034ffe5 100644 --- a/src/sidebar.ts +++ b/src/sidebar.ts @@ -441,7 +441,7 @@ export const sidebarTopics: StarlightSidebarTopicsUserConfig = [ label: 'Infrastructure', items: [ { slug: 'factories/infrastructure-and-security', label: 'About infrastructure and security' }, - { label: 'Zero data retention (ZDR)', link: '/factories/infrastructure-and-security/#zero-data-retention-zdr-for-factory-inference' }, + { 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' },