Why AI Agents Get Flagged — and What Changed in AdsCrawl’s Cloud Browser

Originally published on Medium.

Playwright bot detection, browser fingerprinting, and persistent cloud browsers — with manual BrowserScan, Pixelscan, and IPhey checks.

Cover illustration: AdsCrawl, AI-generated.

Disclosure: This is a product walkthrough with recorded checks, not an independent review.

The browser is part of the agent

An AI agent can choose the right page, locate the right element, and still end up staring at a challenge screen. Debugging the prompt does not tell you whether the problem is the browser, the network, or the session behind it.

For this walkthrough, I started with a simple local baseline: launch stock Playwright, open BrowserScan’s Bot Detection page, and capture the result. Playwright 1.51.1 with headless Chromium 134 returned Robot, with Webdriver, User-Agent, and CDP highlighted in red.

Local baseline: BrowserScan flagged the unmodified local Playwright session. Captured November 4, 2026.

Then I opened the same detection page inside an AdsCrawl persistent cloud browser. That page returned Normal. The difference was visible, but the interpretation needs care: the cloud session was operated through its interactive viewer, not through the identical Playwright script.

The latest manual follow-up in Section 4 shows BrowserScan’s summary at 100%, a consistent fingerprint verdict from Pixelscan, and a Trustworthy result with an MX Score of 100 from IPhey. Those screenshots report a Mac OS profile and a US exit, separate from the earlier MacOS-profile demonstration.

This is an environment comparison, not a controlled “same agent, only the browser changed” benchmark. Browser version, operating-system profile, network route, and control method differed. The screenshots show what happened in these runs; they do not establish a general bypass rate.

1. What a detection system can see

It helps to separate four kinds of evidence when an agent fails:

1. Network: IP reputation, region, connection characteristics, and request volume.
2. Browser: automation indicators and the consistency of the reported OS, graphics stack, fonts, language, timezone, and hardware.
3. Interaction: navigation timing, repeated actions, and the session’s history on the site.
4. Page content: whether the response is the expected page, a challenge, a login screen, or an incomplete rendering.

Different sites weigh these signals differently. A single property such as navigator.webdriver can explain a detector’s warning, but changing that property does not prove that the rest of the environment is consistent.

My practical starting point is to log the actual failure and capture the page. Treat “element not found” as a symptom until you have checked what the browser really loaded.

Behavioral detection: a real browser can still act like automation

A site cannot inspect an agent’s prompt. It can observe requests, browser properties, session history, and interaction events. A familiar Chrome fingerprint therefore does not leave behavior as the only remaining signal: Cloudflare’s detection documentation describes a combination of headers, session characteristics, browser signals, and multiple detection engines.

An agent using an automation interface can share artifacts with a conventional script using that interface. That is a reason to investigate the control stack, not proof that every agent uses CDP or that every block has the same cause. A 2026 study of Playwright-driven agents explicitly identifies cross-framework generalization as an unverified prediction.

Behavior is nevertheless an important layer. The FP-Agent study observed differences in mouse, typing, and scrolling patterns across the agents it tested:

• Mouse activity: whether clicks are preceded by a continuous stream of pointer movement, and how movement direction and curvature vary. Some tested agents jumped directly between click targets.
• Text entry: whether input arrives through paste events, individual keystrokes, or programmatic form filling; the order of events and key-hold and inter-key timing can differ.
• Scrolling and timing: the distribution of scroll distances and durations, repeated jumps, and the sequence of actions across a task can provide additional evidence.

These are features to evaluate together, not universal rules. Human movement does not have to follow a Bézier curve; people also paste, use autofill, navigate by keyboard, or use touch and assistive tools. Likewise, automation does not always mean zero mouse events or pasted input. Playwright documents mouse events and both form filling and per-character keyboard input. A fixed “5 ms after load” cutoff would need evidence from a specific detector and measurement setup.

Why a legitimate agent can still be challenged

Recognizing automation, identifying its operator, and deciding whether to allow it are different decisions. A task-directed agent can complete a legitimate request through a direct, repetitive sequence. Classifying that session as automated may be correct; treating automation alone as evidence of abuse can create unwanted challenges. Permission from the user also does not override the destination site’s access policy.

For agents that identify themselves, operators can verify identity through mechanisms such as signed requests, published IP ranges with a stable user-agent, or reverse DNS. A user-agent string alone is an assertion, not authentication. Cloudflare’s verified-bot documentation describes these approaches. Identity verification and behavioral risk assessment can complement each other.

Research results need a separate qualification. FP-Agent studied seven agents on three tasks on an instrumented test site, and its authors limit the findings to their agents, tasks, and configurations. Strong classification results in that setting are not production blocking rates, nor a guarantee that any particular agent will be blocked.

For this walkthrough, the boundary is clear: changing the browser environment does not establish that an agent’s behavior resembles a human’s. The screenshots below do not measure a complete agent task’s mouse, keyboard, or scrolling behavior. They cannot substantiate a claim of behavioral undetectability.

2. Two browser products, two different lifecycles

AdsCrawl has two workflows that are easy to mix up:

• Remote CDP sessions are temporary browser sessions intended for programmatic control with Playwright, Puppeteer, or another CDP client. The create-session response supplies a cdpBaseUrl.
• Persistent Cloud Browser profiles save a reusable environment and expose an interactive viewer while running. The saved profile remains after its runtime stops.

That distinction matters in code. A persistent browser’s viewer URL is not a CDP endpoint. The launch reference documents runtimes that omit cdpBaseUrl, so do not pass a viewer link to chromium.connectOverCDP() or assume a top-level session.cdpBaseUrl exists after a Cloud Browser launch.

The screenshots in this article use the persistent Cloud Browser dashboard. The Playwright example in Section 6 uses the separate Remote CDP API, which is the documented programmatic connection route.

At the time of this test, Cloud Browser runtimes were billed at 1 credit per started minute, until shutdown was confirmed. The Free plan could save a profile but could not launch a Cloud Browser runtime. Check the current lifecycle and plan requirements before running a long job. Closing the viewer is not the same as stopping the runtime.

3. Configure the proxy and fingerprint together

For the earlier cloud demonstration, I created a dedicated profile named Medium demo — US research and selected the United States residential-proxy region in the dashboard. I left timezone, geolocation, and language on their IP-based settings, with WebRTC set to Forward. The configuration screenshots below show that earlier MacOS profile; they are not a configuration record for the later Mac-profile checks in Section 4.

Earlier MacOS-profile demonstration: the proxy-region selector and fingerprint settings. This is not the configuration record for the later Mac-profile checks.

The editor also exposes canvas, WebGL image, audio, font, media-device, and hardware settings. The generated MacOS profile paired its WebGL vendor with a renderer and offered WebGPU settings based on that WebGL configuration.

Canvas and WebGL settings in the earlier MacOS-profile demonstration.

Configuration and verification are separate steps. A country selector tells you what you requested. A report from inside the running browser tells you what the site observed. Check the exit IP, timezone, WebRTC behavior, and reported OS/GPU together before trusting a regional workflow.

There is also an API detail worth getting right: API-key callers starting a persistent profile must supply the required top-level proxy object for that request. A saved profile preference is not a substitute. The dashboard’s managed-region selector is a different workflow. Put proxy credentials in the dedicated username and password fields, not inside the proxy URL. See the launch reference for the accepted proxy formats.

4. What the detection checks actually showed

The cloud profile uses AdsPower’s fingerprint-browser environment. The relevant question for this walkthrough is what the detection page actually saw, rather than whether a marketing description promises an undetectable browser.

In the earlier interactive cloud check on November 4, 2026, BrowserScan’s Bot Detection page returned Normal. Its Webdriver, User-Agent, CDP, and Navigator cards were not marked red.

Earlier interactive cloud check: BrowserScan Bot Detection returned Normal. This is separate from the later manual Mac-profile results below.

For the follow-up, I manually checked BrowserScan, Pixelscan, and IPhey inside an AdsCrawl Cloud Browser. The four screenshots below report a Mac OS profile and a US exit, rather than the MacOS / Arizona environment used for the earlier demonstration. These are a separate set of observations, not a rerun of the local Playwright script.

BrowserScan’s updated summary shows browser fingerprint authenticity of 100% and Bot Detection: No Detection. It reports Chrome 156.0.8078.47 on Mac OS 13.5.0, Pennsylvania / USA, the America/New_York IP timezone, and English (United States). These are the labels and values on this report; the score is not a cross-site success rate.

BrowserScan reports 100% fingerprint authenticity and No Detection for the displayed Mac OS / US environment.

The accompanying details screenshot identifies the device as Apple / Macintosh. Its IP and WebRTC STUN fields display the same US address, while the WebRTC field itself is labeled disabled. This records what BrowserScan displayed, without treating a single field as a comprehensive leak test.

BrowserScan details from the manual follow-up. The WebRTC field is labeled disabled, and the IP and STUN fields display the same US address.

Pixelscan’s updated result reads “Your Browser Fingerprint is consistent.” Its cards show Chrome 156.0.0.0 on Mac OS, United States / Mount Union, “No proxy detected,” “No masking detected,” and “No automated behavior detected.” The last label describes this manual check; it does not evaluate how a complete Playwright or AI-agent task would behave.

Pixelscan: consistent fingerprint, no masking detected, and no automated behavior detected.

IPhey now shows a completed result: “Your Digital Identity Looks Trustworthy,” with an MX Score of 100. Browser, location, IP address, hardware, and software cards all show green checks. The browser is Chrome, the location is United States, and the displayed IP matches the one in the BrowserScan screenshots.

IPhey: Trustworthy, MX Score 100, with green checks across the five displayed categories.

Taken together, these manual screenshots show favorable results from three different checkers for the reported environment. Their scores and labels are not interchangeable: BrowserScan’s 100% and IPhey’s MX Score 100 measure different things. “No proxy detected” also does not prove that no proxy was used. A controlled agent comparison would still need the same task logic, recorded browser and network settings, and repeated runs.

5. Separate workflows deserve separate profiles

I created two clearly labeled demonstration profiles: US research and DE regional QA. During the screenshot, the US profile was running and the DE profile was stopped.

Two separate saved profiles, with different lifecycle states. US and DE in the names describe their configured workflow regions; the list’s Proxy region cells were not populated in this capture.

For real work, I would keep research, regional QA, and authenticated workflows in separate profiles. That gives each job its own saved configuration and session data, and makes it easier to identify which runtime needs to be stopped.

Persistence also needs configuration. In the editor used here, cookies and tabs were selected for synchronization; local storage, IndexedDB, and several other data types were optional. Verify the synchronization settings your application needs rather than assuming every kind of browser state is saved automatically. A site can still expire a session or require another login.

6. The code: connect Playwright through Remote CDP

For a programmatic Playwright agent, use the documented Remote CDP workflow. This example separates browser provisioning from the page logic and performs cleanup even if connecting or navigating fails.

Install adscrawl and playwright, and set ADSCRAWL_API_KEY in your environment. The example follows the SDK and API documentation; it was not the control method used for the persistent-browser screenshots above.

import { chromium } from "playwright";
import AdsCrawl from "adscrawl";

const client = new AdsCrawl();
let session;
let browser;

async function inspectPage(page) {
  await page.goto("https://www.browserscan.net/bot-detection", {
    waitUntil: "domcontentloaded",
  });
  await page.waitForLoadState("networkidle", { timeout: 20000 });
  await page.screenshot({ path: "browser-check.png", fullPage: true });
  return page.title();
}

try {
  session = await client.cdp.create({
    idleTimeoutMs: 300000,
    maxSessionMs: 600000,
    browserSettings: { viewport: { width: 1440, height: 1000 } },
  });
  browser = await chromium.connectOverCDP(session.cdpBaseUrl);
  const context = browser.contexts()[0];
  const page = context.pages()[0] ?? await context.newPage();
  console.log(await inspectPage(page));
} finally {
  try {
    if (browser) await browser.close();
  } finally {
    if (session) await client.cdp.close(session.sessionId);
  }
}

For a fair local-versus-remote experiment, reuse inspectPage(page) and change the provisioning step. Keep the page actions fixed, record the other configuration differences, and inspect the resulting images before describing either run as a pass.

Persistent Cloud Browser cleanup uses a different endpoint: POST /cloud-browsers/:id/stop. If the response says stopping, poll the profile with a bounded retry loop until runtime.status is stopped. Store the profile ID as soon as it is returned. If a launch response is lost, inspect the profile list before launching again: another launch can create another saved profile.

The Playwright guide and Cloud Browser lifecycle reference document the two flows separately. Never log API keys, token-bearing connection URLs, or proxy passwords.

7. Three practical applications

Regional QA. Use a dedicated profile to check the pricing, language, banners, and available payment options your own site presents in another region. Validate the actual route and locale before attributing a difference to geography.

An agent that resumes a workflow. A persistent profile can retain the browser state selected for synchronization between runs. This is useful for longer tasks, while still respecting login expiry and any re-authentication the site requires.

Data collection with validation. After navigation, check that the expected fields and page structure are present. Keep a screenshot of unexpected responses. Use bounded retries, backoff, and a clear failure state instead of letting an agent repeatedly hammer a challenge page.

These are workflow examples, not measured customer case studies or success-rate claims from this test.

8. What changing the browser does not fix

• A detector verdict is narrow. Normal on one page does not prove access to every target site or every fingerprint check.
• Behavior and history still matter. Request volume, repeated actions, and a site’s knowledge of the session can change the outcome.
• Proxy routing needs verification. A selected region does not establish reputation, a stable exit IP, or consistency by itself.
• Rendering and connectivity can fail. An incomplete checker is an inconclusive result, not a pass. Keep the failure in your notes.
• Persistence is not permanent authentication. Cookies can expire, and storage synchronization must match the workflow.
• Runtime cleanup is part of the job. Close the connection and stop the correct runtime; verify shutdown when the API reports a transitional state.

Use these tools for authorized testing, research, and automation. A browser environment does not change what you are permitted to access.

9. My takeaway

The useful change is treating the browser as an explicit part of an agent’s environment: choose it, configure it, observe it, and clean it up.

The local Playwright baseline was flagged by BrowserScan’s Bot Detection page, while the earlier interactive cloud check returned Normal. The later manual screenshots show BrowserScan at 100%, Pixelscan reporting a consistent fingerprint, and IPhey reporting Trustworthy with an MX Score of 100. These are useful environment checks, with clear limits: the manual follow-up used a different reported profile, and it did not measure a complete automated task.

If your automation already works locally, or the target offers a suitable API, start there. If you need saved browser state, isolated workflows, or regional testing, a persistent cloud profile is worth evaluating against your actual workload.

Try the workflow at AdsCrawl and keep the Cloud Browser documentation open while you build. For reproducible agent automation, start with the Remote CDP and Playwright guide.