A Real Browser No Longer Proves a Human Is Visiting

Your signup page can receive a visit from a full browser, execute JavaScript, and get a completed form while an AI agent operates the session.

That changes a familiar shortcut in bot detection: a convincing browser environment cannot establish that a person is operating it directly.

Meta’s introduction to Muse describes an agent running in a dedicated cloud VM with its own browser. The visitor your site observes can therefore be a remote execution environment serving someone’s task.

For a site owner, the useful questions are concrete: what is this visitor doing, what evidence supports its identity, and what should it be allowed to do next?

Three figures worth paying attention to

In its Q3 2026 AI Traffic Report, published October 15, DataDome reported:

The report covers July–September; its Muse observation window extends from September 22 to October 3. These are DataDome’s measurements, rather than WebDecoy telemetry or estimates of every website’s traffic.

An endpoint request does not establish a completed submission, purchase, or fraudulent action. Our interpretation is that site owners should inspect the actions this traffic attempts, alongside its source.

The browser belongs to the agent

Consider someone asking an assistant to compare products and contact a seller. The assistant can use a remote browser to visit pages and interact with the site. Your application receives requests from that environment.

The IP describes a network exit. A fingerprint describes browser characteristics. A sequence of clicks describes an interaction. Each can contribute evidence, but none establishes the customer’s identity or grants permission to act on an account.

This distinction matters in both directions. A cloud-hosted visit may be useful to your business. A polished browser session may also be attempting an action you would reject.

Your policy needs to account for the resource being requested and the consequences of the action. Reading a public article, submitting a sales inquiry, and claiming a free account benefit deserve different decisions.

Give each signal a specific job

A practical investigation separates four questions:

Keep evidence attached to the decision. If an actor repeatedly requests the same resource, preserve the requests and timestamps that show it. If a rule denies a submission, make the reason inspectable.

For declared crawlers, use the verification methods their operators support. Google’s Web Bot Auth guidance describes a gradual, experimental rollout: some agents and requests remain unsigned. Missing a signature by itself therefore cannot settle an identity or abuse investigation.

Put controls where the action happens

Start with a small set of routes that matter to your business:

• Contact forms: verify the submission on the server before sending email or invoking a webhook. Apply limits that account for repeated submissions.
• Signup and free credits: check eligibility and apply account-level limits before granting the benefit. Make the grant safe to retry without issuing it twice.
• Login and account changes: retain authentication, authorization, and recovery controls. A bot-detection result does not replace them.
• Public content: observe crawl breadth, repeated targets, and request cost. Decide which access patterns you can support before applying broad restrictions.

Record the outcome too. A rejected request, an accepted submission, and a new account with a working install are different events. This is how you learn whether a control protects a useful flow while still letting legitimate visitors finish it.

See the activity before choosing a response

WebDecoy gives site owners a way to investigate that traffic. Combine browser detection signals with edge visibility for clients that do not execute your page’s JavaScript. Inspect agent identity evidence when a visitor claims to be a known crawler.

Use the observed requests to answer the questions that matter to your site: which paths does this actor return to, how broadly does it crawl, and which detections support further action?

Start in monitor mode. Review the evidence and legitimate traffic before choosing enforcement through the integrations you configure.

If your immediate problem is AI agents interacting with a form, FCaptcha is our separate, self-hosted CAPTCHA project built to detect AI agents driving real browsers. Try the demo, then verify its token on your server before executing the protected action. Your application still owns permissions, quotas, and retry handling.

See what is visiting your site: create a free WebDecoy account. No credit card required.