How to bypass bot detection for AI agents: stealth, proxies, and CAPTCHA solving in 2026

Last updated: August 19, 2026. Kernel capabilities and pricing verified against the Kernel docs on that date.

TL;DR: AI agents keep getting blocked because the browser they drive looks like a bot the moment it loads a page — wrong fingerprint, wrong IP, wrong TLS handshake, wrong behavior. Getting through modern anti-bot defenses takes a layered stack: a stealth-mode browser build, a driver that doesn't announce itself over the automation protocol, the right kind of proxy for the target (this one matters more than the rest combined), human-shaped interaction timing, a way to handle CAPTCHAs when you hit them, GPU-backed rendering for sites that fingerprint pixels, session profiles used deliberately rather than by reflex, and Web Bot Auth on the specific destinations that verify it. The fastest way to assemble all of that is Kernel — stealth builds, a managed CAPTCHA solver, five proxy types, headful and headful + GPU browsers, OS-level input, session profiles, and Web Bot Auth, all switchable per session on one runtime. Most of what follows is which of those levers actually moves the needle on which vendor, based on our own sensor research and A/B testing — including the ones that came back null.

Why your AI agent is getting blocked

Before you can bypass bot detection, it helps to know what's actually detecting you. Modern anti-bot stacks (Cloudflare, DataDome, PerimeterX / HUMAN, Kasada, hCaptcha, reCAPTCHA v3, Akamai Bot Manager) don't look for a single tell — they collect signals across six broad categories and combine them into a score. Fail enough of them and you get a challenge page, a 403, a silent 200 with poisoned content, or a shadowban that only shows up three requests later.

These are categories, not a pipeline. Vendors weight them very differently and there's no single sequence they fire in — one vendor's dominant signal is another's rounding error, and the same vendor can decide at the edge, in a page script, or asynchronously after the fact. The one ordering statement that does hold generally is that the network and transport layers can reject you before any JavaScript runs, which is why a fingerprint fix on a bad IP is often not even measurable.

The categories:

1. Network fingerprint. Your IP's ASN, geolocation, reputation history, and whether it's on a public datacenter block. Anything from AWS, GCP, Azure, DigitalOcean, or Hetzner is a red flag on its own. TLS and HTTP/2 SETTINGS frames also leak whether you're a real Chrome, a headless Chrome, or a Python requests call cosplaying as a browser. Chrome's TLS extension permutation — initially planned for Chrome 110 but observed in versions 108 and 109 — made order-sensitive JA3 fingerprints vary by connection (Fastly). JA4 resists that randomization by sorting extensions before hashing (Cloudflare), so a current Chromium build can produce a stable JA4 even when its JA3 changes.

2. Browser fingerprint. Navigator properties, WebGL vendor and renderer strings, canvas hashes, audio context hashes, installed fonts, screen resolution, device pixel ratio, timezone vs. IP geo mismatch, navigator.webdriver, plugin list shape, and headless-specific quirks. Vanilla Playwright and Puppeteer trip a dozen of these before you've clicked anything. Chrome's newer headless mode narrowed some of the classic gaps, but the specific properties are still read and cross-checked — vendors we've deobfuscated check navigator.plugins length, pdfViewerEnabled, and Notification.permission explicitly. What catches automated browsers most often isn't a missing property, it's an inconsistent one: a WebGL vendor that doesn't match the renderer, a desktop user agent reporting touch support, screen.availHeight equal to screen.height on a platform that always has a taskbar.

3. Behavioral signals. Mouse movement entropy, typing cadence, scroll pattern, dwell time on form fields, whether you focus an input before typing into it, whether you move the cursor to a button before clicking it. Agents that jump straight to page.click() on a coordinate look nothing like humans.

4. Challenge response. When the score is ambiguous, you get a CAPTCHA — hCaptcha, reCAPTCHA v2/v3/Enterprise, Cloudflare Turnstile, Arkose Labs FunCAPTCHA, DataDome interactive. Some are solvable programmatically; some require a real solver-in-the-loop; some (FunCAPTCHA) are deliberately expensive to defeat.

5. Session continuity. Cookies, localStorage, IndexedDB, service worker state, and site-issued tokens accumulate a "this is a returning visitor" signal. Sites with their own device-identity systems weight this heavily — arriving with none of their cookies is itself suspicious. But it cuts both ways, and the direction depends on whose history is accumulating: a scoring vendor that tracks your browser across sites can just as easily be carrying a negative history forward. See layer 7 of the stack below for the measurements.

6. Standards-based identity. The newest category: Web Bot Auth, which the IETF currently lists as an active working group with an approved charter, lets automated clients cryptographically sign their requests so cooperating destinations can verify the automation is legitimate rather than trying to detect it. Where your target verifies signatures and has allowlisted you, this flips the game from adversarial detection to authenticated allow-listing. Where it doesn't, signing can actively cost you — see layer 8 of the stack.

Getting through reliably means addressing every layer that applies to your target — not just one. A stealth browser with a datacenter IP still gets blocked. A great proxy with vanilla Playwright still gets blocked. A CAPTCHA solver with a headless browser still gets challenged repeatedly.

Different vendors read very different signals

The generic advice — "spoof canvas, spoof WebGL, spoof audio" — is wrong often enough to waste real time. We deobfuscate these sensor scripts as part of our own anti-detection work, and the surfaces diverge sharply. Some highlights from what the scripts actually read:

Two practical consequences. First, work out which vendor is in front of your target before you spend a week on canvas noise that vendor never reads. Second, the pre-JS layers matter more than most stealth guides admit: on some targets the IP is rejected before a line of JavaScript executes, and until the egress passes, no fingerprint fix you make is even observable.

The rest of this piece is how to stack the pieces so you actually get through.

How to bypass bot detection: the eight-layer stack

1. Start with a stealth-mode browser build, not vanilla Playwright

Raw Playwright, Puppeteer, or Selenium fail every standard bot check at page load — navigator.webdriver is true, the Chrome fingerprint has automation-specific quirks, and a dozen detection libraries (fingerprint-suite, CreepJS, BotD) will flag you before your first click. The fix is a browser that's been patched at build time to remove those tells: a stealth-mode build.

The stealth-mode browser build is the foundation. Everything else on this list assumes you're not leaking navigator.webdriver = true at the outermost layer.

The tooling here has churned hard, and a lot of published advice still recommends what was current in 2021. What matters is where a tool applies its changes, because that determines what a detector can see:

• Engine-level (rebuilt browser binary). Fingerprint changes live in the C++ source, so there's no JavaScript tampering to find — no rewritten toString, no broken prototype chains — and canvas and WebGL output is altered during rendering rather than intercepted on read. This is where the serious work is: Kernel's own browser build, Camoufox on the Firefox side, and the commercial anti-detect browsers (Multilogin's Mimic, Octo, Kameleo, Linken Sphere, Undetectable, Hidemium, BitBrowser, GoLogin, AdsPower, Dolphin Anty) which pair engine patches with real-device fingerprint databases so the spoofed attributes are internally consistent. The cost is a rebuild per Chromium release.
• Driver-level. patchright and rebrowser patch Playwright's automation surface; nodriver — the successor to undetected-chromedriver — goes further and avoids the attach-time protocol calls entirely. See layer 2, because on some vendors this is the whole ballgame.
• Transport-level. curl-impersonate, curl_cffi, and httpcloak reproduce a browser's TLS and HTTP/2 fingerprints from a plain HTTP client. Not browsers, so no DOM, but the right tool when your target's gate is entirely pre-JS.
• JS injection. puppeteer-extra-plugin-stealth and the older Selenium patches. Treat these as legacy: they can only intercept the read of a fingerprint rather than change what's rendered, they leave detectable traces doing it, they can't touch the transport layer at all, and every anti-bot vendor tests against them by name.

On Kernel, stealth mode is a configuration flag on session creation — no plugins, no patch juggling — available on every plan including the free one. It brings a default ISP proxy and an automatic CAPTCHA solver, both opt-out per session. The browser build and runtime layers are open source and inspectable, and in-VM Playwright execution ships with Patchright applied by default.

If you're running an agent framework (Browser Use, Stagehand, computer use), point it at a stealth-mode runtime rather than raw Playwright. The browser fixes the browser's fingerprint — but be aware the framework can add one. DataDome ships targeted detections for exactly this: Browser Use's highlight attributes (data-browser-use-highlight and friends) picked up through a MutationObserver, Stagehand's injected global, Claude computer use's animation stylesheet, and Playwright's own globals (__playwright_builtins__, __pwInitScripts). It also wraps createElement, querySelector, and document.cookie and inspects the call stack for Puppeteer frames. No amount of browser-level stealth fixes those, because they aren't the browser — they're your tooling writing into the page. If you're on a DataDome target, disable your framework's visual-debugging features in production and check what it leaves in the DOM.

2. Watch which automation protocol commands your driver sends

The single most under-appreciated tell isn't in the browser, it's in how you connect to it. A CDP connection is not automatically a problem — what matters is which commands the driver issues on attach.

We measured this against a bytecode-VM vendor: a bare CDP connection that only enables what it needs passed every token integrity check, while driving the same browser with Playwright's connectOverCDP failed roughly one in five. The difference is that connectOverCDP sends Runtime.enable, Runtime.addBinding, Console.enable, and Page.addScriptToEvaluateOnNewDocument during setup, and those mutate V8 inspector state in ways the sensor can observe — it probes for them by deliberately triggering TypeErrors and reading the messages. An independent 2026 benchmark of seven anti-detect tools found the same pattern from the other direction: a direct-CDP driver cleared a live Cloudflare Turnstile gate that every Playwright-based fork failed, on the same fingerprint. Automation-protocol fingerprinting is now competitive with fingerprint patching as a detection method.

What to do about it: use the thinnest driver that does the job, or move the code to where the browser is. Kernel's computer controls API drives the browser through OS-level mouse and keyboard events with no inspector attached at all, and Playwright execution runs your Playwright code inside the browser's own VM so there's no external client to observe — though note that in-VM Playwright still dispatches its input through the protocol, so it removes the connection tell without removing the synthetic input tell covered in layer 4.

3. Match your proxy to the target

On most hardened targets the egress IP is the highest-leverage variable you control, and it's the one people get wrong most often. Across a couple dozen Cloudflare-protected sites we A/B tested, moving off datacenter egress took pass rates from roughly 6% to the low-to-mid 60s. Nothing else we tested on those sites — not behavioral pacing, not GPU rendering, not solver extensions — produced an effect anywhere near that size. Start here.

Where the conventional wisdom is wrong is the assumption that residential is the top of a quality ladder:

Three findings from our own testing that contradict the usual advice:

Rotating residential pools can score worse than static ISP IPs. On reCAPTCHA v3 Enterprise the gap wasn't marginal: rotating residential exits failed essentially every run in a controlled comparison, while static ISP IPs passed the overwhelming majority. Google appears to classify the traffic pattern of a shared rotating gateway, not just the quality of the exit IP. If your target is scored by Google — reCAPTCHA anywhere in the flow, or Google properties themselves — reach for ISP, not residential.

Third-party IP reputation scores do not predict outcomes. We've had ISP IPs that commercial reputation services rated as maximum-risk datacenter bot traffic pass a Google-scored gate on nearly every attempt, while pristine-scoring consumer residential IPs failed every one. The big vendors run their own internal scoring. Buying IPs on a reputation-score spec is optimizing the wrong number; measure against your actual target instead.

Reputation is a property of the /24, and it oscillates. When we swept a proxy pool twice roughly a day apart against an IP-gated target, recoveries outnumbered degradations three to one and the pool's usable rate went up — which cumulative "IP burn" cannot produce. Blocked addresses came in whole neighbouring blocks whose members had unrelated usage histories, and our own request volume didn't predict which blocks were dead. Prefix-level reputation scoring is documented practice at multiple vendors, and at least one of our dead ranges had been publicly flagged as proxy-dense before we ever sent traffic through it. The operating implications: select and health-check at /24 granularity rather than per IP, don't build a per-IP deny list that thrashes against an hourly-recomputed score, retry later rather than immediately, and screen prefix history before you onboard a range.

One transport detail worth knowing: prefer a proxy that tunnels with CONNECT over one that terminates and re-originates TLS. A tunnel preserves your browser's own handshake end to end — we've confirmed identical JA4 fingerprints and identical headers across tunnelled proxy paths — whereas a man-in-the-middle proxy re-terminates TLS and can introduce exactly the browser-versus-transport mismatch you're trying to avoid.

The right pattern is per-target proxy selection. Kernel ships all five types — datacenter, ISP, residential, mobile, and custom — with health checking, geo-targeting, and per-session selection; stealth mode routes through a static ISP proxy by default, which is the right default for the reasons above. Configurable and bring-your-own proxies require the Start-Up or Enterprise plan. Standalone proxy vendors (Bright Data, Oxylabs, IPRoyal, Smartproxy) give you the pool without the browser-runtime glue — fine if you're already building your own runtime.

4. Drive the browser the way a person would

On the vendors that score behavior, this is not a rescue pass you run after you're already flagged — it's mandatory from the first version of your automation. Against Akamai in particular, a stealth browser with a perfect fingerprint and a clean IP never clears the cookie on its own; the sensor is waiting for interaction events and will not release you without them. Four things we learned getting this to work:

Events dispatched over the automation protocol are not the same as real input. page.mouse.move and page.keyboard.type synthesize events inside the browser, and some vendors detect that directly, independent of how nice your trajectory is. OS-level input — a real mouse and keyboard against the running desktop — is what actually reads as human. That's what Kernel's computer controls API dispatches, and it's why computer-use agents driving via screenshots plus OS-level mouse and keyboard tend to beat pure DOM automation on hardened targets.

Trajectory quality is not the same as trajectory density. This one is counterintuitive: our first attempt generated dense 1–2px mouse steps on the theory that more samples looks more human, and it solved 0% of the time. Switching to a handful of waypoints (four to six) with heavy Bézier interpolation between them took the same target to an 80% solve rate. Detectors are looking at the shape of the curve and the variance in it, not the number of samples. ghost-cursor and similar Bézier libraries are the right idea; cranking up the sample rate is not.

Fire events during page load, not after it. Sensors initialize a couple of seconds into page load and start recording immediately. If you wait for the page to settle before interacting, the sensor sees a browser that sat perfectly still through its entire observation window and then moved. Starting mouse activity concurrently with navigation cut our time-to-pass on one hardened target from around 15 seconds to about 3 — and a majority of those runs cleared before the page had finished rendering.

Variance is the signal, not smoothness. Google's SearchGuard computes running variance on mouse velocity, key press duration, inter-key interval, click interval and scroll delta, and flags near-zero variance — the tell is metronomic regularity, not being too fast or too slow. It also flags implausibly high event rates. A humanization layer that emits perfectly even 50ms intervals is as detectable as no humanization at all.

Two limits worth stating plainly. First, this is vendor-specific: DataDome's page sensor collects no mouse or keyboard events at all, and Imperva's simpler layer doesn't either, so behavioral work buys you nothing on those. In our own Cloudflare A/B tests on already-clean ISP egress, adding behavioral humanization moved pass rates by about a point — inside the noise at the sample sizes we ran, so read it as "no large effect there," not as a proven zero. Second, behavior cannot fix a decision the target made before your code ran: if the block fires on the IP or on first paint, no amount of realistic mousing changes it.

The cost is wall-clock time, and it's real: pacing a form fill like a human adds seconds per step. Spend it on the targets that score behavior.

5. Handle CAPTCHAs when you get one

Even a well-tuned stealth stack will hit a CAPTCHA sometimes. When you do, you want to clear the challenge rather than the whole page — retry from scratch and you're just going to hit another one. Your options:

• A solver managed by your runtime. Kernel's stealth mode ships with an automatic CAPTCHA solver already wired up: the browser handles the challenge and your automation code doesn't need to know it happened. There's an hCaptcha-specific solver in beta on top of that — ask support to enable it for your org. To be clear about what this is, because the category is full of vendors implying otherwise: managed solvers — ours included — are built on the same solver services listed below. The value is that the integration, the extension packaging, and the credential handling are done for you, not that a different and better solving technology exists behind the flag.
• Wiring up a solver service yourself — 2Captcha, Anti-Captcha, CapSolver, NopeCHA. These accept a site key + page URL and return a token you inject. Doing it directly gives you control over which challenge types you cover and when the solver is active — which, per the warning below, is a control you actually want. You pay per solve either way, and detection scores can flag the injected token if you're too fast about submitting it.
• Human-in-the-loop. For low-volume high-value flows, hand a live-view URL to a human when a challenge appears. Kernel's live view is interactive, and embeds in your own dashboard as an iframe (give it focus for keyboard events, and add allow="clipboard-read; clipboard-write" if you want clipboard sharing).

A solver can be the thing that gets you blocked — including ours. This is the least-known trap in the category, and we found it in our own stack. Extension-based solvers work by patching page JavaScript: the common reCAPTCHA approach is to override grecaptcha.execute() and race the site's own token against a solved one. reCAPTCHA v3 Enterprise detects that tampering. On one target we measured a 0% pass rate with the solver extension active and 93% with the same configuration and the extension disabled. Same browser, same ISP proxy, same everything else. Solver extensions also tend to override other main-world properties, which a vendor doing native-function integrity checks over a property manifest can notice. Since the solver runs by default with stealth mode, this is a default you should know how to turn off.

The lesson isn't "never use a solver," it's that a solver is a fallback for challenges you actually get, not a thing to leave running on every session. On reCAPTCHA v3 sites specifically, disable it — v3 is a passive score, there is no challenge for a solver to solve, and the interception itself is the signal. And don't generalize the finding either: in our Cloudflare A/B testing the same extension on-versus-off came out flat, so this is a reCAPTCHA-specific interaction, not a universal rule.

If hCaptcha is appearing, the fix is often upstream of hCaptcha. hCaptcha is frequently served because a WAF in front of it scored the session badly, not because hCaptcha itself decided anything. On one target where hCaptcha was reliably blocking a login, the root cause turned out to be a WebGL vendor string that didn't match the spoofed renderer — a fingerprint inconsistency, two layers up. Fixing that made the challenge stop appearing at all. Before you buy an hCaptcha solver, check whether you can stop triggering it.

Which combination you use depends on volume and challenge type. Common challenges on a stealth session: let the runtime handle them. Mixed challenge types across a lot of sites: pair Kernel with a solver service as a fallback. Rare-but-high-value flows: fall back to human-in-the-loop.

6. Get the rendering path right, not just the display

These are two separate things and most write-ups blur them. Headless is about whether there's a display. Software rendering is about what actually draws the pixels. The signal that gets caught is usually the second one.

A browser rendering through a software rasterizer produces canvas and WebGL pixel hashes that match no real consumer GPU. Any vendor that fingerprints rendering output cross-checks those pixels against the GPU you claim to have, and a software renderer fails that check no matter how carefully the vendor and renderer strings are spoofed. In our testing this is the difference that matters for HUMAN/PerimeterX and for DataDome's CSS-transform fingerprint: GPU-backed browsers pass targets where software-rendered ones are challenged, and no amount of additional canvas noise closes the gap — noise is itself a pattern that ML detectors have learned to spot. Headless matters too (it changes compositor and font-rendering paths, and it's what the older detection libraries look for), but if you're only going to change one thing on a rendering-fingerprint target, change the renderer.

On Kernel, headful is the default — it's also what live view and replays need — with headless as a lighter option (1 GB vs. 8 GB) and headful + GPU when you need real hardware rendering, whether that's for WebGL and video workloads or for the fingerprint reason above. Usage is metered per second at $0.0000166667 per GB-second, so the effective rates are $0.0000166667/sec headless, $0.0001333336/sec headful, and $0.0008000016/sec with GPU — you pay the higher rate only for the sessions that need it. GPU browsers require the Start-Up or Enterprise plan and don't support standby mode, so scope them to the targets that score rendering. Browserbase focuses on headless-only browsers, which may be a constraint when you're evaluating it for hardened targets.

As with the other levers, this one is vendor-specific rather than universal: reCAPTCHA v3 reads no canvas or WebGL at all, so GPU rendering does nothing for you there, and in our Cloudflare A/B tests on clean egress it came out flat. It's a targeted fix for the vendors that fingerprint pixels.

Headful is also what unlocks reliable computer-use agents (Anthropic-, OpenAI-, or Gemini-style visual agents driving via screenshots + mouse + keyboard), because the visual model needs a real rendered display to reason about.

7. Use profiles deliberately, not reflexively

"Always reuse a warm profile" is the piece of advice in this article we'd most want to qualify, because we've measured it cutting both ways.

Where it wins, it wins enormously — and the mechanism is the site's own session state. Sites with first-party device-identity systems (large marketplaces are the common case) expect a visitor who already holds their cookies: a device identifier, an API token pair, a security cookie their own checks set earlier. A cold browser arriving directly on a strict subdomain has none of that, and gets challenged on first load before any behavior can help. The fix is to warm the profile on the parent domain first: open a stealth browser with the profile and save_changes: true, visit the main site, wait a few seconds for their cookies to land, close it, then reuse that profile for the strict endpoint with save_changes off. On one target this took us from roughly one clean session in ten to better than nine in ten. Nothing else we tried on that case — GPU, mobile user agent, a different automation library, in-VM execution — came close; the load-bearing signal was session continuity.

Where it loses, it loses because the scorer keeps its own history of your browser. On reCAPTCHA v3 Enterprise we ran a controlled profile experiment and every warming strategy did worse than a fresh profile: pre-visiting Google, pre-visiting other reCAPTCHA sites, and accumulating runs in one profile all landed at zero, while fresh profiles passed a fifth of the time. reCAPTCHA keeps its own reputation attached to the browser, so a profile that has scored badly carries that penalty forward. Reuse makes it worse, not better.

The rule that survives both results: reuse a profile when the target site's own cookies are what you're accumulating, and use a fresh one when what accumulates is a scoring vendor's opinion of you. When in doubt, run both arms against your actual target — it's a cheap experiment and the answer is not guessable from first principles.

Two operational notes either way. Don't save changes during normal runs, or you'll persist a challenge-contaminated state into every future session; keep warm-up sessions and working sessions separate. And re-warm on a schedule or when your challenge rate starts climbing, because these cookies expire.

Kernel's profiles are a first-class primitive for this — attach a profile by name at creation, set save_changes: true when you want to persist, and everything the session accumulates carries into the next browser that attaches it. Combined with Kernel's managed authentication (a hosted login UI, an embeddable React component, or programmatic credential submission with automatic re-auth and health checks), the "log in once, use forever" pattern is a supported workflow instead of something you build yourself with brittle cookie-jar code.

Browserbase has an equivalent called Contexts. Roll-your-own is possible on any runtime, but the failure modes (expired cookies, invalidated tokens, service-worker state drift) tend to only surface at 3am under load.

8. Sign your requests with Web Bot Auth on cooperating sites

The newest option, and the most interesting long-term: Web Bot Auth lets automated clients cryptographically sign their requests with an Ed25519 key using HTTP Message Signatures (RFC 9421), so participating sites can verify the automation is legitimate rather than trying to detect it. The IETF Datatracker currently lists webbotauth as an active working group with an approved charter; its current documents remain Internet-Drafts rather than published standards, so build against it expecting the details to move.

For agents talking to participating destinations, this flips the whole model — instead of trying to sneak past defenses, you're getting invited in as an authenticated automation. Kernel supports it through a signing extension you build and attach to your browsers (kernel extensions build-web-bot-auth --upload my-web-bot-auth), and Kernel's identities are approved by Cloudflare, Vercel, Akamai, and other bot-verification providers.

Two catches, and the second one surprised us. The obvious one: it only helps on sites that actually verify signatures and have decided to allow your identity. The less obvious one: signing is not free, and on the wrong target it can cost you. Signing requires something in the request path to read and modify the plaintext request, which means terminating TLS rather than tunnelling it — and a terminated connection emits an imitation of Chrome's handshake rather than the genuine article, which is exactly the transport-layer coherence you spent layer 3 protecting. Against a site that verifies your signature and allowlists you, that trade is fine, because the heuristics never run. Against a site that fingerprints but doesn't honour Web Bot Auth — Cloudflare in challenge mode is the case we hit — you've paid the fingerprint cost and received nothing, and you've also announced that you're a bot to something that was still deciding.

So: turn signing on per-target, for destinations you've confirmed verify it. Don't leave it on globally as a defensive default. For everything else, layers 1–7 still apply.

Top recommendation to bypass bot detection: Kernel

For most teams shipping AI agents in 2026, the reliable path through anti-bot defenses is Kernel. It ships every layer in the stack above as configuration on a single runtime — no plugin juggling, no separate solver vendor, no dance between a proxy provider and a browser provider.

What you get out of the box:

• Stealth-mode browser builds as a configuration flag on session creation, on every plan including free. Not an add-on, not a support-ticket unlock.
• An automatic CAPTCHA solver that runs in-band with stealth mode, opt-out per session for the targets where a solver hurts more than it helps, plus an hCaptcha-specific solver in beta on request.
• Five proxy types — datacenter, ISP, residential, mobile, custom — with health checking, geo-targeting, and per-session selection. Configurable and bring-your-own proxies are on the Start-Up and Enterprise plans.
• Headful (default), headless, and headful + GPU modes priced per second at different rates. GPU is a real anti-bot lever on vendors that fingerprint rendering output, not just a performance knob.
• Profiles for persisting cookies and storage across browsers, with save_changes per session so warm-up runs and working runs stay separate, plus managed authentication with a hosted login UI, embeddable React component, or programmatic credential submission, with automatic re-auth and health checks.
• Web Bot Auth for cryptographically signing requests to participating destinations.
• Browser extensions — ad-hoc uploads and Chrome Web Store fetch — so you can bolt on tooling that isn't in Kernel's default stack.
• MP4 replays and live view for debugging when a target does block you, with an interactive view a human can take over.
• OS-level computer controls and in-VM Playwright execution, so you can drop the external inspector connection and the synthetic-input tell that come with driving over CDP from outside.
• Sub-30ms cold starts on Kernel's unikernel runtime, and up to 72-hour sessions for long-lived authenticated flows.
• Per-second billing with Standby Mode — browsers waiting on an LLM or a slow target don't run the meter.

On the anti-bot dimension specifically, we'd rather give you the honest version than a headline number. Anyone quoting you a single cross-platform "success rate" — us included — is quoting an average over a site list they chose, against vendor models that changed last week. Pass rates are target-specific, they move whenever a vendor ships, and the only number that means anything is the one you measure on your own targets. What we'll claim is narrower and checkable: the levers listed above exist on one runtime and are switchable per session, we publish what our own research found about which of them actually move the needle per vendor, and when a strategy stops working on a target you change a parameter instead of changing platforms. Run a proof of concept on your real targets and hold whatever you're evaluating to that standard.

Framework flexibility matters here too: Kernel works with Playwright (including execution inside the browser's own VM), CDP directly, WebDriver BiDi, Stagehand, Browser Use, and computer controls — so you can use the stealth stack from whichever agent framework your team is on, not a house SDK.

Other tools worth knowing

Kernel isn't the only way to do this. If it doesn't fit, here's the honest read on the alternatives you'll evaluate.

Browserbase

The other big cloud-browser platform for AI agents. Ships proxies and auto-CAPTCHA on paid tiers, with Verified sessions on the Scale tier. Browserbase focuses on headless-only browsers, so targets that fingerprint headless may be harder than on a runtime that offers headful. Session duration is plan-dependent: 15 minutes on Free, 6 hours on the paid tiers below Scale, and 6+ hours on Scale. See our Kernel vs Browserbase piece for the full comparison.

Browser Use

Two products worth keeping straight. The framework is an open-source Python-first agent library — you point it at a browser over CDP and it handles the LLM-driven reasoning, so it runs against any CDP endpoint, Kernel included. That pairs well: Browser Use for the agent loop, Kernel for the underlying stealth stack. Browser Use Cloud is a separate paid product that hosts the browsers and competes directly with Kernel. It ships always-on stealth, CAPTCHA handling, and residential proxies across 195+ countries, with session recordings and live preview for debugging. The anti-bot stack is narrower than Kernel's, though: proxy traffic is metered separately at $5/GB on top of browser time, and headful + GPU rendering and Web Bot Auth aren't documented. If you want the agent loop and the browser from the same vendor it's a reasonable package; if you want the widest set of anti-bot levers, run the framework against Kernel.

2Captcha, Anti-Captcha, CapSolver, NopeCHA

Solver-only services. You send a site key + page URL, they return a token. Covers more challenge types (reCAPTCHA v2/v3, Turnstile, FunCAPTCHA, DataDome interactive) than most in-runtime solvers. The right choice when your target uses a challenge type your runtime doesn't natively clear, or when you need a fallback for high-value flows. Pricing is per-solve, and quality varies by vendor and challenge type.

Bright Data, Oxylabs, IPRoyal, Smartproxy

Proxy-only vendors. All offer residential, mobile, ISP, and datacenter pools with reasonable rotation and session-stickiness options. Bright Data has the largest network and the most self-serve tooling; Oxylabs is close behind and often cheaper on high-volume commits; IPRoyal and Smartproxy are more approachable at low-to-mid volume. Use these when you're bringing your own browser runtime, or bring them to Kernel as custom proxies when you already have a contract you don't want to abandon.

Self-hosted stealth tooling

If you're building your own runtime, the current open-source landscape is bigger and better than the "install a stealth plugin" advice that dominates search results. Two findings worth having before you choose:

The driver is a differentiator, not just the fingerprint. nodriver, the successor to undetected-chromedriver, deliberately avoids the protocol calls Playwright issues on attach. An independent 2026 benchmark across seven tools and 31 targets found it clearing a live Cloudflare Turnstile gate that every Playwright-based fork failed — Patchright and rebrowser included — on the same fingerprint. If you take one thing from this section, it's that the connection layer deserves as much attention as the fingerprint layer.

Firefox buys you something Chromium forks can't fake. Camoufox patches at the C++ level like the serious Chromium forks, but because it's Firefox it emits a genuinely different TLS and HTTP/2 fingerprint via NSS rather than an imitation of Chrome's via BoringSSL. That's the one part of the stack that can't be convincingly spoofed from a Chromium base. It's also still experimental, so budget for breaking changes.

For pre-JS gates specifically, the HTTP-client tools (curl-impersonate, curl_cffi, httpcloak) reproduce browser TLS and HTTP/2 fingerprints without a browser at all — no DOM, but far cheaper when the target's gate is entirely at the transport layer.

The tradeoff vs. a managed runtime is twofold. Anti-bot vendors fingerprint the most popular OSS stealth libraries by name, so you're on a patch treadmill against a moving target. And the pieces none of these tools cover — proxy pools selected at /24 granularity, GPU-backed rendering, OS-level input, profile warm-up and rotation — are yours to build and operate. Good starting point for hobby projects and for genuinely understanding the problem; a lot of undifferentiated work for a production agent.

Putting it together: a minimal Kernel example

Here's the shortest complete example that stacks stealth mode, a residential proxy, and a persisted profile using Kernel's TypeScript SDK and Playwright. Everything else in this post is a variation on this pattern.

import Kernel from "@onkernel/sdk";
import { chromium } from "playwright";

const kernel = new Kernel(); // reads KERNEL_API_KEY from the environment

// Proxies are created once and reused across sessions.
const proxy = await kernel.proxies.create({
  type: "residential",
  name: "us-residential",
  config: { country: "US" },
});

// Headful is the default. Attach a saved profile so cookies and storage
// carry over, and save any changes back when the session ends.
const session = await kernel.browsers.create({
  stealth: true,
  proxy: { id: proxy.id },
  profile: { name: "target-site-logged-in", save_changes: true },
  timeout_seconds: 3600, // inactivity timeout before Kernel deletes the session
});

try {
  const browser = await chromium.connectOverCDP(session.cdp_ws_url);
  const page = browser.contexts()[0].pages()[0];

  await page.goto("https://target-site.example.com/dashboard");

  // If a CAPTCHA appears, the stealth runtime clears it in-band —
  // your code just waits for the post-challenge page to render.
  await page.waitForSelector('[data-testid="dashboard-ready"]', {
    timeout: 60_000,
  });

  console.log(await page.locator('[data-testid="metric"]').allInnerTexts());
} finally {
  // Without this the session lingers until the inactivity timeout fires.
  await kernel.browsers.deleteByID(session.session_id);
}

Swap stealth: true off and the same script typically fails on any hardened target. Swap the proxy type based on what your target accepts — and note that on a Google-scored target you'd want type: "isp" here rather than residential, for the reasons in layer 3. On the hardest targets, replace the external connectOverCDP with kernel.browsers.playwright.execute() to run the same Playwright code inside the browser's VM, which removes the inspector-state tell, or drive it with the computer controls API, which additionally replaces synthetic input with OS-level events. The rest of your agent code — Browser Use, Stagehand, or a computer-use loop — sits on top unchanged.

Best practices for a reliable anti-bot pipeline

The pattern that separates teams whose agents run reliably from teams who are on-call every day for a different broken flow:

Measure success rate per target, not overall. "Our anti-bot success rate is 94%" is a meaningless average. What matters is the success rate on each target site, tracked over time, with an alert when it drops. Anti-bot vendors ship changes; your success rate on any given target will decay if you're not watching.

Have at least two strategies per target. Primary: stealth + ISP proxy + a persisted profile. Fallback: GPU rendering, OS-level input pacing, a different proxy prefix, human-in-the-loop. When the primary strategy stops working — and it will — you want the fallback ready to swap in without a code change.

Change one variable per run. Every finding in this article that turned out to be wrong was wrong because several things changed at once and the wrong one got the credit. If you swap the proxy and enable GPU and add mouse pacing in the same commit, you've learned nothing about which lever mattered, and you'll be carrying two of them as cargo cult forever.

Don't retry into a block, and retry at the right granularity. Do not immediately retry with the same fingerprint from the same IP. But "rotate the IP" is usually too fine-grained: reputation is scored on the /24, so the next address in the same block is often just as dead, and the block itself may recover on its own within hours without being rested. Move to a different prefix, back off on a timescale of hours rather than seconds, and don't build a permanent per-IP deny list — it will thrash against a score that's being recomputed underneath you.

Persist authenticated sessions, but test whether persistence helps unauthenticated ones. Every login is expensive (2FA, email verification, sometimes a CAPTCHA gate), so save the profile the moment auth succeeds and reuse it until it breaks — Kernel's managed authentication handles the re-auth loop when it does. For unauthenticated scraping the answer isn't automatic: a warm profile is a large win on sites with their own device identity and a measurable loss against vendors that score your browser across sites. Run both arms. And keep warm-up sessions separate from working sessions so you never persist a challenged state.

Test against your actual targets, not a leaderboard. Public anti-bot checks (BotD, CreepJS, bot.sannysoft.com) are useful sanity checks but they're not what your production targets are running. The only measurement that matters is a real request against the real site, over enough runs to see the tail behavior.

Log everything, replay when things break. MP4 session replays are the difference between "the agent got blocked at step 47" and "here's the exact modal that appeared at step 47." When you're operating agents at scale, that feedback loop is what makes debugging tractable. Replays record headful sessions on every plan, with retention scaling from 1 day on the free tier to 30 days on Start-Up.

FAQ

What's the most reliable way to bypass CAPTCHA for an AI agent?

The most reliable bypass is not to trigger the CAPTCHA in the first place — a well-tuned stealth stack (stealth browser build + right-fit proxy + persisted profile + headful when needed) keeps most sites from ever serving one. When you do hit one, in-runtime solving avoids the round-trip to an external service and the token-injection race; on Kernel that solver runs automatically with stealth mode, with an hCaptcha-specific solver in beta on request. For challenge types your runtime doesn't natively clear — Arkose FunCAPTCHA, DataDome interactive — pair with a third-party solver (2Captcha, CapSolver, Anti-Captcha) as a fallback, or hand a live-view URL to a human on high-value flows.

One important exception: reCAPTCHA v3 is a passive score, not a challenge, so there's nothing for a solver to solve — and an extension-based solver that patches grecaptcha.execute() is detected as tampering. We measured a 0% pass rate with a solver extension active against 93% with it disabled on the same configuration. On reCAPTCHA v3 targets, turn the solver off.

How do I stop my AI agent from getting blocked by Cloudflare?

Cloudflare's Bot Management scores requests across TLS fingerprint, browser fingerprint, IP reputation, and behavioral signals — but in our own A/B testing those factors are nowhere near equally weighted. Egress IP reputation dominated everything else. Datacenter egress passed around 6% of the protected sites we tested; ISP, residential and mobile all landed in the low-to-mid 60s. That's roughly a tenfold swing from one variable. Every other lever we tested on top of already-clean ISP egress — behavioral humanization, GPU rendering, a solver extension — came back flat at the sample sizes we ran.

So: get the egress right first, and use a stealth-mode build rather than vanilla Playwright. Then note that clean egress is necessary but not sufficient — about a third of sites still failed with a good IP, and Cloudflare's Managed Challenge does monitor behavioral events during its challenge window, so the remaining work is real.

One thing not to reach for here: Web Bot Auth is not a Cloudflare bypass. Signing only helps when the origin verifies your signature and has allowlisted your identity. A Cloudflare site in challenge mode doesn't honour it, so you get nothing — and because signing requires terminating TLS to modify the request, turning it on can degrade your handshake from a genuine Chrome fingerprint to an imitation of one. On Cloudflare-protected targets that haven't opted in, signing is a net negative. Enable it per-destination, not globally.

Which cloud browser is best for anti-bot?

Kernel, on the grounds that it gives you the widest set of switchable levers on one runtime: stealth builds, a managed CAPTCHA solver you can also turn off per session, five proxy types with per-/24 selection, GPU-backed rendering for the vendors that fingerprint pixels, OS-level computer controls and in-VM Playwright execution that remove the automation-protocol tells, session profiles, and Web Bot Auth.

That's a capability claim, not a success-rate claim, and the distinction matters. There is no honest universal ranking of cloud browsers by anti-bot pass rate — the number depends entirely on which sites are in the list, which vendors protect them, and what those vendors shipped this month. Treat any provider quoting you a single figure, including us, as quoting an average over a site list they picked. What to do instead: take your three hardest targets, run them on whatever you're evaluating, change one variable at a time, and let that decide.

Can I bypass bot detection with headless Chrome?

Don't build on it. Headless is a cost optimization for targets that aren't fighting you, not an anti-bot strategy, and treating it as one is how teams end up debugging a detection problem they designed in.

The useful version of this question is about the renderer, not the display, because "headless" gets blamed for two different things. A browser without real GPU acceleration produces canvas and WebGL pixel hashes that match no consumer hardware, and the vendors that fingerprint rendering output — HUMAN/PerimeterX and DataDome among them — cross-check those pixels against the GPU you claim to have. That check fails regardless of how carefully the vendor and renderer strings are spoofed, and adding canvas noise doesn't fix it because the noise is itself a pattern. So for a target that scores rendering you want a real display and real hardware rendering: headful, GPU-backed. On Kernel headful is the default and GPU is a flag on Start-Up and above. Reach for headless only when you've established the target doesn't care.

Do I need residential proxies for every target?

No, and it's often counterproductive. Residential is slower and more expensive than ISP or datacenter, and it rotates the exit IP per connection — which breaks IP allowlists and can look erratic on a login flow. In fact static ISP is the better default on most protected targets, and on anything scored by Google it is decisively better: in a controlled comparison, rotating residential exits failed essentially every run against reCAPTCHA v3 Enterprise while static ISP IPs passed the large majority — Google appears to classify the traffic pattern of a shared rotating gateway rather than just the exit IP's quality. Reserve residential and mobile for targets that specifically want a consumer-looking IP. Two related traps: third-party IP reputation scores don't predict outcomes (we've had "maximum-risk" ISP IPs pass where pristine residential IPs failed every attempt), and reputation is scored on the /24 rather than the individual address, so rotating to the next IP in a blocked block usually accomplishes nothing. On Kernel, stealth mode already routes through a default static ISP proxy, so the common case needs no proxy configuration at all — you only reach for proxies.create() and proxy: { id } when a target specifically needs residential, mobile, or an IP you own. Proxies are created once and reused, and selection is per session, so the same profile can move between proxy types run to run.

What is Web Bot Auth and does it actually help?

Web Bot Auth lets automated clients cryptographically sign their requests with an Ed25519 key using HTTP Message Signatures, so cooperating destinations can verify the automation is legitimate rather than trying to detect it. The IETF Datatracker currently lists webbotauth as an active working group with an approved charter, and its specifications remain Internet-Drafts rather than published standards.

It helps a lot where it applies and it can hurt where it doesn't. Where the destination verifies your signature and has allowlisted your identity, the game changes from adversarial detection to authenticated allow-listing — you're invited in rather than sneaking through, and the heuristics don't run. Where the destination fingerprints but doesn't honour signatures, you get no benefit, you've told a still-undecided scorer that you're a bot, and you've paid a real cost: signing requires terminating TLS to modify the request, so the handshake the site sees is an imitation of Chrome's rather than the genuine one. Enable it per-destination for endpoints you've confirmed verify it — not globally as a defensive default.

Kernel signs requests through a Web Bot Auth extension you build with the CLI and attach to your browsers, and its identities are approved by Cloudflare, Vercel, Akamai and other bot-verification providers.

How do I bypass bot detection without a paid service?

You can assemble a credible stack from open source. Camoufox for an engine-level build (and a genuinely non-Chrome transport fingerprint), nodriver or patchright for a driver that doesn't announce itself on attach, a low-volume ISP proxy vendor for egress, and a solver service billed per solve — the same services every managed runtime is using underneath, so you're not giving anything up on solving by wiring it yourself. Skip puppeteer-extra-plugin-stealth; it's the baseline every vendor tests against.

What you're taking on is the operational half, which is where the effort actually is: keeping patches current against Chromium releases, health-checking and rotating proxies at prefix granularity, real GPU rendering for the vendors that fingerprint pixels, OS-level input rather than protocol-dispatched events, and profile warm-up and rotation. Fine for a personal project or for genuinely learning the problem. A lot of undifferentiated infrastructure for a production agent people are paying for. Kernel's free plan includes stealth mode and $5/month of usage credits if you'd rather not build it.

How can I tell if my AI agent is being blocked?

Blocks are noisy and quiet. The noisy ones — 403s, challenge pages, connection failures — are easy to catch in your automation. The quiet ones are harder: 200 responses with poisoned content (empty results, wrong data, a "you seem to be a bot" interstitial embedded in an otherwise-valid page), or shadowbans that only surface on the third or fourth request. Instrument every session with content-length and DOM-shape checks against a known-good baseline, stream Kernel's telemetry (console, network, page, and captcha-solve events) while the run is live, and record MP4 replays so you can see exactly what the browser rendered when a run looked wrong.

Should I use a CAPTCHA solver or try not to trigger CAPTCHAs?

Both, in that order. Reducing the trigger rate is far cheaper than solving — every CAPTCHA you avoid saves a solver call and the seconds of latency that come with it. Stealth + right-fit proxy + persisted profile + headful when needed will keep most sites from ever challenging you. For the challenges you do get, use in-runtime solving where available and a third-party solver as a fallback for challenge types your runtime doesn't natively cover.

Can my agent framework itself get me detected?

Yes, and this catches people who have done everything else right. DataDome ships detections aimed specifically at AI agent frameworks: Browser Use's highlight attributes (data-browser-use-highlight and its variants) caught through a MutationObserver, Stagehand's injected global compared across frames, Claude computer use's animation stylesheet, and Playwright's own globals. It also wraps createElement, querySelector and document.cookie and checks the call stack for Puppeteer frames. None of that is fixable by the browser — it's your tooling writing into the page, so no stealth build removes it and switching cloud providers won't either. The fixes are framework-side: turn off visual-debugging and element-highlighting features in production, audit what your framework leaves in the DOM, and prefer driving through a screenshot-and-OS-input loop over DOM injection on those targets.

Why does the same configuration work on one site and fail on another?

Because the vendors read different signals, and a config tuned for one can be actively wrong for another. Canvas and WebGL work buys you nothing against reCAPTCHA v3, which doesn't read them; behavioral pacing buys you nothing against DataDome's page sensor, which collects no mouse or keyboard events; a CAPTCHA solver extension helps on challenge-based vendors and actively hurts on reCAPTCHA v3. Identify the vendor in front of a target before you tune for it — the script URLs and cookie names give it away — then change one variable at a time and measure. The table earlier in this piece is a starting map of who reads what.

How do I turn on stealth mode on Kernel?

Pass stealth: true to browsers.create(). Every Kernel browser already ships with baseline anti-detection patches, so stealth mode isn't what removes navigator.webdriver — it adds two managed services on top: a default static ISP proxy for a stable exit IP, and the automatic CAPTCHA solver. Both are opt-out, so you can select your own proxy or bring your own solver without losing the rest. Stealth is available on every plan including the free one. Note that selecting a proxy explicitly changes egress only — it doesn't turn stealth or the solver off, and proxy: { mode: "direct" } on a stealth browser still runs stealth with the solver enabled.

What's the recommended Kernel configuration for a hardened target?

Start with stealth: true, headful (the default), and the default ISP proxy — that clears most targets. Escalate one lever at a time from there, in roughly this order of expected payoff: confirm the egress is clean and try a different /24 before anything else, since IP reputation dominates on most vendors; add headful + GPU if the site fingerprints canvas or WebGL rendering; move off an external connectOverCDP to Playwright execution or the computer controls API, which also replaces synthetic input with OS-level events; add behavioral pacing if the vendor scores behavior; and test a warmed profile both ways rather than assuming it helps. Changing one variable per run is what tells you which lever actually mattered — and it's the step teams skip.

Does driving a Kernel browser over CDP hurt my success rate?

It can, on the targets that check. A CDP client attached from outside the VM is itself a signal, which is why Kernel recommends computer controls or Playwright execution for agent workloads — both run co-located with the browser, so there's no external protocol connection to fingerprint. Playwright execution also ships with Patchright applied by default. Keep raw CDP for deterministic scripted work against targets that don't score it.

Do I need a paid Kernel plan for the anti-bot features?

Most of them, no. Stealth mode, the automatic CAPTCHA solver, profiles, live view, telemetry, and MP4 replays are on every plan, including the free Developer tier with its $5/month of usage credits and 5 concurrent browsers. What the free tier limits is depth rather than access: replay retention is 1 day (7 on Hobbyist, 30 on Start-Up), managed auth caps at 3 connections, and custom extensions at 1. Two anti-bot levers are genuinely Start-Up-and-above: configurable and bring-your-own proxies, and headful + GPU browsers. If you're evaluating, run the free tier against your actual targets first — the plan you end up needing is usually decided by concurrency, not by features.

How do I debug a block on Kernel?

Three tools, in order. Turn on telemetry at session creation and stream it live — the captcha category reports every automated solve result, and console, network, and page are opt-in when you need to see what the target actually returned. Open the live view while the run is in flight to watch the block happen and take over by hand if you need to. Record an MP4 replay so you can rewatch the exact frame where the run went wrong after the fact; replays need a headful session, and retention runs from 1 day on the free plan to 30 on Start-Up. The captcha-solve events are usually the fastest signal: a rising solve rate on a target that used to be quiet means that target changed, not your code.

How much does an anti-bot run cost on Kernel?

Billing is per second by browser type: $0.0000166667/sec headless, $0.0001333336/sec headful, $0.0008000016/sec with GPU, metered per GB-second. The thing that matters more than the rate is standby mode — a Kernel browser goes to standby after five seconds with no CDP, live view, or computer-controls activity and stops billing while keeping its state, so a session parked waiting on an LLM decision or a slow challenge page isn't running the meter. That's what makes it affordable to hold a profile-backed session open through a human-in-the-loop handoff. GPU browsers are the exception: they don't support standby mode, so scope them to the sessions that need the rendering.

Anti-bot vendors and cloud-browser platforms ship changes frequently — verify current capabilities and success rates against your actual targets before making a purchase decision.