{"id":492864,"date":"2026-08-30T23:50:16","date_gmt":"2026-08-30T23:50:16","guid":{"rendered":"https:\/\/savepearlharbor.com\/?p=492864"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=492864","title":{"rendered":"Why Your AI Agent Gets Blocked and Your Chrome Doesn’t"},"content":{"rendered":"
\n

Two months ago I gave an agent a simple job: log into a vendor portal, download last month\u2019s invoice PDF, rename it, drop it in a folder. It worked on my laptop. It failed on the server, silently, in a way that took me a full day to understand \u2014 the page loaded, the DOM was there, the login form was there, and the credentials were rejected with a generic error. No CAPTCHA. No block page. Just \u201csomething went wrong.\u201d<\/p>\n

The site had decided my agent was a bot several layers before any of that.<\/p>\n

I build a browser for this problem, so I\u2019ve now read a lot of block pages. The thing I keep having to explain is that \u201cbot detection\u201d is not one check that you either pass or fail. It\u2019s a stack, and the layers fire in order, and the layer that kills you is almost never the one you\u2019re looking at.<\/p>\n

The order things actually happen in<\/h3>\n

Before a single line of your JavaScript runs, the server already has:<\/p>\n

    \n
  1. \n

    Your TLS handshake.<\/strong> Cipher suite order, extensions, elliptic curves, ALPN, GREASE placement. This gets hashed into a JA3\/JA4 fingerprint. A Go or Python HTTP client claiming to be Chrome 140 is over the moment the handshake completes \u2014 the UA says Chrome, the handshake says crypto\/tls<\/code>. That\u2019s not a heuristic, it\u2019s a contradiction.<\/p>\n<\/li>\n

  2. \n

    Your HTTP\/2 frames.<\/strong> SETTINGS values, initial window size, header table size, the pseudo-header order. Chrome sends a specific shape. Most automation stacks that proxy or rewrite requests don\u2019t.<\/p>\n<\/li>\n

  3. \n

    Your headers.<\/strong> Order matters. Presence matters. Sec-Fetch-Site<\/code>, Sec-Fetch-Mode<\/code>, Sec-CH-UA<\/code> and friends are sent by real Chrome in a specific pattern that depends on how the navigation started. The University of Bamberg\u2019s Detecting Bot Detection<\/em> dataset (arXiv:2606.14525, ARES 2026, Tranco Top 1M) found that 75% of the blocks they observed against headless Chromium could be triggered on HTTP header signals alone<\/strong> \u2014 no JS execution required.<\/p>\n<\/li>\n<\/ol>\n

    Only after all of that does the page get to run the fingerprinting script everybody writes blog posts about.<\/p>\n

    This ordering is why \u201cI patched navigator.webdriver<\/code> and it still doesn\u2019t work\u201d is the single most common thing I hear. Of course it doesn\u2019t. You fixed layer 4 of a stack that rejected you at layer 1.<\/p>\n

    Why your own Chrome sails through<\/h3>\n

    Your desktop Chrome passes not because it\u2019s trusted, but because everything about it agrees with everything else about it. That\u2019s the whole game.<\/p>\n