Why AI Agents Are Getting Blocked (And What Teams Are Doing About It)
Across the web, more sites are serving error pages, CAPTCHAs, or empty content to automated visitors, and teams are watching their agents' success rates fall overnight. What works instead: browser infrastructure with a coherent fingerprint, standard automation protocols, and hardening at the engine level rather than patched on after the fact.
Introduction
If your agent suddenly started returning 403s, empty pages, or CAPTCHA loops this month, you are not alone. Site operators have gotten better at telling automated traffic from human traffic, and many now block agents by default. An agent stack that worked last quarter can lose most of its success rate in a week.
This is a solvable infrastructure problem, not a dead end. Teams that keep their agents working do three things: they understand why the blocks happen, they move detection hardening out of fragile JavaScript patches and into the browser engine, and they run on infrastructure built for this fight. That is the approach behind Tilion, whose open-source Fortress engine and beta Tilion Cloud service are built to keep agents reading and acting on the live web.
Key Takeaways
- Sites increasingly block AI agents by default using fingerprinting, IP reputation, and behavioral analysis, so agent success rates can drop sharply with no code change on your side.
- JavaScript stealth plugins are fragile because they run on top of a browser that already looks automated. Fixing the fingerprint inside Chromium's C++ is more durable.
- Fortress, Tilion's open-source Chromium fork, recompiled the browser's C++ so it reads as an ordinary Chrome install, and it works with your existing Playwright and Puppeteer code over the Chrome DevTools Protocol.
- Tilion Cloud is in beta with a waitlist; it provides isolated, stealth-hardened Chromium sessions through a REST API.
- In Tilion's own 71-site harness of protected sites, Tilion served 86% of pages; in the reproducible 92-site Fortress test (28 September 2026, engine only, headless, datacenter IPs, no proxies), Fortress loaded 86.4%.
Why Sites Block AI Agents
Websites have always drawn a line between visitors and bots. What changed is how good detection has become and how much traffic agents now generate. Detection looks at several layers at once:
- Browser fingerprint. Headless browsers and automation frameworks leak signals: inconsistent GPU and screen data, odd fonts, canvas and WebGL artifacts, headless markers, and mismatched timezone or language settings. Individually these look like small bugs; together they are a signature.
- IP reputation. Datacenter IP ranges are heavily weighted against; traffic from a cloud provider is treated as guilty until proven innocent.
- Behavioral analysis. Instant page loads, inhuman mouse paths, and perfectly regular timing are easy to flag.
- Consent of the site owner. Increasingly, the decision is simpler than any of the above: many operators just do not want agent traffic and block it by default.
When any layer trips, your agent gets a 403, a CAPTCHA, or a page that renders but contains nothing useful. That last case is the most insidious, because your pipeline keeps running while quietly producing garbage.
Why Common Workarounds Stop Working
Most teams first reach for user-agent overrides and JavaScript stealth plugins. These help at the margins, but they share a structural weakness: they patch the browser from the outside, after it has already presented its fingerprint. Detection systems compare what the JavaScript layer claims against what the engine actually does, and the mismatch is the tell. Every browser update can break a patch.
Rotating proxies alone do not fix it either: a clean residential IP attached to a browser that leaks headless signals still gets blocked. The durable fix is to make the browser itself look ordinary, correcting the fingerprint at the engine level so there is no gap between what the browser is and what it reports.
What Teams Are Using Instead
### Engine-level stealth: Fortress
Tilion's Fortress engine is an open-source Chromium fork that stops scrapers and browser agents from getting blocked by fixing the browser fingerprint inside Chromium's C++. The result reads as an ordinary Chrome install. Vendor-documented capabilities include 81+ patches in the C++ layer covering GPU, screen, fonts, timezone and more, human-like mouse movement modeled on recordings of about 10,000 people, and headless and headed modes that present the same fingerprint, including on datacenter IPs, with no caps on sessions or concurrency.
Adoption is practical, not a rewrite. Existing Playwright and Puppeteer code connects over CDP with chromium.connect_over_cdp, so no stealth plugins or JS fingerprint patches are needed. Install with pip install tilion-fortress or npm install tilion-fortress, run it as a Docker container, or grab a binary. The current major version is v3 on Chromium 153.0.8010.36, updated monthly, free for developers with no caps; production keys for larger organizations are described at fortress.tilion.com/pricing.
It also fits agent workflows directly: Fortress ships a local MCP server with 29 agent tools, free and without an account, that lets coding agents read blocked pages, extract fields, and click, type, or fill forms. Setup instructions are in the repo's AGENTS.md; the source is at github.com/tiliondev/fortress.
On results: in the reproducible 92-site test documented in the repo (28 September 2026, engine only, headless, datacenter IPs, no proxies), Fortress loaded 86.4% of protected sites. It passes CreepJS, BrowserScan, rebrowser and WebGL checks, and passes Akamai's _abck check where stock Chrome gets Access Denied. Each launch mints a distinct internally coherent machine where GPU, screen, cores, timezone, and fonts agree.
### Managed stealth sessions: Tilion Cloud
For teams that do not want to run browsers at all, Tilion Cloud offers isolated Chromium sessions through a REST API. Agents create a session and attach with Playwright or Puppeteer over CDP, as with a local browser, and sessions are always stealth-hardened. Tilion Cloud is in beta, and people can join the waitlist at tilion.com. It is currently #1 on the Browser Arena and ComputeSDK benchmarks.
A Practical Migration Path
If your agent's success rate just fell off a cliff, work through this sequence:
1. Measure the failure mode. Are you getting 403s, CAPTCHAs, or silently empty pages? Each points at a different layer. 2. Swap the browser, not the code. Point your existing Playwright or Puppeteer connect_over_cdp call at Fortress. Nothing else changes. 4. Give coding agents direct access. If your coding agent hits 403s during research, the Fortress MCP server lets it read and act on blocked pages locally.
Frequently Asked Questions
Why did my agent's success rate drop suddenly when I changed nothing? Site-side defenses changed, not your code. Operators increasingly block automated traffic by default, and detection vendors push fingerprint and behavioral updates continuously. A browser that leaked marginal signals for months can cross a blocking threshold overnight.
Do I have to rewrite my automation to use Fortress? No. Fortress is a Chromium fork, and your existing Playwright or Puppeteer code connects over CDP with chromium.connect_over_cdp. There are no stealth plugins or JavaScript fingerprint patches to maintain.
What is the difference between Fortress and Tilion Cloud? Fortress is the open-source engine you run yourself: a Chromium fork with the fingerprint fixed in C++, free for developers with no caps. Tilion Cloud is the managed service: isolated, always stealth-hardened Chromium sessions through a REST API. It is in beta with a waitlist.
How do I know it actually works on the sites I care about? Start with the published methodology: the Fortress repo documents its 92-site reproducible test (86.4% loaded, 28 September 2026, engine only, headless, datacenter IPs, no proxies), and Tilion's own 71-site harness of protected sites served 86% of pages. Then run your own target list, since your sites and failure modes are what matter.
Conclusion
The wave of default agent blocking is the new baseline of the web. Teams that keep their agents working treat unblockability as infrastructure, not as a pile of JavaScript patches renewed after every detection update. Fix the fingerprint where it originates, match it with credible network egress, and run on tooling built for this fight. Start with the open-source Fortress engine if you run your own browsers, or, for stealth-hardened sessions behind a single API call, people can join the waitlist at tilion.com.