Key Takeaways
- Agentic browsers like Perplexity Comet, ChatGPT Atlas, and Claude for Chrome render full Chromium sessions and execute every script on a page, so they pass every technical check a traditional bot fails: CDN filters and user-agent blocking never see them.
- HUMAN Security's April 2026 State of Agentic Traffic report found automation growing eight times faster than human traffic, with browser-based agents accounting for roughly 71% of observed agentic activity across the top 10 agents.
- When these agents hit a cookie consent banner, they dismiss it programmatically or ignore it entirely. No informed choice gets made, and the consent management platform records no meaningful signal either way.
- Every marketing pixel and analytics tag on the page fires anyway, which means the site has no documented GDPR Article 6 lawful basis for that processing, because neither the visiting agent nor the human it's acting for ever gave real consent.
- Visually gating a banner does nothing against this traffic; the only enforcement that holds is blocking the underlying scripts and data collection at the source until a genuine consent signal is confirmed, regardless of what rendered the page.
If your site got a visit from Perplexity Comet or ChatGPT Atlas this week, it probably didn't show up in your logs as anything unusual, and that's the problem. An AI agent doesn't read your cookie banner. It renders it, and then it clicks through it, and your analytics platform logs the resulting session as if a person had made a choice, because technically, someone's proxy did, just not in any way GDPR recognizes as consent.
Why cookie banners were never built to handle a visitor like this
Cookie consent banners assume a specific kind of visitor: someone who loads a page, reads two sentences of legal text, and clicks "Accept" or "Decline" with at least a passing understanding of what they just agreed to. Every consent management platform on the market, including Secure Privacy's own, is built around that interaction model. It's also the model that traditional bot detection was built to filter out entirely: search crawlers, scrapers, and scanner bots get identified by user-agent string, missing JavaScript execution, or IP reputation, and either blocked at the CDN or simply ignored because they don't set marketing cookies in the first place.
Agentic browsers break that model from a different direction. Simon Wijckmans, founder and CEO of the agentic-security firm cside, described the distinction plainly in a June 2026 analysis: agentic browsers "open a real Chromium instance, execute every script on your page, generate plausible fingerprints, and interact with DOM elements the way a human would." Tools like ChatGPT Atlas, Perplexity Comet, and Claude for Chrome aren't sending stripped-down HTTP requests. They're running a full browser, loading every asset a human visitor would load, and clicking through the page the way a person would. Wijckmans put the practical consequence in one sentence: "To your server logs, your CDN, and your analytics platform, an agentic browser session looks like a normal human visit." There's no detection signal to filter on, because there's no meaningful technical difference to detect.
This isn't a fringe traffic pattern anymore. HUMAN Security's 2026 State of AI Traffic & Cyberthreat Benchmark Report, released in April 2026, found that automated traffic is now growing eight times faster than traffic from actual humans, and that browser-based agents led by Comet and Atlas account for roughly 71% of observed activity across the ten most active agents tracked. Separately, Adobe reported that AI-referred traffic to U.S. retail sites jumped 269% year-over-year in March 2026 alone. Whatever the exact share on any individual website, the direction is not in question: a growing slice of "visits" are agents completing a task on a human's behalf, not the human clicking through in person.
What actually happens when an agent hits your consent banner
Here's the mechanism, and it matters because "the agent clicked something" is not the same thing as "the agent gave consent." Researchers Alisha Ukani, Hamed Haddadi, Ali Shahin Shamsabadi, and Peter Snyder tested eight widely used browser agents against cookie consent prompts, in a study first reported on by Help Net Security in December 2025, and found the behavior is inconsistent by design rather than uniform. Claude Computer Use and ChatGPT Agent both clicked "accept all" when a page blocked its own content until the banner was dismissed. Browser Use went further, auto-accepting cookies on every test page via a bundled "I still don't care about cookies" extension. Perplexity Comet took a third approach entirely: its built-in ad blocker strips the banner at the network level before it ever renders, so no cookie preference gets set in either direction. Only Google's Project Mariner paused to notify the human operator that a banner existed and asked how to proceed, and only two of the eight agents tested (Claude for Chrome and Browserbase's Director) rejected cookies by default in at least one scenario. The study logged 30 distinct privacy vulnerabilities across the eight products, with every single one showing at least one issue.
None of that is informed consent under GDPR. An agent clicking "Accept All" to clear an obstacle in its way is functionally identical to a script auto-clicking through a banner: it satisfies nothing about the statutory standard, which requires that consent be freely given, specific, informed, and unambiguous, indicating a clear affirmative action by the actual data subject. The agent isn't the data subject. It's also not clear the agent's operator ever saw the banner at all, since many agentic sessions run with minimal or no visible rendering back to the human who issued the task. As Wijckmans's analysis put it, in the more common failure mode "the agent encounters your cookie banner but does not make an informed choice, dismissing or ignoring it and leaving no documented consent signal." Auto-accept, silent dismissal, and network-level banner stripping are three different mechanisms, but none of them produces a valid consent record, and in the auto-accept and silent-dismissal cases specifically, the result at the infrastructure level is the same: every marketing pixel, analytics tag, and third-party tracker on the page loads and fires during that session, consent gating notwithstanding.
The GDPR Article 6 gap this creates
GDPR Article 6 requires a documented lawful basis for every processing activity: consent, contract necessity, legitimate interest, or one of the other three grounds set out in the regulation. For cookie-based tracking specifically, consent is almost always the operative basis, which is exactly why the banner exists. When an agentic session triggers analytics and marketing scripts without a genuine consent signal, the site has none of the six lawful bases actually satisfied for that instance of processing. It isn't consent, because no informed choice was made. It isn't legitimate interest, because tracking-for-advertising doesn't qualify on its own under the EDPB's balancing test. There simply is no basis on file for that specific pixel fire, on that specific visit, and that gap sits with the controller (the website operator), not with whoever built the agent.
This is a documentation problem before it's anything else, and it's a novel one. Existing GDPR enforcement around cookies has focused on human-facing failures: pre-checked boxes, dark patterns that make "reject" harder to find than "accept," or scripts that fire before any banner interaction happens at all. Agentic traffic introduces a new failure mode that doesn't fit neatly into any of those categories, because the banner itself may have rendered and been "interacted with" in a technical sense, just not by anyone capable of giving consent. A regulator auditing a company's consent logs today would see a session, a click, and cookies set. Whether that click came from a human or an agent acting faster than any person could read the banner is invisible in a standard consent log unless the platform is specifically built to flag it.
Why blocking-before-consent is the only version of enforcement that survives this
The instinct for a lot of website operators has been to treat the cookie banner as the compliance control: get a banner up, style it correctly, log the clicks, done. That was always a slightly generous reading of what GDPR requires, and agentic traffic exposes exactly why. A banner is a UI element. It's something to look at and click through, and an agent can do both of those things without anything resembling consent occurring. The actual GDPR obligation was never "show a banner." It was "don't collect data until you have a lawful basis to do so." Those are different requirements, and only the second one survives contact with a visitor that doesn't read.
The technical fix that holds up here is blocking the underlying scripts and data collection until a genuine consent signal is confirmed, rather than relying on the banner's visual presence to do that work. This is the distinction between a banner that gates itself and a banner that gates the rest of the page: with the latter, no cookies or trackers get placed on a device at all until a visitor, human or otherwise, takes a real, verifiable consent action, so an agent that dismisses or ignores the banner without a valid interaction simply doesn't trigger the scripts behind it. Secure Privacy's cookie-blocking control works on exactly that model: nothing loads until the visitor clicks the banner, with blocking enforced against the scripts and trackers themselves rather than layered on top of a banner that anyone or anything can click past. Paired with automated, exportable consent logging that timestamps and records every accepted, declined, or partial response, that combination gives a controller something to point to if a regulator ever asks who consented to what, closing a real gap in a standard visual-only banner setup that never captures anything beyond "a click happened."
None of this requires guessing at how a specific agent behaves internally, which is good, because that behavior changes by the week and no operator should be building a compliance program around the assumption that a particular AI product will keep behaving the way it does today. Blocking-first architecture doesn't need to know whether the visitor is Perplexity Comet, a human on Safari, or something that doesn't exist yet. It just needs a verified signal before anything fires, and if a session never sends a valid one, nothing gets collected. That's the property that actually holds up as agent traffic keeps growing, rather than a piecemeal fix aimed at whatever the current leading agentic browser happens to do.
What to audit on your own site right now
A few checks are worth running before assuming your setup is already fine. First, confirm your consent management platform actually blocks cookies and tracking scripts at the source rather than only rendering a banner on top of a page that keeps loading everything regardless. This is the single most common gap, and it's often invisible until someone checks the network tab. Second, review your consent logs for sessions where a banner interaction is recorded with no measurable time between page load and the click; a human reading two sentences of legal text and making a decision takes at least a few seconds, and a sub-second "accept" is a signal worth investigating, not a normal user. Third, check whether your current CMP configuration distinguishes between a visually dismissed banner and a verified consent event tied to the actual scripts firing. If those two things aren't the same event in your system, you likely have exposure. Finally, revisit your Article 30 records of processing to see whether "agentic or automated visitor traffic" appears anywhere as a documented category; for most organizations right now, it doesn't, and that's the gap this whole problem lives in.
None of this is about detecting or blocking AI agents as visitors, which is a separate security question outside this article's scope. It's about making sure your site never treats an unverified click, from anything, as a lawful basis for processing.
Frequently Asked Questions
Are AI shopping agents and browsers illegal to use on websites under GDPR?
No. Using or allowing agentic browsers on a website isn't itself a GDPR violation. The violation risk comes from what the website does in response: if analytics, advertising, or tracking scripts fire without a valid, documented consent signal during an agentic session, that specific instance of processing has no lawful basis under Article 6, regardless of what triggered it.
Can an AI agent legally give cookie consent on a user's behalf?
Not in any way that satisfies GDPR's consent standard. Consent under Article 6 must be a freely given, specific, informed, and unambiguous action by the actual data subject. An agent auto-clicking "Accept All" to clear an obstacle, or dismissing a banner without evaluating it, doesn't meet that bar even if the human it's acting for would have consented if asked directly.
Do agentic browsers get blocked by normal bot-detection tools?
Usually not. Traditional bot detection relies on signals like missing JavaScript execution, generic user-agent strings, and known scraper IP ranges. Agentic browsers run full Chromium sessions, execute every script on the page, and generate browser fingerprints consistent with a human visitor, so they pass most detection layers built for older bot traffic.
What's the difference between blocking cookies visually and blocking them technically?
A visual gate hides the page's content behind a banner but may still let scripts load in the background; a technical block prevents the underlying script or tracker from executing at all until a verified consent signal is received. Only the second approach stops data collection when a banner gets dismissed without a genuine consent decision, which is the exact scenario agentic traffic creates.
Do all AI agents handle cookie banners the same way?
No, and that inconsistency is itself part of the problem. Academic testing of eight major browser agents found Claude Computer Use and ChatGPT Agent both auto-accepted cookies when a page blocked content until the banner was cleared, Browser Use auto-accepted on every test page via a bundled extension, Perplexity Comet strips banners at the network level before they render, and only Google's Project Mariner paused to ask the human operator how to proceed. No consistent, GDPR-safe default exists across current agents.
How common is agentic browser traffic right now?
It's growing quickly. HUMAN Security's April 2026 benchmark report found automated traffic growing eight times faster than human traffic, with agentic browsers accounting for roughly 71% of observed activity among the top agents tracked, and Adobe separately reported a 269% year-over-year jump in AI-referred traffic to U.S. retail sites in March 2026.
Should I add an EU AI Act layer to how I think about this, or is this purely a GDPR issue?
This specific gap is a GDPR Article 6 documentation problem: it's about lawful basis for cookie-based tracking, not about classifying or governing the AI agent itself. If your organization is separately deploying or building AI systems, those activities may trigger distinct EU AI Act obligations, but that's a parallel compliance track, not a substitute for fixing the consent-gating gap on your own site.
Agentic traffic is only going to make up a larger share of the sessions hitting your site from here, and a banner that merely displays correctly was never going to be enough to prove a lawful basis for the visitor it can't actually get a real answer from. Secure Privacy's cookie and consent solution blocks cookies and trackers at the script level until a verified consent signal is received, and logs every accepted, declined, or partial response automatically so there's a real audit trail behind every session, human or otherwise. If you're not sure whether your current setup blocks at the source or just visually gates a banner, that's the first thing worth checking today.
