Fortress Goes Open Source: Building a Stealth Chromium for AI Agents So Automated Browsing Stops Getting Instantly Blocked

On July 7, tiliondev dropped a new project on GitHub — Fortress. In one sentence: a stealth version of Chromium built specifically for AI Agents. The project quickly hit the front page of Hacker News, where half the comments praised the unconventional approach while the other half argued about how long this cat-and-mouse game can realistically continue.

The background barely needs explaining. Over the past year, every team building Browser Agents — whether cloning Claude Computer Use, recreating OpenAI Operator, or developing custom web automation — has been running into the same problem: the moment your Agent starts browsing, it gets stopped by Cloudflare Turnstile, DataDome, or PerimeterX. In mild cases, you get CAPTCHA prompts. In severe ones, your IP gets blocked outright. Legacy tools like Playwright, Puppeteer, and Selenium have fingerprints that anti-bot engines already know by heart. navigator.webdriver=true has basically become an industry meme.

Fortress doesn’t try to patch around the problem. Instead, it goes straight for the Chromium source code itself.

Why Existing Solutions Aren’t Enough

First, it’s important to clarify one thing: the “anti-detection browser” space is already crowded. undetected-chromedriver, playwright-stealth, rebrowser-patches, and Camoufox are all trying to solve similar problems. But almost all of them rely on the same strategy: runtime monkey-patching — hooking the navigator object at the JavaScript layer, spoofing WebGL rendering info, and masking CDP leaks.

The problem is that anti-bot systems in 2026 no longer fall for those tricks. Detection techniques have evolved into things like:

• CDP communication-layer fingerprinting: As soon as you control the browser through Chrome DevTools Protocol, calls like Runtime.enable leave side effects in the prototype chain. Cloudflare challenge scripts can detect them within milliseconds.
• Execution stack tracing: Anti-bot scripts deliberately throw exceptions, then inspect stack traces to look for puppeteer or patched call chains.
• TLS/HTTP2 fingerprints (JA3/JA4/Akamai): These have nothing to do with browser-level spoofing — they leak during the network handshake itself.
• Behavioral fingerprints: Statistical characteristics of mouse movement, typing rhythm, and request intervals.

JavaScript-layer spoofing can cover up the surface symptoms of the first two, but it doesn’t solve the root problem. Fortress’s answer is: modify Chromium itself so these leaks disappear at compile time.

What Fortress Actually Changes

After digging through the repository, Fortress’s core modifications seem concentrated in several areas:

1. CDP Stealth

The biggest change targets CDP itself. In traditional setups, enabling Chrome DevTools Protocol means calls like Runtime.evaluate create observable side effects inside V8 isolation contexts — for example, strings like __puppeteer_evaluation_script__ appearing inside Error.stack. Fortress cleans these identifiers directly at the V8 layer, making remote control look indistinguishable from a user manually pressing F12.

2. Runtime Fingerprint Elimination

Chromium contains plenty of “I am an automation browser” leak points — from navigator.webdriver and window.chrome.runtime to subtle differences in Permissions API responses. Fortress rewrites these in C++ instead of patching them after JavaScript loads.

That distinction is crucial: the browser is already “normal” before any JavaScript executes, so even scripts injected at the earliest possible stage can’t catch inconsistencies.

3. Custom TLS Fingerprints

This is where many “stealth browsers” fail. Chromium uses BoringSSL, and its cipher suite ordering and extension lists during TLS handshakes are relatively fixed. Calculating a JA3 hash immediately reveals that you’re using headless Chrome. Fortress allows TLS fingerprint templates to be specified at startup so it can mimic the handshake characteristics of real Chrome stable releases.

4. Maintaining Playwright/Puppeteer Compatibility

This is the real killer feature. Historically, the biggest problem with custom Chromium forks has been: after modification, the upper-layer ecosystem stops working. Fortress explicitly preserves external CDP compatibility, meaning Playwright, Puppeteer, and even LangChain browser tools can run on top of it without code rewrites.

You only need to point executablePath at the Fortress binary.

# Basic usage
npx playwright test --browser=chromium \
  --executable-path=/opt/fortress/chrome

How Fortress Compares to Similar Projects

Here’s a quick comparison:

| Solution | Layer | CDP Stealth | TLS Fingerprinting | Maintenance Cost | |------|------|---------|---------|---------| | playwright-stealth | JS patch | ❌ | ❌ | Low | | undetected-chromedriver | Python layer | Partial | ❌ | Medium | | rebrowser-patches | Chromium patch | ✅ | ❌ | Medium | | Camoufox | Firefox fork | ✅ | ✅ | High | | Fortress | Chromium fork | ✅ | ✅ | High |

Fortress is most similar to Camoufox in philosophy: both directly fork the browser itself. But Camoufox is based on Firefox, making it incompatible with mainstream Agent frameworks (which are almost entirely Chromium + CDP based). It relies on the Marionette protocol and has a narrower ecosystem.

Fortress bets directly on the Chromium ecosystem itself. The upside is a much higher ceiling. The downside is that it has to track Chromium upstream updates constantly. Chromium ships major releases every four weeks, which makes rebasing a serious workload.

That’s also my biggest concern about the project. Very few open-source teams can sustainably maintain a Chromium fork long-term. Brave and Vivaldi operate at a scale most small teams simply can’t match. Fortress currently appears to be maintained by an individual or small team, so its long-term sustainability remains an open question.

Anti-Bot vs Anti-Anti-Bot: Does This Arms Race Still Matter?

The hottest debate in the comments section was this: now that the project is public, won’t Cloudflare neutralize it overnight?

My view is: probably not in the short term, but it will accelerate the next generation of detection methods. Once all static fingerprints can be erased, the only remaining path for anti-bot systems is behavioral analysis plus server-side reputation systems. IP ranges, account histories, and temporal request patterns aren’t things a browser fork can solve. Fortress merely pushes the front line one step further back — it’s not the endgame.

At a deeper level, the awkward reality of this conflict is that many legitimate use cases get caught in blanket anti-bot enforcement too. Academic researchers scraping public data, companies running E2E tests on their own websites, accessibility tools helping visually impaired users navigate pages — these scenarios are harmless, yet using Playwright alone is often enough to get flagged as a bot. In some sense, projects like Fortress are correcting that overreach.

Of course, it will also be used for gray-market activity. There’s no point pretending otherwise.

Viewing Fortress Alongside Tencent Zhuque’s SkillTrustBench

Interestingly, just days before Fortress launched, Tencent Zhuque Lab and CUHK-Shenzhen released the first Agent skill security benchmark, SkillTrustBench. After scanning over 50,000 Skills on ClawHub, it exposed widespread supply-chain poisoning risks.

Combined with BrowserAct’s recently open-sourced anti-blocking tools and the CloakBrowser project, it’s clear that the entire Browser Agent ecosystem is simultaneously being pulled in two directions: capability expansion and security governance.

On one side, developers are trying to make Agents more capable and harder to block. On the other, security researchers are examining these new entry points as potential attack surfaces. Fortress belongs to the former category, but now that it’s open source, it will inevitably become material for red-team research as well.

From a Developer’s Perspective: Is It Worth Trying?

If you’re working on any of the following, Fortress is worth watching:

• Commercial Browser Agent products: Teams whose customer support lines explode because users get blocked three times a day
• Data pipelines: Legitimate scraping scenarios falsely flagged by anti-bot systems
• E2E testing: Simulating real-user behavior in test environments
• AI Agent framework integration: Browser backends for Claude Computer Use or Operator-style applications

One important caveat regarding adoption cost: Fortress requires either self-compilation or official release binaries. Building Chromium is resource-intensive — realistically, you’ll want at least 32 CPU cores and 64GB of RAM, and initial builds commonly take several hours. For production use, the official binaries are probably the practical choice.

Also, if your model layer already uses aggregated services like OpenAI Hub, pairing Fortress as the browser layer while continuing to use GPT, Claude, or Gemini for planning and reasoning is a very natural architecture. One OpenAI Hub key can cover mainstream models, while Fortress handles the browser side underneath, avoiding duplicated infrastructure work.

Final Thoughts

Fortress is neither the first Chromium stealth fork nor the last. But its timing is notable: Browser Agents are transitioning from demos to production systems. From Anthropic and OpenAI to a wave of startups in China, everyone is betting on this direction. Anti-bot systems have shifted from being a minor annoyance to becoming a critical bottleneck.

An open-source solution that tackles the problem at the source-code level while preserving CDP compatibility is valuable even if long-term maintenance eventually falls behind. The importance of projects like this often lies less in how long they survive and more in how they move the conversation forward.

The next thing worth watching is whether Cloudflare and DataDome introduce new detection rules specifically targeting Fortress. This cat-and-mouse game has only entered a new round.

References

• Fortress GitHub Repository - Project source code and documentation
• SkillTrustBench and Agent Security Evaluation - Research from Tencent Zhuque Lab (Note: the original work comes from Zhuque Lab; see also the AI-Infra-Guard project on GitHub: https://github.com/tencent/AI-Infra-Guard)
• AI Agents and Browser Entry Point Reconstruction - Analysis of the evolution of the Browser Agent ecosystem