> For the complete documentation index, see [llms.txt](https://docs.warp.dev/llms.txt).
> Markdown versions of each page are available by appending .md to any URL.

# Security overview

Review Warp's enterprise security architecture, organization controls, and deployment boundaries.

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](https://docs.warp.dev/support-and-community/privacy-and-security/privacy/#provider-retention-analytics-and-storage).

## Transparency and control

Warp’s security philosophy centers on **transparency and developer control**:

-   **Complete visibility** - View exactly what telemetry is collected through our [exhaustive telemetry table](https://docs.warp.dev/support-and-community/privacy-and-security/privacy/#exhaustive-telemetry-table)
-   **Real-time monitoring** - Use Warp’s [Network Log](https://docs.warp.dev/support-and-community/privacy-and-security/network-log/) to monitor all network requests in real time
-   **Opt-out controls** - Disable telemetry and crash reporting at any time while retaining full functionality
-   **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](https://docs.warp.dev/support-and-community/community/contributing/) for the source repository and the security reporting process.

## Provider retention, analytics, and storage

### Zero Data Retention (ZDR)

Provider ZDR concerns what AI providers retain, not what Warp stores. See the [Warp-wide provider ZDR policy](https://docs.warp.dev/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](https://docs.warp.dev/agents/inference/model-choice/#models-requiring-provider-retention) lists the model exceptions.

### Warp analytics and improvement collection

Review [Warp’s analytics and improvement controls](https://docs.warp.dev/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](https://docs.warp.dev/enterprise/team-management/admin-panel/#privacy-settings).

### Product storage

See [product storage boundaries](https://docs.warp.dev/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](https://docs.warp.dev/factories/self-hosting/data-storage/) separately from execution hosting.

### Disabling telemetry

Follow [Privacy and data control](https://docs.warp.dev/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](https://docs.warp.dev/enterprise/team-management/admin-panel/#privacy-settings).

## Data handling and privacy

### Where your data lives

-   **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 provider account. See the [provider ZDR policy](https://docs.warp.dev/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](https://docs.warp.dev/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](https://docs.warp.dev/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](https://docs.warp.dev/factories/infrastructure-and-security/).

### Encryption

-   **In transit** - All data transmitted to Warp servers uses TLS 1.2 or higher
-   **At rest** - Warp encrypts all user data at rest using AES-256

### Secret redaction

When Secret Redaction is enabled, Warp masks matching sensitive information before sending terminal or AI content to LLM providers. Admins can configure patterns for:

-   API keys and tokens
-   Passwords and secrets
-   SSH keys and certificates
-   Custom secret patterns (configurable via Admin Panel)

Telemetry payload redaction is a separate mechanism. It applies built-in patterns to telemetry and includes user and Enterprise patterns when they are configured.

See [Secret Redaction documentation](https://docs.warp.dev/support-and-community/privacy-and-security/secret-redaction/) for details.

### Data retention

-   **Inference and product data** - See [provider retention](https://docs.warp.dev/support-and-community/privacy-and-security/privacy/#zero-data-retention-zdr) and [feature-specific storage](https://docs.warp.dev/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

## Compliance and certifications

### SOC 2 Type II

Warp is SOC 2 Type II certified, demonstrating compliance with industry-standard security controls for:

-   **Security** - Infrastructure protection, access controls, and monitoring
-   **Availability** - System uptime and disaster recovery
-   **Confidentiality** - Data protection and privacy controls
-   **Processing integrity** - Accurate, complete, and authorized processing

SOC 2 reports are available to Enterprise customers upon request.

## Infrastructure security

### Warp-hosted infrastructure

When using Warp’s hosted infrastructure:

-   **Cloud provider** - Hosted on GCP with SOC 2 and ISO 27001 certified datacenters
-   **Network isolation** - Workloads run in isolated VPCs with strict network policies

Warp’s operational security practices — including access controls, monitoring, and vulnerability management — are validated through SOC 2 Type II certification. See [Compliance and certifications](#compliance-and-certifications) for details.

### Self-hosted deployments

Enterprise teams can self-host cloud agent execution to control where agents run and keep repositories on their own infrastructure.

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](https://docs.warp.dev/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.
-   **Managed** - Run the `oz-agent-worker` daemon to let Warp orchestrate agents in isolated Docker containers on your infrastructure.

Agent runs are fully tracked and steerable in both modes. No inbound network access is required.

**Network egress requirements**

Self-hosted agents require outbound access to Warp’s backend services and, for the managed architecture, Docker Hub and GitHub.

## Access controls and authentication

### Single Sign-On (SSO)

Warp supports SSO via Okta, Microsoft Entra ID, Google Workspace, OneLogin, and any SAML 2.0 or OpenID Connect (OIDC) compatible provider. Admins can require SSO for all team members and enforce MFA through your identity provider.

See [Single Sign-On (SSO)](https://docs.warp.dev/enterprise/security-and-compliance/sso/) for setup instructions, SCIM provisioning, account linking, and troubleshooting.

### Team permissions

Warp uses role-based access control with three roles — Team Owner, Team Admin, and Member — to manage team access and Admin Panel privileges. See [User roles and permissions](https://docs.warp.dev/enterprise/getting-started/getting-started-enterprise/#user-roles-and-permissions) for details.

Resource sharing in Warp Drive has granular controls for who can view, edit, and share.

### Admin Panel governance

The Admin Panel gives security and IT teams centralized control over AI behavior, data handling, and sharing policies. Settings can be **enforced** (overriding individual user preferences organization-wide) or set to **respect user setting** (deferring to individual preferences).

Security-relevant controls include:

-   **Privacy** - Configure user-generated content (UGC) data collection, cloud conversation storage, and enterprise secret redaction
-   **Sharing** - Restrict or permit direct link sharing and “anyone with link” sharing permissions
-   **AI** - Configure AI autonomy settings and general agent behavior for the team
-   **Models** - Control which LLM models are available to team members, including BYOLLM routing through AWS Bedrock and Gemini Enterprise (Vertex AI)
-   **Platform** - Configure cloud agent access and settings

## Security features for developers

### Bring Your Own LLM (BYOLLM)

Route agent inference through your own cloud infrastructure for complete control:

-   **Data locality** - Interactive agent inference runs in your AWS account or Google Cloud project
-   **Cloud-native IAM** - Authenticate using your user’s existing identity and access management process
-   **No key storage** - Warp never stores your cloud credentials or API keys
-   **Billing control** - Inference costs billed directly to your cloud account

See [Bring Your Own LLM](https://docs.warp.dev/enterprise/enterprise-features/bring-your-own-llm/) for configuration details.

### Docker Sandboxes

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; saved snapshots and run data have separate storage behavior

### Agent permissions

Configure what agents can access and execute:

-   **Tool restrictions** - Enable/disable terminal use, code editing, web search, and file system access
-   **Repository scoping** - Limit agents to specific repositories or directories
-   **Execution approvals** - Require manual approval for sensitive commands
-   **Visibility** - When cloud conversation storage is enabled, agent actions are logged with full context for review

## Incident response and support

### Security issue reporting

If you discover a security vulnerability in Warp:

1.  Email [security@warp.dev](mailto:security@warp.dev).
2.  Include detailed steps to reproduce.
3.  Do not publicly disclose until Warp has addressed the issue.

Warp follows responsible disclosure practices and works with reporters to coordinate disclosure timelines.

### Enterprise support

Enterprise customers receive priority security support:

-   **Dedicated channels** - Private Slack/Teams channels for security questions
-   **Security advisories** - Proactive notifications of security updates
-   **Incident assistance** - Support during security incidents or breach investigations
-   **Compliance assistance** - Help with compliance questionnaires and audits

## 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](https://docs.warp.dev/enterprise/security-and-compliance/trust-center/) for details on requesting SOC 2 reports, subprocessors, and vendor security assessments.
-   [Warp subprocessors list](https://www.warp.dev/legal/subprocessors)
-   **Privacy documentation** - [Privacy guide](https://docs.warp.dev/support-and-community/privacy-and-security/privacy/) with complete telemetry table
-   **Contact** - [privacy@warp.dev](mailto:privacy@warp.dev) for privacy questions, [security@warp.dev](mailto:security@warp.dev) for security issues

Note

For vendor security assessments, compliance questionnaires, or access to SOC 2 reports, contact your account manager or email [security@warp.dev](mailto:security@warp.dev).