Kernel supplies cloud-hosted Chromium sessions for web agents and automation. Developers create a browser on demand, connect their code, and delete the session when the task is done.
What Kernel provides
A developer can create a browser through Kernel's API and connect over the Chrome DevTools Protocol (CDP) or WebDriver BiDi. Kernel also has a Playwright execution API, computer controls for screenshot-driven agents, and a hosted Model Context Protocol server.
The browser service supports headless and headful sessions. Profiles preserve cookies and browser storage between runs, while Live View and replays help people inspect what an automation did. Browser pools keep configured browsers ready for repeated work. Kernel's browser creation guide explains when to choose these options.
Kernel works much like Browserbase, another managed cloud-browser service. Its features serve more than scraping. Teams can use remote browsers for testing, account workflows, repetitive web operations, or agents that need to work through a visual interface.
What stealth mode changes
The word "stealth" needs careful reading here. Kernel applies anti-detection settings to its browsers by default. Its current stealth mode documentation says the optional mode adds a managed static ISP proxy and an automatic CAPTCHA solver. A customer can replace or disable those managed services.
Profiles affect browser state. Proxies affect network identity. Computer controls affect how input reaches the browser. These are separate variables, and they should not be collapsed into one generic "stealth browser" label.
For a target website, this means that a Kernel session can look different depending on the chosen control method, profile, and network route. A rule built around one fixed IP range or one JavaScript property is unlikely to describe every session.
How Kernel can reach a website
An agent may drive a Kernel browser with Playwright, send computer-control commands, or invoke browser tools over MCP. The resulting browser then makes requests to the target site. With a profile, a later run can reuse cookies and authenticated state from an earlier session.
That persistence is operationally useful, but it changes the risk for a protected site. Automation that reaches an authenticated workflow can do more than an anonymous page fetch. The policy should account for the resource, account state, request sequence, and declared purpose.
Why layered detection matters
Kernel documents browser configuration, proxy options, persistent profiles, and input methods designed to reduce common automation indicators. None of those features provides a universal signature that a website can safely treat as "Kernel."
Detection therefore has to look beyond one property. Connection and request evidence can be combined with browser observations and behavior across the session. This also reduces the chance of blocking an ordinary visitor merely because one signal resembles automation.
Centinel benchmark result
In our September 2026 benchmark, Centinel detected Kernel.
Identification is the start of the policy decision. Teams can observe an approved automation, limit it to specific resources, rate-limit a costly route, or block activity that violates the site's rules. Centinel bot management, the product tested in that benchmark, lets you make each of those choices per route. Test it against your own traffic.
What to check in your own traffic
For suspected Kernel traffic, review:
- whether the session is anonymous or reusing authenticated state;
- which application routes and browser actions repeat;
- whether IP, browser identity, or timing changes while the task stays the same;
- whether the activity belongs to an approved agent, test, or integration.
That session-level view is more useful than chasing one cloud-browser fingerprint.
How to detect browser automation provides a practical evidence matrix for this review.