From edd03ac8fda7a44b817fd7e1020e942d69aee1b6 Mon Sep 17 00:00:00 2001 From: Hong Yi Chen Date: Sat, 15 Aug 2026 16:46:32 -0700 Subject: [PATCH 1/5] docs(factories): document infrastructure and security Co-Authored-By: Warp Agent Co-Authored-By: Warp --- .../factories/infrastructure-and-security.mdx | 95 +++++++++++++++++-- .../docs/platform/self-hosting/index.mdx | 2 +- .../self-hosting/security-and-networking.mdx | 8 +- 3 files changed, 91 insertions(+), 14 deletions(-) diff --git a/src/content/docs/factories/infrastructure-and-security.mdx b/src/content/docs/factories/infrastructure-and-security.mdx index 4be57f77..8aaf7ed9 100644 --- a/src/content/docs/factories/infrastructure-and-security.mdx +++ b/src/content/docs/factories/infrastructure-and-security.mdx @@ -1,16 +1,95 @@ --- title: Warp Factories infrastructure and security description: >- - Warp Factories give you control over inference, hosting, and data exhaust - so you own your factory's infrastructure and outputs. + Warp Factories separate control and execution planes so teams can choose + hosting, inference, storage, secret, and governance controls. sidebar: label: "Infrastructure & security" --- -[STUB — pending content from HYC/content team for the 8/18 closed-beta soft launch. Owner: HYC. +Warp Factories separate coordination from execution. Your team can choose where a factory runs code, which supported providers serve model requests, where supported factory data is stored, and which credentials each agent receives. Available controls depend on your team's configuration and agreement with Warp. -Lightweight aggregation page — mostly link into existing detailed docs rather than duplicate them. Cover: -- AI sovereignty positioning: bring your own inference, bring your own hosting, own your data exhaust (agent conversations, evals, memories), ZDR -- Self-hosting (cross-link to the Automation Platform tab's Self-hosting docs rather than duplicating) -- Security, permissions, and governance for factory agent runs -- Closed beta / apply for access treatment consistent with other Factories pages] +## Control plane and execution plane + +* **Control plane** - Warp coordinates runs, identity and configuration, observability, integrations, storage, and inference routing. +* **Execution plane** - A Warp-hosted sandbox or managed self-hosted worker checks out code, runs setup, invokes tools, builds the project, and executes commands. + +```mermaid +flowchart LR + I["Integrations and triggers"] --> C["Warp control plane
coordination · identity/config
observability · inference routing"] + C --> H["Warp-hosted sandbox"] + C -->|"task, config, and scoped
runtime credentials"| S["Managed self-hosted worker"] + H -->|"results, transcripts,
artifacts, telemetry"| C + S -->|"results, transcripts, attachments,
artifacts, and telemetry
can contain code context"| C + C --> P["Warp-managed or
customer-configured inference"] + C --> D["Warp or supported
customer-owned storage"] +``` + +Managed self-hosting changes the execution boundary; it does not remove Warp from orchestration. On managed self-hosted compute, the repository checkout, command execution, and sandbox filesystem stay on customer infrastructure. Content included in prompts, results, transcripts, attachments, artifacts, or telemetry can still flow through Warp and configured providers. Customer-owned provider and storage options change their corresponding paths, not the existence of the control plane. See [deployment patterns](../platform/deployment-patterns) and [self-hosting security and networking](../platform/self-hosting/security-and-networking) for the broader data model. + +## Environments and runners + +| Configuration | Defines | Typical contents | +| --- | --- | --- | +| **Environment** | Workspace and runtime context | Repositories, setup, secrets, toolchain image, and provider configuration | +| Runner | Execution compute | Operating system, architecture, sandbox image, vCPUs, and memory | + +A run can select a runner explicitly. Otherwise, Warp uses the environment's configured execution defaults and ultimately the system default. Use [environments](../platform/environments) to define the workspace and the [runner reference](../platform/runners) for compute and resolution behavior. A factory references both through its [definition as code](./factory-as-code). + +In the control room, the [Runners surface](../platform/runners) shows each runner's default status, operating system and architecture, setup commands, and size. For an externally source-managed factory, `runners/*.yaml` remains the source of truth and edits open in the connected repository. With Warp-managed source, authorized users can create and edit runner files in the control room. + +Warp-hosted instance shapes are limited by your team's plan. Warp rejects a hosted shape above that limit. Managed self-hosted runners are exempt from the hosted size limit because your team supplies the compute. See the [runner reference](../platform/runners) for configuration details. + +## Choose an execution host + +A factory can select Warp-hosted compute or a managed self-hosted worker as its execution host. + +| Decision area | Warp-hosted | Managed self-hosted | +| --- | --- | --- | +| Compute | Warp provisions the sandbox | Your team provisions the worker | +| **Checkout and commands** | Run on Warp-managed compute | Run on customer-managed compute | +| **Control plane** | Runs through Warp | Runs through Warp | +| Network | Warp manages sandbox connectivity | Outbound connection to Warp; no inbound firewall port | +| **Private services** | Must be reachable from the hosted sandbox | Uses the worker's network access | +| Operations | Warp manages capacity and lifecycle | Your team manages capacity, isolation, updates, and availability | + +Managed self-hosted execution is available to eligible Enterprise teams. Supported worker implementations include `linux/amd64` and `linux/arm64`; each worker implementation determines workload compatibility. Workers authenticate to Warp with a supported principal. Select a managed self-hosted worker with [`workerHost` in the factory definition](./factory-as-code), use a compatible runner, and review the [self-hosting requirements](../platform/self-hosting/) before routing factory work. Unmanaged and other CLI agents are not selectable factory execution hosts, but they can exchange work with a factory through [Factory MCP](./factory-mcp). Do not treat self-hosting as a guarantee that all factory data stays in your network. + +## Choose execution, inference, and storage independently + +| Team choice | Boundary changed | What remains in the Warp path | +| --- | --- | --- | +| **Warp-hosted or managed self-hosted execution** | Where checkout, commands, and the sandbox filesystem run | Coordination, configuration, observability, and inference routing | +| **Warp-managed or customer-supplied inference** | Provider account, model routing, billing, and provider-side retention | Run coordination and inference routing | +| **Warp or customer-owned storage** | Persistence for supported transcripts, artifacts, and run attachments | Orchestration, the write path, and other factory and control-plane state | + +Cloud-agent inference supports team-managed first-party model credentials, AWS Bedrock, and OpenAI-compatible custom endpoints. Gemini Enterprise (Vertex AI) supports interactive sessions only and is not available to cloud agents. Provider-side retention follows your provider account and contract; Warp does not expose a retention toggle for that provider. Review [team-managed model keys and endpoints](../enterprise/enterprise-features/team-managed-keys-and-endpoints), [Bring Your Own LLM](../enterprise/enterprise-features/bring-your-own-llm), and the [security overview](../enterprise/security-and-compliance/security-overview). + +Eligible teams can use customer-owned Amazon S3 or Google Cloud Storage for the supported data classes in the table. Warp writes the applicable data to the configured bucket. Your team owns its access and lifecycle policies, but customer-owned storage does not move all factory state into your account. + +## Credential boundaries + +| Credential | Where it applies | Boundary | +| --- | --- | --- | +| **Inference credentials** | Model provider requests | Remain at the inference boundary and are not injected into the sandbox | +| **Execution secrets** | APIs, package registries, and tools used by an agent | Explicit per-agent allowlist; non-user factory agents default to no managed secrets | +| **Harness authentication** | Third-party harnesses such as Claude Code or Codex | Separate from the agent's general secret allowlist | +| **Repository identity** | Checkout and code-forge changes | User authorization for creator attribution or a team executor identity for unattended work | + +Restrict each credential to the resources and actions its agent needs. Warp redacts known secret values at output boundaries, but redaction does not replace narrow external permissions or rotation. See [cloud agent secrets](../platform/secrets), [harness authentication](../platform/harnesses/authentication), [secret redaction](../support-and-community/privacy-and-security/secret-redaction), and [team identity](../platform/team-access-billing-and-identity) for the underlying controls. + +## Governance and metering + +Team Owners and Admins control factory definitions, environments, runners, secrets, and provider configuration through existing [team roles](../enterprise/team-management/roles-and-permissions). Warp Factories does not add a factory-specific approval role. Specification review and merge approval remain workflow and repository policy decisions. Review factory-definition changes as operational code and keep merge access with the people responsible for shipping. + +Warp meters hosted compute, Warp-provided inference, and platform services. Your team supplies managed self-hosted compute. Customer-supplied providers bill model usage through the applicable provider account, while platform services can still consume credits. See [platform credits](../support-and-community/plans-and-billing/platform-credits) for the current model. + +## Deployment checklist + +1. **Classify the workload** - Identify the repositories, data, internal services, and regulated systems the factory can reach. +2. **Choose execution** - Decide where checkout, commands, and the sandbox filesystem must run. +3. **Define environments and runners** - Set repositories, setup, secrets, operating system, architecture, image, and compute. +4. **Choose inference and storage** - Select provider routing and persistence for supported data. +5. **Scope credentials** - Set each agent's secret allowlist, harness authentication, and repository identity. +6. **Set human gates** - Define specification and pull request review in workflow and repository policy. +7. **Validate operations** - Test network egress, isolation, rotation, redaction, capacity, observability, and metering before increasing volume. diff --git a/src/content/docs/platform/self-hosting/index.mdx b/src/content/docs/platform/self-hosting/index.mdx index 5cc939db..8faf7726 100644 --- a/src/content/docs/platform/self-hosting/index.mdx +++ b/src/content/docs/platform/self-hosting/index.mdx @@ -52,7 +52,7 @@ With any self-hosted architecture: * **Resource limits are controlled by your infrastructure** — Concurrency and compute are only limited by the machines you provision, not by Warp. :::note -Enterprise teams that need full control over LLM inference routing can use [Bring Your Own LLM (BYOLLM)](/enterprise/enterprise-features/bring-your-own-llm/) to route inference through their own cloud provider accounts. BYOLLM currently applies to interactive (local) agents; cloud agent support is coming. +Enterprise teams that need full control over LLM inference routing can use [Bring Your Own LLM (BYOLLM)](/enterprise/enterprise-features/bring-your-own-llm/) to route inference through their own cloud provider accounts. AWS Bedrock supports interactive sessions and cloud agents. Gemini Enterprise supports interactive sessions only and is not available to cloud agents. ::: --- diff --git a/src/content/docs/platform/self-hosting/security-and-networking.mdx b/src/content/docs/platform/self-hosting/security-and-networking.mdx index c039db6a..7b0662e6 100644 --- a/src/content/docs/platform/self-hosting/security-and-networking.mdx +++ b/src/content/docs/platform/self-hosting/security-and-networking.mdx @@ -22,14 +22,14 @@ Self-hosted execution keeps repository clones, source files, build artifacts, ru * Runtime secrets and environment variables. * Container filesystem state (managed architecture) or host workspace (Direct backend / unmanaged). -**Routes through Warp's backend** (under [Zero Data Retention (ZDR)](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr)): +**Routes through Warp's backend:** * Orchestration metadata (task status, lifecycle events). * Session transcripts, which include agent-generated summaries of code context, file contents the agent reads, and command output. * LLM inference requests and responses, which include code context from the agent's interactions. :::note -While repositories are cloned and stored only on your infrastructure, code content appears in session transcripts and LLM prompts as part of normal agent operation. All data routed through Warp's backend is covered by [ZDR](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) agreements — Warp does not persistently store your source code or use it for model training. +While repositories are cloned and stored only on your infrastructure, code content can appear in session transcripts, artifacts, and LLM prompts as part of normal agent operation. Warp stores applicable orchestration and conversation data according to your product configuration and agreement. When you use Warp-managed inference, contracted model providers process requests under Warp's [Zero Data Retention (ZDR)](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) agreements. Customer-supplied inference follows the provider agreement configured by your team. ::: --- @@ -102,9 +102,7 @@ See [GitLab](/platform/integrations/gitlab/) and [Bitbucket](/platform/integrati ## LLM inference and BYOLLM -LLM inference routes through Warp's backend, which has [ZDR](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) agreements with all contracted model providers. Enterprise teams that need full control over inference routing can use [Bring Your Own LLM (BYOLLM)](/enterprise/enterprise-features/bring-your-own-llm/) to route inference through their own cloud provider accounts. - -BYOLLM currently applies to interactive (local) agents; cloud agent BYOLLM support is coming. +LLM inference routes through Warp's backend. Warp-managed inference uses contracted providers with [ZDR](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) agreements. Enterprise teams can use [team-managed model keys and endpoints](/enterprise/enterprise-features/team-managed-keys-and-endpoints/) for supported cloud-agent providers, including AWS Bedrock. Gemini Enterprise through Google Vertex AI currently applies to interactive agents rather than cloud agents. --- From ec7c86681ae199f1f7f30326ac107851c7830d69 Mon Sep 17 00:00:00 2001 From: hongyi-chen Date: Sun, 16 Aug 2026 05:05:55 +0000 Subject: [PATCH 2/5] docs(factories): editorial pass on infrastructure and security for clarity Rewrites dense, hedged phrasing in plain language while preserving all verified claims: - Replace "available controls depend on your team's configuration and agreement with Warp" with the concrete gating: self-hosted execution and customer-supplied inference are Enterprise features; customer-owned storage is enabled for eligible teams. - Spell out jargon: "supported principal" -> agent API key, "worker implementations" -> worker platforms, "hosted shape" -> instance shape (vCPUs and memory), "the write path" -> Warp writes to your bucket. - Break the dense self-hosting paragraph into a numbered deploy flow and move the data-locality warning into a :::caution callout. - Normalize table bolding, clarify column headers ("Boundary changed" -> "What it changes"), and add lead-in sentences before tables. - Clarify retention wording in the self-hosting security note (what is stored and for how long, and who governs provider-side retention). Validation: style lint 0 errors on changed pages, npm run build (377 pages), internal link check 0 broken. Co-Authored-By: Warp --- .../factories/infrastructure-and-security.mdx | 89 ++++++++++++------- .../docs/platform/self-hosting/index.mdx | 2 +- .../self-hosting/security-and-networking.mdx | 4 +- 3 files changed, 58 insertions(+), 37 deletions(-) diff --git a/src/content/docs/factories/infrastructure-and-security.mdx b/src/content/docs/factories/infrastructure-and-security.mdx index 8aaf7ed9..3bf42dba 100644 --- a/src/content/docs/factories/infrastructure-and-security.mdx +++ b/src/content/docs/factories/infrastructure-and-security.mdx @@ -1,18 +1,20 @@ --- title: Warp Factories infrastructure and security description: >- - Warp Factories separate control and execution planes so teams can choose - hosting, inference, storage, secret, and governance controls. + Warp Factories separates coordination from execution so your team controls + hosting, inference, storage, and credentials. sidebar: label: "Infrastructure & security" --- -Warp Factories separate coordination from execution. Your team can choose where a factory runs code, which supported providers serve model requests, where supported factory data is stored, and which credentials each agent receives. Available controls depend on your team's configuration and agreement with Warp. +Warp Factories separates coordination from execution: Warp coordinates the work, and your team chooses the infrastructure the work runs on. You decide where a factory runs code, which model providers serve its inference requests, where run data such as transcripts and artifacts is stored, and which credentials each agent receives. Not every option is available to every team: managed self-hosted execution and customer-supplied inference require an Enterprise plan, and Warp enables customer-owned storage for eligible teams. ## Control plane and execution plane +Every factory splits responsibilities across two planes: + * **Control plane** - Warp coordinates runs, identity and configuration, observability, integrations, storage, and inference routing. -* **Execution plane** - A Warp-hosted sandbox or managed self-hosted worker checks out code, runs setup, invokes tools, builds the project, and executes commands. +* **Execution plane** - A Warp-hosted sandbox or a managed self-hosted worker checks out code, runs setup, invokes tools, builds the project, and executes commands. ```mermaid flowchart LR @@ -25,71 +27,90 @@ flowchart LR C --> D["Warp or supported
customer-owned storage"] ``` -Managed self-hosting changes the execution boundary; it does not remove Warp from orchestration. On managed self-hosted compute, the repository checkout, command execution, and sandbox filesystem stay on customer infrastructure. Content included in prompts, results, transcripts, attachments, artifacts, or telemetry can still flow through Warp and configured providers. Customer-owned provider and storage options change their corresponding paths, not the existence of the control plane. See [deployment patterns](../platform/deployment-patterns) and [self-hosting security and networking](../platform/self-hosting/security-and-networking) for the broader data model. +Self-hosting moves the execution plane onto your infrastructure; it does not remove Warp from coordination. With a managed self-hosted worker, repository checkouts, command execution, and the sandbox filesystem stay on machines you control, but content that enters prompts, results, transcripts, attachments, artifacts, or telemetry still flows through Warp and the providers you configure. In the same way, customer-supplied inference and customer-owned storage redirect those specific data paths without changing how runs are coordinated. See [deployment patterns](../platform/deployment-patterns) and [self-hosting security and networking](../platform/self-hosting/security-and-networking) for the broader data model. ## Environments and runners +Two configurations define where and how a factory's agents work: + | Configuration | Defines | Typical contents | | --- | --- | --- | -| **Environment** | Workspace and runtime context | Repositories, setup, secrets, toolchain image, and provider configuration | -| Runner | Execution compute | Operating system, architecture, sandbox image, vCPUs, and memory | +| **Environment** | What an agent works on: the workspace and runtime context | Repositories, setup commands, secrets, toolchain image, and provider configuration | +| **Runner** | Where the work executes: the compute | Operating system, architecture, sandbox image, vCPUs, and memory | -A run can select a runner explicitly. Otherwise, Warp uses the environment's configured execution defaults and ultimately the system default. Use [environments](../platform/environments) to define the workspace and the [runner reference](../platform/runners) for compute and resolution behavior. A factory references both through its [definition as code](./factory-as-code). +When a run starts, Warp resolves its compute in a fixed order: the runner the run selects explicitly, then the environment's execution defaults, then the system default. Use [environments](../platform/environments) to define the workspace and the [runner reference](../platform/runners) for compute options and resolution behavior. A factory references both through its [definition as code](./factory-as-code). -In the control room, the [Runners surface](../platform/runners) shows each runner's default status, operating system and architecture, setup commands, and size. For an externally source-managed factory, `runners/*.yaml` remains the source of truth and edits open in the connected repository. With Warp-managed source, authorized users can create and edit runner files in the control room. +The **Runners** page in the control room shows each runner's operating system and architecture, setup commands, size, and whether it's the default. Where you edit runners depends on where the factory's source lives: -Warp-hosted instance shapes are limited by your team's plan. Warp rejects a hosted shape above that limit. Managed self-hosted runners are exempt from the hosted size limit because your team supplies the compute. See the [runner reference](../platform/runners) for configuration details. +* **Externally managed source** - The `runners/*.yaml` files in the connected repository are the source of truth, and edits open in that repository. +* **Warp-managed source** - Authorized users create and edit runner files directly in the control room. + +Your team's plan sets the maximum instance shape (vCPUs and memory) for Warp-hosted runners, and Warp rejects hosted shapes above that limit. Managed self-hosted runners are exempt from the hosted size limit because your team supplies the compute. See the [runner reference](../platform/runners) for configuration details. ## Choose an execution host -A factory can select Warp-hosted compute or a managed self-hosted worker as its execution host. +A factory runs its work on one of two execution hosts: Warp-hosted compute or a managed self-hosted worker. | Decision area | Warp-hosted | Managed self-hosted | | --- | --- | --- | -| Compute | Warp provisions the sandbox | Your team provisions the worker | -| **Checkout and commands** | Run on Warp-managed compute | Run on customer-managed compute | +| **Compute** | Warp provisions the sandbox | Your team provisions the worker | +| **Checkout and commands** | Run on Warp-managed compute | Run on your infrastructure | | **Control plane** | Runs through Warp | Runs through Warp | -| Network | Warp manages sandbox connectivity | Outbound connection to Warp; no inbound firewall port | -| **Private services** | Must be reachable from the hosted sandbox | Uses the worker's network access | -| Operations | Warp manages capacity and lifecycle | Your team manages capacity, isolation, updates, and availability | +| **Network** | Warp manages sandbox connectivity | The worker connects outbound to Warp; no inbound firewall port | +| **Private services** | Must be reachable from the hosted sandbox | Reachable through the worker's network access | +| **Operations** | Warp manages capacity and lifecycle | Your team manages capacity, isolation, updates, and availability | + +Managed self-hosted execution is available to eligible Enterprise teams. To route factory work to a worker: -Managed self-hosted execution is available to eligible Enterprise teams. Supported worker implementations include `linux/amd64` and `linux/arm64`; each worker implementation determines workload compatibility. Workers authenticate to Warp with a supported principal. Select a managed self-hosted worker with [`workerHost` in the factory definition](./factory-as-code), use a compatible runner, and review the [self-hosting requirements](../platform/self-hosting/) before routing factory work. Unmanaged and other CLI agents are not selectable factory execution hosts, but they can exchange work with a factory through [Factory MCP](./factory-mcp). Do not treat self-hosting as a guarantee that all factory data stays in your network. +1. **Deploy a worker** - Review the [self-hosting requirements](../platform/self-hosting/), then connect a worker that authenticates to Warp with an agent API key. Workers run on `linux/amd64` and `linux/arm64`, and the worker's platform determines which workloads it can run. +2. **Pair it with a compatible runner** - Choose a runner that matches the worker's platform. +3. **Select the worker in the factory definition** - Set [`workerHost`](./factory-as-code) so the factory routes work to it. + +Unmanaged self-hosted agents and other CLI agents can't serve as a factory's execution host, but they can exchange work with a factory through [Factory MCP](./factory-mcp). + +:::caution +Self-hosting is not a guarantee that all factory data stays in your network. Execution stays on your infrastructure, but run content still flows through Warp and your configured providers as described above. +::: ## Choose execution, inference, and storage independently -| Team choice | Boundary changed | What remains in the Warp path | +Execution, inference, and storage are three separate decisions, and choosing one does not constrain the others. Each choice moves one boundary and leaves the rest of the run flow with Warp: + +| Team choice | What it changes | What stays with Warp | | --- | --- | --- | -| **Warp-hosted or managed self-hosted execution** | Where checkout, commands, and the sandbox filesystem run | Coordination, configuration, observability, and inference routing | -| **Warp-managed or customer-supplied inference** | Provider account, model routing, billing, and provider-side retention | Run coordination and inference routing | -| **Warp or customer-owned storage** | Persistence for supported transcripts, artifacts, and run attachments | Orchestration, the write path, and other factory and control-plane state | +| **Execution**: Warp-hosted or managed self-hosted | Where checkout, commands, and the sandbox filesystem run | Coordination, configuration, observability, and inference routing | +| **Inference**: Warp-managed or customer-supplied | The provider account, model routing, billing, and provider-side retention | Run coordination and inference routing | +| **Storage**: Warp or customer-owned | Where supported transcripts, artifacts, and run attachments persist | Orchestration, the write path, and other factory and control-plane state | -Cloud-agent inference supports team-managed first-party model credentials, AWS Bedrock, and OpenAI-compatible custom endpoints. Gemini Enterprise (Vertex AI) supports interactive sessions only and is not available to cloud agents. Provider-side retention follows your provider account and contract; Warp does not expose a retention toggle for that provider. Review [team-managed model keys and endpoints](../enterprise/enterprise-features/team-managed-keys-and-endpoints), [Bring Your Own LLM](../enterprise/enterprise-features/bring-your-own-llm), and the [security overview](../enterprise/security-and-compliance/security-overview). +Factory runs execute as cloud agents, so customer-supplied inference follows cloud-agent support: team-managed first-party model keys, AWS Bedrock, and OpenAI-compatible custom endpoints. Gemini Enterprise (Vertex AI) supports interactive sessions only and isn't available to cloud agents. When you supply the provider, provider-side retention follows your provider account and contract; Warp can't configure or enforce it for you. Review [team-managed model keys and endpoints](../enterprise/enterprise-features/team-managed-keys-and-endpoints), [Bring Your Own LLM](../enterprise/enterprise-features/bring-your-own-llm), and the [security overview](../enterprise/security-and-compliance/security-overview). -Eligible teams can use customer-owned Amazon S3 or Google Cloud Storage for the supported data classes in the table. Warp writes the applicable data to the configured bucket. Your team owns its access and lifecycle policies, but customer-owned storage does not move all factory state into your account. +For storage, eligible teams can keep the supported data classes above (transcripts, artifacts, and run attachments) in a customer-owned Amazon S3 or Google Cloud Storage bucket. Warp writes the applicable data to the bucket you configure, and your team owns the bucket's access and lifecycle policies. Customer-owned storage doesn't move all factory state into your account: configuration, run metadata, and other control-plane state stay with Warp. ## Credential boundaries -| Credential | Where it applies | Boundary | +A factory handles four kinds of credentials, each with its own boundary: + +| Credential | Used for | Boundary | | --- | --- | --- | -| **Inference credentials** | Model provider requests | Remain at the inference boundary and are not injected into the sandbox | -| **Execution secrets** | APIs, package registries, and tools used by an agent | Explicit per-agent allowlist; non-user factory agents default to no managed secrets | -| **Harness authentication** | Third-party harnesses such as Claude Code or Codex | Separate from the agent's general secret allowlist | -| **Repository identity** | Checkout and code-forge changes | User authorization for creator attribution or a team executor identity for unattended work | +| **Inference credentials** | Model provider requests | Used only at the inference boundary; never injected into the sandbox | +| **Execution secrets** | APIs, package registries, and tools an agent uses | Delivered from an explicit per-agent allowlist; factory agents that don't act as a specific user receive no managed secrets by default | +| **Harness authentication** | Third-party harnesses such as Claude Code or Codex | Configured separately from the agent's secret allowlist | +| **Repository identity** | Checking out code and pushing changes | Runs act with the creating user's authorization (changes are attributed to them) or as a team executor identity for unattended work | -Restrict each credential to the resources and actions its agent needs. Warp redacts known secret values at output boundaries, but redaction does not replace narrow external permissions or rotation. See [cloud agent secrets](../platform/secrets), [harness authentication](../platform/harnesses/authentication), [secret redaction](../support-and-community/privacy-and-security/secret-redaction), and [team identity](../platform/team-access-billing-and-identity) for the underlying controls. +Scope each credential to the resources and actions its agent needs. Warp redacts known secret values at output boundaries, but redaction is a backstop, not a substitute for narrow external permissions and rotation. See [cloud agent secrets](../platform/secrets), [harness authentication](../platform/harnesses/authentication), [secret redaction](../support-and-community/privacy-and-security/secret-redaction), and [team identity](../platform/team-access-billing-and-identity) for the underlying controls. ## Governance and metering -Team Owners and Admins control factory definitions, environments, runners, secrets, and provider configuration through existing [team roles](../enterprise/team-management/roles-and-permissions). Warp Factories does not add a factory-specific approval role. Specification review and merge approval remain workflow and repository policy decisions. Review factory-definition changes as operational code and keep merge access with the people responsible for shipping. +Factories use your existing [team roles](../enterprise/team-management/roles-and-permissions): Team Owners and Admins control factory definitions, environments, runners, secrets, and provider configuration. Warp Factories doesn't add a factory-specific approval role, so who reviews specifications and who approves merges stays a workflow and repository policy decision. Treat factory-definition changes as operational code: review them like any other change, and keep merge access with the people responsible for shipping. -Warp meters hosted compute, Warp-provided inference, and platform services. Your team supplies managed self-hosted compute. Customer-supplied providers bill model usage through the applicable provider account, while platform services can still consume credits. See [platform credits](../support-and-community/plans-and-billing/platform-credits) for the current model. +Warp meters hosted compute, Warp-provided inference, and platform services. Your infrastructure choices shift the corresponding bill: your team supplies managed self-hosted compute, and customer-supplied providers bill model usage through your provider account. Platform services can still consume credits regardless of those choices. See [platform credits](../support-and-community/plans-and-billing/platform-credits) for the current model. ## Deployment checklist 1. **Classify the workload** - Identify the repositories, data, internal services, and regulated systems the factory can reach. 2. **Choose execution** - Decide where checkout, commands, and the sandbox filesystem must run. -3. **Define environments and runners** - Set repositories, setup, secrets, operating system, architecture, image, and compute. -4. **Choose inference and storage** - Select provider routing and persistence for supported data. +3. **Define environments and runners** - Set repositories, setup commands, secrets, operating system, architecture, image, and compute. +4. **Choose inference and storage** - Select provider routing and where supported run data persists. 5. **Scope credentials** - Set each agent's secret allowlist, harness authentication, and repository identity. -6. **Set human gates** - Define specification and pull request review in workflow and repository policy. +6. **Set review gates** - Decide where humans review specifications and pull requests, and enforce those gates in workflow and repository policy. 7. **Validate operations** - Test network egress, isolation, rotation, redaction, capacity, observability, and metering before increasing volume. diff --git a/src/content/docs/platform/self-hosting/index.mdx b/src/content/docs/platform/self-hosting/index.mdx index 8faf7726..6e345590 100644 --- a/src/content/docs/platform/self-hosting/index.mdx +++ b/src/content/docs/platform/self-hosting/index.mdx @@ -52,7 +52,7 @@ With any self-hosted architecture: * **Resource limits are controlled by your infrastructure** — Concurrency and compute are only limited by the machines you provision, not by Warp. :::note -Enterprise teams that need full control over LLM inference routing can use [Bring Your Own LLM (BYOLLM)](/enterprise/enterprise-features/bring-your-own-llm/) to route inference through their own cloud provider accounts. AWS Bedrock supports interactive sessions and cloud agents. Gemini Enterprise supports interactive sessions only and is not available to cloud agents. +Enterprise teams that need full control over LLM inference routing can use [Bring Your Own LLM (BYOLLM)](/enterprise/enterprise-features/bring-your-own-llm/) to route inference through their own cloud provider accounts. AWS Bedrock works for both interactive sessions and cloud agents; Gemini Enterprise works for interactive sessions only, not cloud agents. ::: --- diff --git a/src/content/docs/platform/self-hosting/security-and-networking.mdx b/src/content/docs/platform/self-hosting/security-and-networking.mdx index 7b0662e6..f06c3e1e 100644 --- a/src/content/docs/platform/self-hosting/security-and-networking.mdx +++ b/src/content/docs/platform/self-hosting/security-and-networking.mdx @@ -29,7 +29,7 @@ Self-hosted execution keeps repository clones, source files, build artifacts, ru * LLM inference requests and responses, which include code context from the agent's interactions. :::note -While repositories are cloned and stored only on your infrastructure, code content can appear in session transcripts, artifacts, and LLM prompts as part of normal agent operation. Warp stores applicable orchestration and conversation data according to your product configuration and agreement. When you use Warp-managed inference, contracted model providers process requests under Warp's [Zero Data Retention (ZDR)](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) agreements. Customer-supplied inference follows the provider agreement configured by your team. +Repositories are cloned and stored only on your infrastructure, but code content can still appear in session transcripts, artifacts, and LLM prompts as part of normal agent operation. Warp stores orchestration and conversation data; exactly what is stored, and for how long, depends on your team's configuration and agreement with Warp. On the inference side, retention depends on who supplies the provider: with Warp-managed inference, contracted model providers process requests under Warp's [Zero Data Retention (ZDR)](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) agreements; with customer-supplied inference, retention follows your team's agreement with that provider. ::: --- @@ -102,7 +102,7 @@ See [GitLab](/platform/integrations/gitlab/) and [Bitbucket](/platform/integrati ## LLM inference and BYOLLM -LLM inference routes through Warp's backend. Warp-managed inference uses contracted providers with [ZDR](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) agreements. Enterprise teams can use [team-managed model keys and endpoints](/enterprise/enterprise-features/team-managed-keys-and-endpoints/) for supported cloud-agent providers, including AWS Bedrock. Gemini Enterprise through Google Vertex AI currently applies to interactive agents rather than cloud agents. +LLM inference routes through Warp's backend. With Warp-managed inference, requests go to contracted providers covered by [ZDR](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) agreements. Enterprise 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/) with supported cloud-agent providers, including AWS Bedrock. Gemini Enterprise (through Google Vertex AI) currently supports interactive agents only, not cloud agents. --- From 5c3aae56fcd0bdfc5a522f9176bd6bfbb50a8944 Mon Sep 17 00:00:00 2001 From: hongyi-chen Date: Sun, 16 Aug 2026 05:10:31 +0000 Subject: [PATCH 3/5] docs(factories): restore benefit-led description without 'data exhaust' Per feedback, bring back the original ownership framing for the page description, replacing "data exhaust" with "run data" and using the singular verb to match the page prose. Co-Authored-By: Warp --- src/content/docs/factories/infrastructure-and-security.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/content/docs/factories/infrastructure-and-security.mdx b/src/content/docs/factories/infrastructure-and-security.mdx index 3bf42dba..5ed7a6ba 100644 --- a/src/content/docs/factories/infrastructure-and-security.mdx +++ b/src/content/docs/factories/infrastructure-and-security.mdx @@ -1,8 +1,8 @@ --- title: Warp Factories infrastructure and security description: >- - Warp Factories separates coordination from execution so your team controls - hosting, inference, storage, and credentials. + Warp Factories gives you control over inference, hosting, and run data so + you own your factory's infrastructure and outputs. sidebar: label: "Infrastructure & security" --- From b8c5fc56b0cedd45dc544f70b8d4dd4e7079d225 Mon Sep 17 00:00:00 2001 From: hongyi-chen Date: Sun, 16 Aug 2026 05:19:42 +0000 Subject: [PATCH 4/5] docs(factories): move plan gating into a note callout and trim redundancy - Plan/eligibility gating moves from the intro paragraph into a :::note. - Dedupe restatements of "run content still flows through Warp": the post-diagram paragraph carries the detail once, and the caution and independence lead-in each shrink to one sentence. - Drop the duplicate runner-reference link and the section sentence now covered by the callout (kept as a short parenthetical). Co-Authored-By: Warp --- .../factories/infrastructure-and-security.mdx | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/src/content/docs/factories/infrastructure-and-security.mdx b/src/content/docs/factories/infrastructure-and-security.mdx index 5ed7a6ba..0bb2b55d 100644 --- a/src/content/docs/factories/infrastructure-and-security.mdx +++ b/src/content/docs/factories/infrastructure-and-security.mdx @@ -7,7 +7,11 @@ sidebar: label: "Infrastructure & security" --- -Warp Factories separates coordination from execution: Warp coordinates the work, and your team chooses the infrastructure the work runs on. You decide where a factory runs code, which model providers serve its inference requests, where run data such as transcripts and artifacts is stored, and which credentials each agent receives. Not every option is available to every team: managed self-hosted execution and customer-supplied inference require an Enterprise plan, and Warp enables customer-owned storage for eligible teams. +Warp Factories separates coordination from execution: Warp coordinates the work, and your team chooses the infrastructure it runs on. You decide where a factory runs code, which model providers serve its inference requests, where run data such as transcripts and artifacts is stored, and which credentials each agent receives. + +:::note +Managed self-hosted execution and customer-supplied inference require an Enterprise plan. Warp enables customer-owned storage for eligible teams. +::: ## Control plane and execution plane @@ -27,7 +31,7 @@ flowchart LR C --> D["Warp or supported
customer-owned storage"] ``` -Self-hosting moves the execution plane onto your infrastructure; it does not remove Warp from coordination. With a managed self-hosted worker, repository checkouts, command execution, and the sandbox filesystem stay on machines you control, but content that enters prompts, results, transcripts, attachments, artifacts, or telemetry still flows through Warp and the providers you configure. In the same way, customer-supplied inference and customer-owned storage redirect those specific data paths without changing how runs are coordinated. See [deployment patterns](../platform/deployment-patterns) and [self-hosting security and networking](../platform/self-hosting/security-and-networking) for the broader data model. +Self-hosting moves only the execution plane: with a managed self-hosted worker, repository checkouts, command execution, and the sandbox filesystem stay on machines you control, but content that enters prompts, results, transcripts, attachments, artifacts, or telemetry still flows through Warp and the providers you configure. See [deployment patterns](../platform/deployment-patterns) and [self-hosting security and networking](../platform/self-hosting/security-and-networking) for the broader data model. ## Environments and runners @@ -38,14 +42,14 @@ Two configurations define where and how a factory's agents work: | **Environment** | What an agent works on: the workspace and runtime context | Repositories, setup commands, secrets, toolchain image, and provider configuration | | **Runner** | Where the work executes: the compute | Operating system, architecture, sandbox image, vCPUs, and memory | -When a run starts, Warp resolves its compute in a fixed order: the runner the run selects explicitly, then the environment's execution defaults, then the system default. Use [environments](../platform/environments) to define the workspace and the [runner reference](../platform/runners) for compute options and resolution behavior. A factory references both through its [definition as code](./factory-as-code). +When a run starts, Warp resolves its compute in a fixed order: the runner the run selects explicitly, then the environment's execution defaults, then the system default. Use [environments](../platform/environments) to define the workspace; see the [runner reference](../platform/runners) for compute options and resolution behavior. A factory references both through its [definition as code](./factory-as-code). The **Runners** page in the control room shows each runner's operating system and architecture, setup commands, size, and whether it's the default. Where you edit runners depends on where the factory's source lives: * **Externally managed source** - The `runners/*.yaml` files in the connected repository are the source of truth, and edits open in that repository. * **Warp-managed source** - Authorized users create and edit runner files directly in the control room. -Your team's plan sets the maximum instance shape (vCPUs and memory) for Warp-hosted runners, and Warp rejects hosted shapes above that limit. Managed self-hosted runners are exempt from the hosted size limit because your team supplies the compute. See the [runner reference](../platform/runners) for configuration details. +Your team's plan sets the maximum instance shape (vCPUs and memory) for Warp-hosted runners, and Warp rejects hosted shapes above that limit. Managed self-hosted runners are exempt because your team supplies the compute. ## Choose an execution host @@ -60,7 +64,7 @@ A factory runs its work on one of two execution hosts: Warp-hosted compute or a | **Private services** | Must be reachable from the hosted sandbox | Reachable through the worker's network access | | **Operations** | Warp manages capacity and lifecycle | Your team manages capacity, isolation, updates, and availability | -Managed self-hosted execution is available to eligible Enterprise teams. To route factory work to a worker: +To route factory work to a managed self-hosted worker (an Enterprise feature): 1. **Deploy a worker** - Review the [self-hosting requirements](../platform/self-hosting/), then connect a worker that authenticates to Warp with an agent API key. Workers run on `linux/amd64` and `linux/arm64`, and the worker's platform determines which workloads it can run. 2. **Pair it with a compatible runner** - Choose a runner that matches the worker's platform. @@ -69,12 +73,12 @@ Managed self-hosted execution is available to eligible Enterprise teams. To rout Unmanaged self-hosted agents and other CLI agents can't serve as a factory's execution host, but they can exchange work with a factory through [Factory MCP](./factory-mcp). :::caution -Self-hosting is not a guarantee that all factory data stays in your network. Execution stays on your infrastructure, but run content still flows through Warp and your configured providers as described above. +Self-hosting is not a guarantee that all factory data stays in your network: run content still flows through Warp and your configured providers. ::: ## Choose execution, inference, and storage independently -Execution, inference, and storage are three separate decisions, and choosing one does not constrain the others. Each choice moves one boundary and leaves the rest of the run flow with Warp: +Execution, inference, and storage are independent choices: each moves one boundary and leaves the rest of the run flow with Warp. | Team choice | What it changes | What stays with Warp | | --- | --- | --- | From a57f26f5607316c5a13201ba2f0f49d1b8a355f3 Mon Sep 17 00:00:00 2001 From: hongyi-chen Date: Sun, 16 Aug 2026 22:37:10 +0000 Subject: [PATCH 5/5] docs(factories): address infrastructure and security review feedback - Replace the coordination/execution opener with plain language that leads with infrastructure flexibility - Move the Enterprise plan gating note down next to the execution, inference, and storage choices - Rename the 'Typical contents' table column to 'Key settings' - Link the control room mention to the control room page - Drop the redundant self-hosting caution (covered by the data-flow section) - Link 'cloud agents' to the cloud agents overview - Make the metering paragraph matter-of-fact - Keep provider-specific support (Bedrock, Gemini Enterprise) on the provider pages instead of the self-hosting index and security pages - Restore the ZDR reference on 'Routes through Warp's backend' and shorten the retention note by moving the customer-supplied inference detail into the LLM inference and BYOLLM section Co-Authored-By: Warp --- .../factories/infrastructure-and-security.mdx | 22 ++++++++----------- .../docs/platform/self-hosting/index.mdx | 2 +- .../self-hosting/security-and-networking.mdx | 6 ++--- 3 files changed, 13 insertions(+), 17 deletions(-) diff --git a/src/content/docs/factories/infrastructure-and-security.mdx b/src/content/docs/factories/infrastructure-and-security.mdx index 0bb2b55d..655cf362 100644 --- a/src/content/docs/factories/infrastructure-and-security.mdx +++ b/src/content/docs/factories/infrastructure-and-security.mdx @@ -7,11 +7,7 @@ sidebar: label: "Infrastructure & security" --- -Warp Factories separates coordination from execution: Warp coordinates the work, and your team chooses the infrastructure it runs on. You decide where a factory runs code, which model providers serve its inference requests, where run data such as transcripts and artifacts is stored, and which credentials each agent receives. - -:::note -Managed self-hosted execution and customer-supplied inference require an Enterprise plan. Warp enables customer-owned storage for eligible teams. -::: +Warp Factories runs on the infrastructure your team chooses. You decide where a factory runs code, which model providers serve its inference requests, where run data such as transcripts and artifacts is stored, and which credentials each agent receives. Warp coordinates the work the same way regardless of these choices. ## Control plane and execution plane @@ -37,14 +33,14 @@ Self-hosting moves only the execution plane: with a managed self-hosted worker, Two configurations define where and how a factory's agents work: -| Configuration | Defines | Typical contents | +| Configuration | Defines | Key settings | | --- | --- | --- | | **Environment** | What an agent works on: the workspace and runtime context | Repositories, setup commands, secrets, toolchain image, and provider configuration | | **Runner** | Where the work executes: the compute | Operating system, architecture, sandbox image, vCPUs, and memory | When a run starts, Warp resolves its compute in a fixed order: the runner the run selects explicitly, then the environment's execution defaults, then the system default. Use [environments](../platform/environments) to define the workspace; see the [runner reference](../platform/runners) for compute options and resolution behavior. A factory references both through its [definition as code](./factory-as-code). -The **Runners** page in the control room shows each runner's operating system and architecture, setup commands, size, and whether it's the default. Where you edit runners depends on where the factory's source lives: +The **Runners** page in the [control room](./control-room) shows each runner's operating system and architecture, setup commands, size, and whether it's the default. Where you edit runners depends on where the factory's source lives: * **Externally managed source** - The `runners/*.yaml` files in the connected repository are the source of truth, and edits open in that repository. * **Warp-managed source** - Authorized users create and edit runner files directly in the control room. @@ -72,10 +68,6 @@ To route factory work to a managed self-hosted worker (an Enterprise feature): Unmanaged self-hosted agents and other CLI agents can't serve as a factory's execution host, but they can exchange work with a factory through [Factory MCP](./factory-mcp). -:::caution -Self-hosting is not a guarantee that all factory data stays in your network: run content still flows through Warp and your configured providers. -::: - ## Choose execution, inference, and storage independently Execution, inference, and storage are independent choices: each moves one boundary and leaves the rest of the run flow with Warp. @@ -86,7 +78,11 @@ Execution, inference, and storage are independent choices: each moves one bounda | **Inference**: Warp-managed or customer-supplied | The provider account, model routing, billing, and provider-side retention | Run coordination and inference routing | | **Storage**: Warp or customer-owned | Where supported transcripts, artifacts, and run attachments persist | Orchestration, the write path, and other factory and control-plane state | -Factory runs execute as cloud agents, so customer-supplied inference follows cloud-agent support: team-managed first-party model keys, AWS Bedrock, and OpenAI-compatible custom endpoints. Gemini Enterprise (Vertex AI) supports interactive sessions only and isn't available to cloud agents. When you supply the provider, provider-side retention follows your provider account and contract; Warp can't configure or enforce it for you. Review [team-managed model keys and endpoints](../enterprise/enterprise-features/team-managed-keys-and-endpoints), [Bring Your Own LLM](../enterprise/enterprise-features/bring-your-own-llm), and the [security overview](../enterprise/security-and-compliance/security-overview). +:::note +Managed self-hosted execution and customer-supplied inference require an Enterprise plan. Warp enables customer-owned storage for eligible teams. +::: + +Factory runs execute as [cloud agents](../platform/), so customer-supplied inference is limited to providers that support cloud agents. See [team-managed model keys and endpoints](../enterprise/enterprise-features/team-managed-keys-and-endpoints) and [Bring Your Own LLM](../enterprise/enterprise-features/bring-your-own-llm) for the supported providers. When you supply the provider, provider-side retention follows your provider account and contract; Warp can't configure or enforce it for you. The [security overview](../enterprise/security-and-compliance/security-overview) covers Warp's broader data handling. For storage, eligible teams can keep the supported data classes above (transcripts, artifacts, and run attachments) in a customer-owned Amazon S3 or Google Cloud Storage bucket. Warp writes the applicable data to the bucket you configure, and your team owns the bucket's access and lifecycle policies. Customer-owned storage doesn't move all factory state into your account: configuration, run metadata, and other control-plane state stay with Warp. @@ -107,7 +103,7 @@ Scope each credential to the resources and actions its agent needs. Warp redacts Factories use your existing [team roles](../enterprise/team-management/roles-and-permissions): Team Owners and Admins control factory definitions, environments, runners, secrets, and provider configuration. Warp Factories doesn't add a factory-specific approval role, so who reviews specifications and who approves merges stays a workflow and repository policy decision. Treat factory-definition changes as operational code: review them like any other change, and keep merge access with the people responsible for shipping. -Warp meters hosted compute, Warp-provided inference, and platform services. Your infrastructure choices shift the corresponding bill: your team supplies managed self-hosted compute, and customer-supplied providers bill model usage through your provider account. Platform services can still consume credits regardless of those choices. See [platform credits](../support-and-community/plans-and-billing/platform-credits) for the current model. +Warp meters hosted compute, Warp-provided inference, and platform services. Managed self-hosted execution moves compute costs to your own infrastructure, and customer-supplied inference bills model usage through your provider account. Platform services consume credits regardless of these choices. See [platform credits](../support-and-community/plans-and-billing/platform-credits) for details. ## Deployment checklist diff --git a/src/content/docs/platform/self-hosting/index.mdx b/src/content/docs/platform/self-hosting/index.mdx index 6e345590..28f514c6 100644 --- a/src/content/docs/platform/self-hosting/index.mdx +++ b/src/content/docs/platform/self-hosting/index.mdx @@ -52,7 +52,7 @@ With any self-hosted architecture: * **Resource limits are controlled by your infrastructure** — Concurrency and compute are only limited by the machines you provision, not by Warp. :::note -Enterprise teams that need full control over LLM inference routing can use [Bring Your Own LLM (BYOLLM)](/enterprise/enterprise-features/bring-your-own-llm/) to route inference through their own cloud provider accounts. AWS Bedrock works for both interactive sessions and cloud agents; Gemini Enterprise works for interactive sessions only, not cloud agents. +Enterprise teams that need full control over LLM inference routing can use [Bring Your Own LLM (BYOLLM)](/enterprise/enterprise-features/bring-your-own-llm/) to route inference through their own cloud provider accounts. Cloud agent support varies by provider; see each provider's setup guide for details. ::: --- diff --git a/src/content/docs/platform/self-hosting/security-and-networking.mdx b/src/content/docs/platform/self-hosting/security-and-networking.mdx index f06c3e1e..8b9bee94 100644 --- a/src/content/docs/platform/self-hosting/security-and-networking.mdx +++ b/src/content/docs/platform/self-hosting/security-and-networking.mdx @@ -22,14 +22,14 @@ Self-hosted execution keeps repository clones, source files, build artifacts, ru * Runtime secrets and environment variables. * Container filesystem state (managed architecture) or host workspace (Direct backend / unmanaged). -**Routes through Warp's backend:** +**Routes through Warp's backend** (under [Zero Data Retention (ZDR)](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr)): * Orchestration metadata (task status, lifecycle events). * Session transcripts, which include agent-generated summaries of code context, file contents the agent reads, and command output. * LLM inference requests and responses, which include code context from the agent's interactions. :::note -Repositories are cloned and stored only on your infrastructure, but code content can still appear in session transcripts, artifacts, and LLM prompts as part of normal agent operation. Warp stores orchestration and conversation data; exactly what is stored, and for how long, depends on your team's configuration and agreement with Warp. On the inference side, retention depends on who supplies the provider: with Warp-managed inference, contracted model providers process requests under Warp's [Zero Data Retention (ZDR)](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) agreements; with customer-supplied inference, retention follows your team's agreement with that provider. +Repositories are cloned and stored only on your infrastructure, but code content can still appear in session transcripts, artifacts, and LLM prompts as part of normal agent operation. Warp does not persistently store your source code or train on it. For retention with customer-supplied inference, see [LLM inference and BYOLLM](#llm-inference-and-byollm). ::: --- @@ -102,7 +102,7 @@ See [GitLab](/platform/integrations/gitlab/) and [Bitbucket](/platform/integrati ## LLM inference and BYOLLM -LLM inference routes through Warp's backend. With Warp-managed inference, requests go to contracted providers covered by [ZDR](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) agreements. Enterprise 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/) with supported cloud-agent providers, including AWS Bedrock. Gemini Enterprise (through Google Vertex AI) currently supports interactive agents only, not cloud agents. +LLM inference routes through Warp's backend. 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. Enterprise 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/); cloud agent support varies by provider, so check each provider's page. ---