Skip to main content
Last Modified: October 9, 2026

​
Overview

Security and compliance are a shared responsibility between Kernel and the customer. This shared model helps relieve the customer’s operational burden as Kernel operates, manages, and secures the browser infrastructure platform, while customers retain responsibility for how they use the platform, manage their credentials, and handle the data they process through Kernel browser sessions.

​
Kernel’s Responsibility: Security of the Platform

Kernel is responsible for protecting the infrastructure and platform that delivers browser sessions to customers. This includes:
  • Unikernel Isolation — Operating and securing the Unikraft-based unikernel virtual machines that provide hypervisor-level isolation for every browser session
  • Compute and Networking Infrastructure — Securing the underlying servers, hypervisors, network fabric, and orchestration systems that run browser sessions
  • Platform Software — Maintaining and patching the Kernel platform, APIs, and control plane components
  • Encryption — Enforcing TLS 1.2+ for data in transit and AES-256 encryption for data at rest, with cloud provider key management and annual key rotation
  • Physical Security — Ensured through our cloud hosting providers, which maintain controls restricting unauthorized physical access and protecting against environmental threats
  • Monitoring and Incident Response — Continuous monitoring, logging, and alerting across production systems, with a defined incident response plan
  • Compliance — Maintaining certifications and pursuing audit readiness across applicable frameworks (see our Security Practices page for current compliance status)

​
Customer Responsibility: Security in the Platform

Customers are responsible for security within the browser sessions and integrations they operate on Kernel. This includes:
  • Access Credentials — Safeguarding API keys, authentication tokens, and any credentials used to interact with the Kernel platform or third-party services from within browser sessions
  • Automation Scripts and Code — Ensuring the security and correctness of the automation scripts, browser agents, and application code they deploy within Kernel browser sessions
  • Data Handling — Managing the classification, handling, and protection of any data they process, extract, or store through Kernel browser sessions, including compliance with applicable data protection regulations
  • Third-Party Integrations — Securing any third-party services, APIs, or applications that customers connect to from within their Kernel sessions
  • Account Security — Maintaining strong passwords, enabling multi-factor authentication on their Kernel accounts, and managing team member access appropriately

​
Shared Controls

Some security controls apply to both Kernel and the customer, each operating in their own context:

​
Restricting Agent Egress

Egress allowlists limit which destinations a browser session can reach, so an agent tricked by a prompt injection into sending data to an attacker’s server gets a refusal instead of a connection. Responsibility for this control is split:
  • Kernel enforces the allowlist — Kernel’s egress proxy refuses Chromium’s HTTP(S) and WebSocket requests to unlisted destinations, starting with the browser’s first request. On allowlisted browsers, Kernel also refuses CDP browser contexts that set their own proxy and rejects Chrome policies that can send traffic around the proxy. If Kernel can’t start a browser that enforces the allowlist, browser creation fails instead of starting the browser without it.
  • You control who can change it — Anyone holding your Kernel API credentials can replace or remove an allowlist, or create a browser without one. Set allowlists from your own code, and keep your API keys and the Kernel MCP server out of the constrained agent’s reach.
  • You control what runs inside the VM — Enforcement covers browser traffic through Kernel’s egress proxy, not all traffic leaving the browser VM. Code executing inside the VM can send traffic directly and disable the VM-side CDP restriction, so don’t give the constrained agent code execution inside the VM. Extensions with the proxy permission and destinations in network.private_hosts also aren’t filtered.
  • Pools keep the allowlist between leases — A browser pool can set an allowlist that applies to every browser it creates. When you release a browser for reuse, Kernel restores the pool’s current allowlist before handing it out again, or replaces the browser if it can’t safely restore and enforce that allowlist. Reuse still keeps cookies and other browser state, so release with reuse: false when the next lease mustn’t inherit the previous one’s state.
An allowlist isn’t full VM-level network isolation. Review its limitations before relying on it.

​
Session Lifecycle and Data Responsibility

Each Kernel browser session runs inside an ephemeral unikernel VM. When a session ends, the VM is destroyed along with all session data. Customers should be aware that:
  • Session data is ephemeral — Any data created within a browser session is destroyed when the session ends unless the customer explicitly exports or persists it
  • Customer-provided credentials — Any credentials or secrets injected into a browser session (e.g., login cookies, API keys) are the customer’s responsibility to manage and rotate
  • Exported data — Once data leaves the Kernel platform (via API responses, webhooks, or customer-managed storage), its protection becomes the customer’s responsibility

​
Learn More

For a deeper look at the security controls Kernel maintains across product, infrastructure, and organizational domains, see our Security Practices page. For questions about the shared responsibility model or our security program, contact security@kernel.sh.