TagPatrol
The TagPatrol audit runner

TagPatrolBot/1.0

If you found TagPatrolBot in your access logs or your WAF event feed, this is what it is. It is the headless Chromium that runs TagPatrol’s tracking and consent audits — one page, loaded three times, on behalf of someone who asked for a report about that page.

In a hurry? To let it through, allow requests whose User-Agent contains TagPatrolBot or that come from the addresses 209.71.80.104, 2a09:8280:e632:1:0:187:e1c6:0. To stop it completely, put two lines in robots.txt — both are below.

How to recognise it

Every request carries the same declaration. Nothing about the runner is hidden from your logs:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36 TagPatrolBot/1.0 (+https://tagpatrol.app/bot)
  • Product token: TagPatrolBot/1.0. The token TagPatrolBot is stable and will not change; the version after the slash may.
  • Contact header: every request also sends From: bots@tagpatrol.app (RFC 9110 §10.1.2), so a log line is enough to reach a human.
  • Browser identity: the Chrome portion is honest — it is a current Chromium, driven by Playwright. We do not suppress navigator.webdriver or the client hints that give a headless build away, because the point of the audit is to see what a real visitor’s browser is served, not to be mistaken for one.

Where it comes from

Audits run from a small fixed set of addresses. A WAF rule keyed to these cannot be spoofed by anyone who reads this page, so prefer them over the User-Agent match where your product supports it:

209.71.80.104
2a09:8280:e632:1:0:187:e1c6:0

The same list is published as JSON at /bot/ips.json, in the shape the major crawlers use, so you can automate the allowlist rather than maintain it by hand.

What it actually does to your site

  • Loads the one URL that was submitted, 3 times: once without touching the consent banner, once after “reject all”, once after “accept all”. Each pass uses a clean browser profile.
  • A paid audit additionally walks up to 25 same-site pages found from your links and sitemap. A free scan is that one page only.
  • Roughly 60 requests per page load and 3 loads, so on the order of 180 requests for a free scan — comparable to one person opening the page a few times. One page at a time. It is not a crawl and it is not a load test.
  • It runs JavaScript and accepts cookies — it has to, since the whole subject of the audit is which tags fire and which cookies get set.
  • It clicks exactly one thing: the consent banner’s accept or reject control.
  • It never follows a link off the domain being audited. Third-party requests are recorded — that is the audit — but the browser only ever navigates within the site you asked about.
  • Once a quarter the same runner visits a sample of large sites for our State of Consent Compliance index. Nobody submitted those, so that is the one case where it arrives uninvited — still one page, still 3 loads, still declared, and still stopped by the opt-out below. If it is refused, the index records that as a published statistic rather than trying again another way.

And what it never does:

  • No form submissions. No login attempts, no credentials, no session reuse. No checkout, no cart, no state-changing request.
  • No attempt to defeat a bot check. No residential proxies, no fingerprint spoofing, no CAPTCHA solving. If you block it, it reports to our customer that it was blocked and shows them this page.
  • No scraping of your content. The report records which third-party vendors were contacted, not what your pages say.

Letting it through

Pick your product. In every case it is one rule, and the condition is the same idea: match the User-Agent token or the egress addresses, action allow.

Console menus move between releases. If a menu path below is out of date, the match condition is still the part that matters — put it wherever your product accepts an allow rule, ahead of whatever is currently blocking.

Cloudflare WAF / Bot Management

Where: Dashboard → your domain → Security → WAF → Custom rules

Rule expression

(http.user_agent contains "TagPatrolBot" and ip.src in {209.71.80.104 2a09:8280:e632:1:0:187:e1c6:0})
  1. Create a custom rule named "Allow TagPatrol audit runner" and paste the expression above into the editor.
  2. Set the action to Skip, and tick every check you want bypassed — All remaining custom rules, Managed rules, Rate limiting, and Bot Fight Mode where your plan offers it as a skip target.
  3. Move the rule above anything that currently challenges or blocks bots, then Deploy.

You will recognise a block by cf-ray / cf-mitigated headers, a __cf_bm cookie, or a "Just a moment…" interstitial. Vendor documentation.

Akamai Bot Manager / App & API Protector

Where: Control Center → your security configuration → Bot Manager → Custom bot categories

Bot definition

Request header  User-Agent  contains  TagPatrolBot   OR   Client IP in  209.71.80.104 2a09:8280:e632:1:0:187:e1c6:0
  1. Add a custom bot category "TagPatrol audit runner" defined by the condition above.
  2. In the bot policy that serves this site, set that category's action to Allow (not Monitor, which still scores the request).
  3. If App & API Protector also matches, add a rule exception for the same condition, then activate on staging and production.

You will recognise a block by an "Access Denied" page carrying a Reference #, an AkamaiGHost server header, or _abck / ak_bmsc cookies. Vendor documentation.

Imperva Cloud WAF (Incapsula)

Where: Cloud Security Console → your site → Policies → Bot Access Control

Policy condition

Client Application (User-Agent)  contains  TagPatrolBot   OR   IP  in  209.71.80.104 2a09:8280:e632:1:0:187:e1c6:0
  1. Add a Bot Access Control rule with the condition above and the action Allow.
  2. Check Advanced Bot Protection separately — it carries its own policy and will keep blocking if you only changed Bot Access Control.
  3. Apply the policy to the site, not just to the account default.

You will recognise a block by an x-iinfo header, visid_incap_ / incap_ses_ cookies, or "Request unsuccessful. Incapsula incident ID". Vendor documentation.

DataDome

Where: DataDome dashboard → Protection → Custom Rules

Rule condition

User-Agent  contains  TagPatrolBot   AND   IP  in  209.71.80.104 2a09:8280:e632:1:0:187:e1c6:0
  1. Create a custom rule with the condition above and the action Allow.
  2. Place it above any rule whose action is Block or Challenge — DataDome applies the first match.
  3. Save and deploy; the change is live within a minute, so you can re-run the scan straight away.

You will recognise a block by an x-datadome header, a datadome cookie, or a DataDome-branded block page. Vendor documentation.

HUMAN Bot Defender (formerly PerimeterX)

Where: HUMAN portal → your application → Custom Rules / Allowlist

Rule condition

IP  in  209.71.80.104 2a09:8280:e632:1:0:187:e1c6:0
  1. Add an allowlist entry or a custom rule with the condition above and the action Allow.
  2. IP is the stronger match here — Bot Defender scores on far more than the User-Agent, and an allowlist keyed to the address cannot be spoofed.
  3. Publish the policy; enforcement picks it up on the next request.

You will recognise a block by _px / _pxhd / _pxvid cookies, x-px headers, or "Access to this page has been denied". Vendor documentation.

AWS WAF

Where: AWS console → WAF & Shield → your Web ACL → Rules

IP set / rule statement

aws wafv2 create-ip-set --name tagpatrol-audit-runner --scope REGIONAL --ip-address-version IPV4 --addresses 209.71.80.104 2a09:8280:e632:1:0:187:e1c6:0
  1. Create the IP set above (AWS WAF wants CIDR, so each address needs a /32), or a string-match rule on the User-Agent header.
  2. Add a rule referencing it with the action Allow.
  3. Give that rule a LOWER priority number than AWSManagedRulesBotControlRuleSet and AWSManagedRulesCommonRuleSet — AWS WAF evaluates in priority order and stops at the first terminating action.

You will recognise a block by an x-amzn-requestid / x-amzn-errortype header on a 403, or a bare "Request blocked" body. Vendor documentation.

Azure Front Door WAF / Application Gateway WAF

Where: Azure portal → your WAF policy → Custom rules

Custom rule

Match type IP address  ·  operator Does contain  ·  values 209.71.80.104 2a09:8280:e632:1:0:187:e1c6:0  →  Allow
  1. Add a custom rule with the match above and the action Allow.
  2. Give it a lower priority number than the Microsoft managed rule set — custom rules are evaluated first, lowest number wins, and Allow is terminating.
  3. Save; Front Door propagates the policy in a few minutes.

You will recognise a block by an x-azure-ref header, or the Azure WAF body "The request is blocked.". Vendor documentation.

Fastly Next-Gen WAF (Signal Sciences)

Where: Next-Gen WAF console → your site → Rules

Request rule

Site → Rules → Allowlist → add 209.71.80.104 2a09:8280:e632:1:0:187:e1c6:0
  1. Add a request rule with the condition above and the action Allow, or put the egress addresses in the site allowlist.
  2. An allowlisted address is exempt from flagging as well as from blocking, which is what you want for a scheduled audit.
  3. Save — rules apply at the edge within seconds.

You will recognise a block by x-sigsci headers, or a Fastly/Varnish server header on a 403. Vendor documentation.

F5 BIG-IP Advanced WAF / ASM

Where: Security → Application Security → IP Addresses List (and Bot Defense → Bot Profile)

Trusted entry

IP Addresses List → add 209.71.80.104 2a09:8280:e632:1:0:187:e1c6:0 with "Never block this IP" and "Policy Builder trusted"
  1. Add the egress addresses to the policy's IP address exception list, marked never-block.
  2. If Bot Defense is enabled, also add a trusted-bot signature matching the User-Agent token — the IP list alone does not change the bot verdict.
  3. Apply the policy.

You will recognise a block by "The requested URL was rejected. Please consult with your administrator." plus a support ID, or TS / BIGipServer cookies. Vendor documentation.

Kasada

Where: Polyform console → Policies

Policy condition

IP  in  209.71.80.104 2a09:8280:e632:1:0:187:e1c6:0
  1. Add an allow policy for the condition above, keyed to the egress addresses where possible.
  2. Kasada fails closed on unrecognised automation, so a monitoring plan needs the allow in place before the first scheduled run.
  3. Publish the policy.

You will recognise a block by x-kpsdk headers or a KP_UIDz cookie. Vendor documentation.

Vercel Firewall

Where: Project → Firewall → Custom rules

Rule condition

IP Address  is one of  209.71.80.104 2a09:8280:e632:1:0:187:e1c6:0   →   Allow
  1. Add a custom rule with the condition above and the action Allow (Bypass).
  2. Order it above Attack Challenge Mode and any managed ruleset.
  3. Save and deploy the firewall configuration — it takes effect without a project redeploy.

You will recognise a block by an x-vercel-id header on a 403, or a "Vercel Security Checkpoint" page. Vendor documentation.

Sucuri Website Firewall

Where: Sucuri dashboard → Firewall → Settings → Access Control

Allowlist entry

Access Control → Whitelist IP Addresses → 209.71.80.104 2a09:8280:e632:1:0:187:e1c6:0
  1. Add the egress addresses under Whitelist IP Addresses.
  2. Sucuri's user-agent allowlist is a weaker match than the IP list; use the IP list where you can.
  3. Changes apply at the proxy immediately.

You will recognise a block by an x-sucuri-id header or "Access Denied - Sucuri Website Firewall". Vendor documentation.

Radware Bot Manager / Cloud WAF

Where: Radware portal → Bot Manager → Policies

Policy condition

Source IP  in  209.71.80.104 2a09:8280:e632:1:0:187:e1c6:0
  1. Add an allow policy for the condition above, scoped to the protected application.
  2. Check the separate Cloud WAF rule set — Bot Manager and WAF each carry their own verdict.
  3. Apply and activate.

You will recognise a block by x-rdwr headers or a Radware-branded block page. Vendor documentation.

Queue-it virtual waiting room

Where: Queue-it GO Platform → your waiting room → Integration

Bypass condition

IP  in  209.71.80.104 2a09:8280:e632:1:0:187:e1c6:0
  1. This is a waiting room, not a block: the audit measured the queue page rather than your site.
  2. Add a trigger exception (or an IP bypass) for the condition above so the runner reaches the origin.
  3. Or simply re-run the scan when the waiting room is not active.

You will recognise a block by a Queue-it branded waiting-room page or a QueueITAccepted cookie. Vendor documentation.

Checking a request really is ours

A User-Agent is a claim, not a proof — anyone can send ours. There are two ways to be sure, in order of strength:

  1. Match the address. The list above is the authoritative set of addresses our audits originate from. A request claiming to be TagPatrolBot from anywhere else is not ours, and you should treat it exactly as you would any other unverified bot.
  2. Ask us. Send the log line — timestamp, address, URL, User-Agent — to bots@tagpatrol.app and we will tell you whether it was one of ours and which scan it belonged to. Every audit is logged with its id and time.

Stopping it

You do not have to allowlist anything. Two lines in robots.txt and the runner will refuse the scan before it loads a single byte of your site:

User-agent: TagPatrolBot
Disallow: /

We check robots.txt before every audit. A group that names TagPatrolBot is treated as a refusal, and whoever requested the scan is told the site opted out — not that it blocked them. You can also scope it to part of the site (Disallow: /checkout) and the rest stays auditable.

One deliberate exception, stated plainly. A blanket User-agent: * / Disallow: / does not stop a scan of the URL somebody typed in. That directive is aimed at search indexers, and honouring it here would stop site owners auditing their own checkout pages and staging hosts, which is most of what this product is for. It is honoured for pages our crawler finds by itself. To stop us specifically, name us — that is what the snippet above does.

Prefer email? Write to bots@tagpatrol.app with the domains and we will add them to a refusal list on our side. A blocked WAF works too; it is just noisier for both of us.

Why we ask instead of working around it

Roughly two in five large sites answer a data-centre address with a challenge or a stub page. We could defeat that — the tooling to do it is a search away. We do not, and will not: our operating rules put evasion out of bounds, and an audit tool that lies about who it is has no business telling anyone how to comply with anything. So the runner says what it is, publishes where it comes from, obeys an opt-out that names it, and asks.

TagPatrol is operated by Agent Galactica Pte. Ltd., Singapore (UEN 202539172N). Questions about a scan: support@tagpatrol.app. Questions about the runner: bots@tagpatrol.app. See also our privacy policy and terms.