Skip to content

Enterprise > Security and compliance

Security overview

Review Warp's data flows, telemetry settings, authentication, and deployment boundaries when evaluating security controls for your team.

Open in ChatGPT ↗
Ask ChatGPT about this page
Open in Claude ↗
Ask Claude about this page
Copied!

Warp provides controls for telemetry, authentication, and agent permissions. Review the data flows and deployment boundaries below when evaluating Warp for your organization.

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

  • Complete visibility - View exactly what telemetry is collected through our exhaustive telemetry table
  • Real-time monitoring - Use Warp’s 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 at warpdotdev/warp, so security teams can audit the codebase directly. See Contributing to Warp for the source repository and the security reporting process.

How data collection works by plan:

  • Free tier - Individual users can disable data collection in Settings > Privacy.
  • Paid teams - Team admins can enforce data collection settings for the entire team. Data collection is enabled by default.
  • Business and Enterprise - Team admins can enforce data collection settings for the entire team. Data collection is disabled by default.

Some models have provider-specific data retention requirements. For Enterprise teams, these models are off by default; a workspace admin must explicitly enable them in the Admin Panel.

Enterprise subscriptions also include:

  • Team-level enforcement - Admins configure data collection and telemetry policies for the entire organization through the Admin Panel
  • Secret redaction - Admins can enable Secret Redaction for the organization and configure patterns for sensitive data

When telemetry is enabled, Warp collects:

  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.

When data collection is disabled, Warp does not collect:

  • Personally identifiable information beyond user IDs and email addresses
  • Network traffic or external API calls

Users can opt out of telemetry individually:

  1. Navigate to Settings > Privacy.
  2. Toggle off Help improve Warp and/or Send crash reports.

With telemetry disabled, Warp stops collecting usage and interaction data for analytics purposes.

Team admins can enforce telemetry settings organization-wide through the Admin Panel. On Business and Enterprise plans, data collection is disabled by default.

  • 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 inference requests to LLM providers
  • BYOLLM - Requests are proxied through Warp’s servers to your cloud infrastructure, where inference runs
  • Team-managed API keys and endpoints - When an admin configures team-managed API 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 and can include code context from agent interactions.
  • 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

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 for details.

  • 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

Contact security@warp.dev for current assessment materials and their scope. See the Trust Center.

When using Warp’s hosted infrastructure:

  • Cloud provider - Hosted on GCP
  • Network isolation - Workloads run in isolated VPCs with strict network policies

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) - Session transcripts (which include code context from agent interactions), orchestration metadata, and LLM inference route through Warp’s servers

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.

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) for setup instructions, SCIM provisioning, account linking, and troubleshooting.

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 for details.

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

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

Route agent inference through your own cloud provider account:

  • 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
  • Billing control - Inference costs billed directly to your cloud account

See Bring Your Own LLM for configuration details.

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

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

If you discover a security vulnerability in Warp:

  1. Email 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 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