Hi everyone, this is Neo.

On September 15, Search Engine Journal republished a piece by Slobodan Manic, founder of No Hacks, with a blunt title: “Meta Published 2 Documents About Muse And Only One Mentions Attacks.”

It looks like a story about Meta’s AI agent. It’s really a story about the third type of visitor your website is about to get. I think it’s the most underrated thing published this week, so let me unpack it properly — and add a few other data sources to build the full picture.

Start With The One Sentence

Meta launched Muse on September 8: a personal agent that can open a browser, fill out forms, negotiate on your behalf, and check out with Link built by Stripe. It runs on a dedicated Muse Secure VM, is US-only for now, and lives in WhatsApp and the Muse app.

The same day, Meta published two documents: a consumer announcement, and an engineering post called “How We Built Safety Into Muse.” Manic pulled the text of both and counted words. The result:

• Across risk, attack, attacker, mistake, untrusted, and prompt injection, the consumer announcement uses them zero times; the engineering post uses them 39 times;
• The engineering post opens by saying any agent like this “will still make mistakes, and it will sometimes be attacked via the data it reads,” and that Meta “designed the system to assume the agent may be under attack and limit the potential damage”;
• Meta offers up to $300,000 for security reports, including up to $130,000 for a successful prompt injection that affects a single user.

A company being that straight with engineers is a good thing. But the two documents describe the same product as two different things: one is a capability story where safety is a finished property, the other is a containment story where the agent is assumed compromised. Read only the one written for you, and you’d never know the second exists in that form.

What made me sit up, though, is a single sentence that appears only in the engineering post:

“When Muse browses the internet, it will appear as your activity, so if you ask Muse to buy a shirt from a clothing designer’s website, that designer might use your visit to show you an ad on Instagram.”

That’s Meta describing the design, not conceding a flaw. Muse drives “a real up-to-date Chromium-based browser.” So in that designer’s data, a person just showed up.

Why This Sentence Matters If You Run A Site

Translated into site-owner terms:

• GA4 logs a visitor session;
• Your retargeting pixel fires a new audience membership;
• Your ad platform starts chasing a human who was doing something else entirely while a virtual machine did the browsing;
• Your conversion rate, bounce rate, and time on page all get polluted by these “visitors.”

And this traffic isn’t a crawler. Crawlers at least identify themselves — mostly. An agent acting as a logged-in user doesn’t, because doing the user is the entire job.

Manic nails the consequence: bot rules name crawlers, machine paywalls check one line of the request, analytics counts a visit as human when a browser runs JavaScript. All three defenses rest on the same assumption — that a machine either declares itself or fails to look like a browser. Agents do neither, and Meta wrote that down.

How Much Of This Traffic Is There Right Now? Three Data Sets

This isn’t futurism. It’s happening.

One — Cloudflare. On June 3, 2026, CEO Matthew Prince posted that it happened faster than he predicted. Cloudflare Radar showed automated requests at 57.5% of HTML web traffic versus 42.5% from humans — the first time in the internet’s history that machine traffic passed human traffic. His earlier estimate was end of 2027, so it arrived roughly 18 months early. To be fair: not all of that 57.5% is agentic AI. Most is still conventional crawlers and malicious bots (roughly 37% bad bots, 14% legitimate crawlers). But agentic traffic is the fastest-growing slice.

Two — HUMAN Security. Its 2026 State of AI Traffic report found agentic AI traffic grew about 7,851% year over year — yes, four digits — with automated traffic expanding roughly eight times faster than human activity. Its April 2026 tracker showed browser-based agents accounting for about 71% of agentic traffic: Perplexity’s Comet at 48.12%, OpenAI’s Atlas at 21.33%, Anthropic’s Claude Chrome extension at 17.33%, and ChatGPT Agent at 8.55%.

HUMAN also flags the part most site owners miss: mainstream analytics can’t distinguish an AI agent from a human visitor, let alone identify which agent it is or what it wants.

Three — Akamai. Its 2026 e-commerce bot threat report found that nearly half (47.9%) of AI bot traffic sits in the commerce vertical, and it names a newer problem: agentic commerce fraud and signal masking, where autonomous shopping agents mimic human micro-behaviors so precisely that fraud detection loses its footing. Akamai’s CTO of security strategy, Patrick Sullivan, frames the goal as “agentic readiness” — welcome legitimate AI, aggressively shut down malicious bots.

One more for context: Cloudflare forecast in March 2026 that bot traffic would pass human traffic in 2027. It crossed 50% on April 27, 2026. Every prediction about when agents arrive has been too conservative — including the optimistic ones.

The Structural Point: Which Tier Are You In?

Manic surfaces something more important than the traffic percentages.

The word connector appears 11 times in Meta’s engineering post. For services Meta has a relationship with, no browser opens at all: the two sides integrate an API, with scoped credentials, a per-worker allowlist, and a service that knows exactly who it’s talking to.

For everyone else, Muse opens Chromium and behaves like you.

So the question for a site owner isn’t whether agents are coming. It’s which tier you’re in.

• If Meta decides to build you a connector, you get an interface and a negotiation;
• If not, you get a machine wearing your visitor’s face.

That’s the fault line forming across the agentic web: agents that can prove who they are, and agents that can only do things.

Neo’s Take: What This Means And What To Do

Three judgments first.

One, your data breaks before your traffic does. Agent traffic isn’t a large share of total requests yet (HUMAN’s measurements run in the millions of requests per month), so it won’t inflate your sessions dramatically tomorrow. But it poisons the sample: parsing prices, comparing specs, running a checkout flow once. Short sessions, few pages, weird conversion patterns. If you’re not segmenting yet, the “rising bounce rate and falling conversion rate” you’re staring at may just be a changed denominator.

Two, blanket-blocking agents blocks your own orders. A very practical reminder sits in the data: an agentic shopper visits one or two pages, submits a form, and leaves — tiny volume, very high purchase intent. One industry write-up describes the pattern well: a user asks an agent to find a plumber and book Saturday morning. The agent opens a few candidate sites, tries to submit a form, gets served a CAPTCHA by the fraud stack, has no human watching at that moment, and moves to the next candidate. You did nothing wrong and lost a booking.

Three, whoever makes their site agent-readable first collects the upside. I heard this exact argument in 2010 — except then it was about mobile. The sites that went responsive laughed two years later; the rest were left optimizing keywords.

Five Things Worth Doing Now

1. Map your robots.txt rules to server-side equivalents.

On March 20, 2026, Google quietly added a new entry to its crawler documentation: Google-Agent, which shows up when an AI assistant on Google infrastructure fetches a page on behalf of a real person. The crucial difference from Googlebot: Google classifies Google-Agent as a “user-triggered fetcher,” which means it generally ignores robots.txt — the same logic as you typing a URL into Chrome. If you want to block or rate-limit it, you need controls at the firewall, CDN, or application layer.

By contrast, OpenAI’s ChatGPT-User and Anthropic’s Claude-User are also user-triggered fetchers, but both companies state they will respect robots.txt.

So if your access policy assumes robots.txt is a universal door, that assumption is now a gap. The action is concrete: list every disallow rule you rely on, decide which ones need a real control at the server, CDN, or WAF, and keep robots.txt as a polite signal rather than a security boundary.

2. Write down a three-tier visitor policy.

The worst move with agent traffic is treating everything as a bot. Make the tiers explicit:

Visitor type	Treatment
Human users	Normal service, normal risk controls
Crawlers (training and search)	Business decision: allow, meter, or require licensing (pay-per-crawl)
Agents (acting for a human)	Prioritize access, give them their own policy and rate limit; block only those spoofing a known user agent

As a baseline, start pulling trends for Google-Agent, ChatGPT-User, Claude-User, and Perplexity-User out of your logs. Most sites still show zero — but a baseline has to exist before a trend means anything.

3. Follow Web Bot Auth — the digital passport for agents.

It’s an IETF effort built on HTTP Message Signatures (RFC 9421): the agent operator generates an Ed25519 keypair, publishes the public key in a discoverable directory (a JWKS), and signs every outbound request. The site, or the CDN/WAF in front of it, verifies the signature and knows exactly who is asking. Spoofing becomes cryptographically impossible rather than merely discouraged.

Where it stands as of 2026:

• Cloudflare leads the proposal; an IETF working group was chartered in 2026;
• OpenAI signs requests from ChatGPT Agent and Operator;
• Cloudflare’s Signed Agents program launched with ChatGPT Agent, Block’s Goose, Browserbase, and Anchor Browser as founding members, and has folded into its Verified Bots program;
• AWS WAF supports verification, and so does Akamai;
• Google has been signing a subset of Google-Agent requests experimentally under the identity https://agent.bot.goog since May 2026, and explicitly advises sites to keep using IP ranges, reverse DNS, and user-agent strings in parallel.

The practical takeaway: ask your CDN or WAF whether it can verify signatures. If yes, turn on verified-agent reporting. If no, ask for a timeline. That determines whether you eventually get graduated quotas — or just an on/off switch.

4. Segment agent traffic out of your analytics.

GA4 now ships an AI Assistant default channel group, which isolates referral traffic from ChatGPT, Gemini and similar assistants. But note: that channel group measures assistants sending people to you. Agent visits on your site are a different thing and need their own session-scoped custom dimension parsed from the user agent. Then build a separate dashboard:

• what human sessions look like;
• what agent sessions look like;
• how your checkout or inquiry funnel performs across both.

A practical caveat: until segmentation matures, treat engagement metrics as trends, not absolutes, because their denominator is being rewritten by machines.

5. Make your site agent-friendly — which mostly means doing accessibility properly.

Google’s official guidance on web.dev now treats AI agents as a distinct audience, and lands on a line worth repeating: “Everything we suggest to make a site ‘agent-ready’ also makes sites better for humans.” Agents read a page three ways — screenshots via vision models, raw HTML and DOM structure, and the accessibility tree, which Google calls a high-fidelity map of interactive elements.

Concretely:

• Use semantic HTML (real <button> and <a>, not styled <div>s);
• Associate every input with a <label for="">;
• Give every interactive element a programmatic name;
• Keep layouts stable (watch CLS — moving elements cause agent misclicks);
• Add cursor: pointer to clickable elements.

Chrome has productized this: Lighthouse has an “Agentic browsing” audit category starting from M150, plus an early preview of WebMCP, which lets a site expose named tools to agents instead of making them guess at buttons. If you’re technical, it’s worth scheduling a test run.

One trap to avoid: don’t do dynamic content swapping in the browser — for example, serving an agent a different phone number. The reason is practical: many AI crawlers don’t execute page JavaScript at all. One study of 500M+ GPTBot fetches found zero JavaScript execution; roughly 69% of AI crawlers can’t run JS. If you genuinely want per-crawler treatment, it has to happen server-side — and stay well clear of cloaking, which Google’s spam policies define explicitly as serving materially different content based on who is asking.

Watch These Signals

Manic offers three to keep an eye on, and I’d just copy them:

1. Whether any of these agents ever carry an identity a website can verify — i.e. how far Web Bot Auth actually lands;
2. Whether the connector list grows — that list is precisely the set of websites that get an interface instead of a browser;
3. Whether the next agent launches with one document or two.

I’d add a fourth: how your GA4 AI Assistant channel group share moves. That’s the most direct reading of where user habits are going.

Manic says there’s nothing useful to do today, and I mostly agree. But how you understand this now decides where you stand in three years. In the mobile shift, the early movers collected the increment. The shape of this one isn’t settled yet, but the direction is: a growing majority of your visitors will be machines — and some of them were sent by a person.