How Browser Vendors Are Quietly Making Automation Harder to Detect

Browser vendors have always had an official position on automation: be transparent about it. 

When the W3C wrote the WebDriver specification—with input from Google, Microsoft, and other major browser vendors—they included a clear requirement. Browsers controlled by automation tools must identify themselves as automated. The mechanism is a JavaScript property called navigator.webdriver. It gets set to true, and any website can check it.

For years, that transparency was a given. The companies shipping the browsers were also the companies helping write the rules. The assumption was that following them would remain the norm. 

But as AI agents take on more of what humans used to do manually—browsing, clicking, filling forms on their behalf—the line between “automated” and “human” is becoming harder to draw. And browsers are starting to reflect that.

The rule and how it worked

The WebDriver specification has existed in its current form since 2018, though browser automation goes back much further. The navigator.webdriver flag was built in from the start: a simple, readable signal that said: “This browser is being controlled by a script.”

In practice, it was never the only signal. Determined bot operators have always known how to flip navigator.webdriver to false manually, so detection tools built more sophisticated methods on top of it: analyzing JavaScript fingerprints, browser inconsistencies, behavioral patterns, and, more recently, signals from the Chrome DevTools Protocol (CDP). We’ve written about this history at length.

What was always assumed, though, is that the browser itself would stay out of it. The game was bot developers vs. detection tools. The browser was neutral infrastructure—a platform that carried the signal, not one that changed it. That’s no longer the case.

Playwright 1.53.0: When AI-driven automation stopped announcing itself

Microsoft’s Playwright is one of the most widely used browser automation frameworks in the world. It powers legitimate test suites, developer tools, and a significant share of bot traffic. In June 2025, version 1.53.0 shipped with a change that had no documentation and no release note callout.

When an AI agent drives Playwright, navigator.webdriver is now set to false—the same value a normal human-operated browser returns. The browser isn’t staying silent about its automated status, but reporting the opposite.

In the normal Playwright tests, navigator.webdriver returns as true

In the MCP Playwright tests, navigator.webdriver returns as false

Our Galileo threat research team discovered this during routine testing. Related improvements have continued shipping as recently as May 2026, all without public comment. 

In the Playwright MCP file, the code disables webdriver by setting a Chrome flag

Microsoft now ships Copilot agents that browse the web on behalf of real users. As AI takes on more of what humans once did manually, the traditional binary—human versus automated—starts to break down. Whether that drove this decision or not, the effect is the same: an AI agent acting on your behalf no longer announces itself as one.

V8: Google closes the CDP detection window

Another recent change follows the same pattern.

In May 2025, Google shipped two patches to V8, the JavaScript engine that powers Chrome and Edge. Both targeted the same thing: a well-known method for detecting when a browser is being controlled via the Chrome DevTools Protocol (CDP).

• Patch 1: Prevent side effects during object preview — submitted May 7, 2025
• Patch 2: Prevent side effects during error preview — submitted May 9, 2025

CDP is the underlying protocol that Playwright, Puppeteer, and most modern automation frameworks use to control Chromium-based browsers. Detecting that a browser has it connected effectively detects most modern bots in a single check, regardless of what other signals they’ve managed to hide.

We documented one of the most effective CDP detection techniques in 2024: when CDP is active, and the automation framework has sent a Runtime.enable command, V8 serializes objects in a way that triggers a custom getter on JavaScript’s Error object. A script can observe whether that getter fires. If it does, the browser has a CDP client connected. If not, it doesn’t.

The technique spread quickly. It became well-documented across the bot development community and was incorporated into test suites for anti-detect frameworks. Some advanced frameworks were already working to circumvent it by avoiding Runtime.enable entirely. The V8 patches take that evasion out of individual bot developers’ hands and bake it into the browser itself.

These two V8 patches close that window. They modify how V8 handles object and error previews in the inspector so that the getter is no longer triggered during CDP-enabled sessions. 

In the code review, the patch author explicitly referenced CDP detection as one of the known misuses the changes were meant to address. The changes were framed as a security improvement—preventing misuse of the browser’s inspector tooling. The effect on bot detection is a consequence of that, whether intentional or not. Both patches were merged into V8’s main branch without broader industry discussion. Chromium-based browsers—Chrome, Edge, Brave, and others—no longer exhibit the behavior that made this detection method work.

When automation becomes the default 

Browser vendors have always faced a tension between enabling automation and enabling detection. For most of the past decade, that tension resolved in favor of transparency: official tools should announce themselves, unofficial ones could try to hide.

The AI agent boom has fundamentally changed what automation means. For most of the internet’s history, automation was a developer tool, sometimes used to test software or, in the wrong hands, to run bots at scale. 

Today, AI agents browse the web on behalf of real users as a mainstream product feature. That changes the context in which signals like navigator.webdriver were designed to operate. They were built for a world where automation was always distinct from human browsing. That world is shifting.

What’s notable is the absence of broader industry discussion around this shift. The W3C specification that established these signals hasn’t been updated to reflect the new landscape, and there’s been no public framing of what these changes mean for the wider web ecosystem. The tooling is evolving faster than the standards.

What this means for the industry

This isn’t a new attack technique from the botting community. It’s something harder to respond to: a structural change made by the vendors who control the browsers.

Security and fraud teams relying on bot detection tools built heavily around browser-level signals—navigator.webdriver, CDP detection, headless mode indicators—should be asking a pointed question: How much of our protection depends on signals that are fading as the nature of browser automation itself evolves?

For simpler or older tools, the honest answer may be: more than they’d like to admit. The browser signals that once reliably indicated automation are no longer a given, and the shift is coming from inside the platform, not from the threat landscape. 

Why DataDome’s approach was built for this 

These changes don’t materially affect DataDome’s detection. That’s by design.

The navigator.webdriver and CDP signals are part of our signal set, but they’ve never been ground truth. Bot developers have been finding ways to hide automation since Selenium’s early days—flipping navigator.webdriver to false became common practice almost as soon as the flag was introduced.

We’ve always assumed these signals are untrustworthy because anyone controlling the browser can change them. Building around that assumption is why our detection isn’t exposed now that vendors are doing the same thing at scale.

DataDome’s detection is multilayered. It analyzes thousands of signals in real time, including signals vendors don’t know about, behavioral patterns that reflect how real users interact with pages, and intent-based heuristics that evaluate what a visitor is actually trying to do. 

What these vendor changes do expose is the risk of single-layer or browser-signal-dependent detection. 

There’s a pattern in both of these changes that goes beyond the specifics: any signal that lives in the browser is a signal vendors can remove. Behavior and intent are a different story.

Want to understand how DataDome detects bots and AI agents that other tools miss? Book a demo to learn more.