Agent Traffic Is Coming to Your Website: Write Your Door Policy Now

Your website's visitors aren't all people anymore

Two reports landed in the last two weeks that will mostly be read as frontier-lab news. They shouldn't be.

First, security researchers reported making contact with a self-replicating AI agent fleet operating on the public internet — the first documented sighting of agents reproducing outside a lab, per coverage making the rounds in mid-October. Second, Anthropic published research warning that small AI models may be only "months away" from being capable of self-replicating on commercial IoT devices like smart ovens and off-brand Android TV boxes.

The frontier takeaway is doom. The boring takeaway is the one that matters to a business with a website:

Agents are becoming a permanent user class on the open internet. Some are hostile. Some are your customers' assistants. You need a written policy for which doors they get to walk through — and you probably already have agent traffic you've never audited.

Why "block everything" is the wrong reflex

The instinctive response to rogue-agent news is to lock the site down. That's backwards, for one reason: the same traffic class includes your future buyers. When a customer says "find me a plumber who does emergency calls under $200" and their assistant goes shopping, you want to be legible to it — pricing it can read, availability it can parse. Blanket-blocking every agent that knocks closes the door on the sale side of the room, not just the threat side.

So the policy isn't "agents in" or "agents out." It's zoning: three doors, three rules, one page.

The one-page door policy

Door 1: OPEN — your public front room. Pricing pages, service descriptions, hours, FAQs, location info, blog content. This is what a customer's shopping agent needs, and it costs you nothing to give. The job here isn't blocking — it's making this content clean and machine-readable: real prices in text (not images, not "call us"), clear service lists, current availability.

Door 2: VERIFIED — the transaction floor. Forms, checkout, booking, quote requests, account actions. An agent operating here should be acting for a verified human — signed in, or with a session tied to one. In practice: keep CAPTCHA or equivalent verification on forms, don't accept API-style rapid-fire submissions to booking and checkout, and treat any non-human traffic that reaches this floor as a bug, not a customer.

Door 3: BLOCKED — the back office. Bulk scraping of your content, automated form-flooding, credential-stuffing attempts on login, price-inventory probing at machine speed, anything abusing your resources. Rate-limit first, block second, and check what your hosting platform or CDN already does before assuming you need to build anything — most of this is a settings review, not a project.

Write it down as three columns on one page. Name what's in each door, and add one line at the bottom: "When an agent breaks the rules: rate-limit first, block second, escalate to whoever manages the site if it persists." That single page is the deliverable. It turns an abstract threat into a rule your site admin can actually enforce.

The 10-minute access-log check

You already have agent traffic — most businesses have never looked. Ten minutes:

1. Open your server logs or analytics and search for AI crawler user agents. The common ones are easy to find: GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot. Most SMB sites on shared hosting can find this in their control panel's raw access logs; analytics tools increasingly label AI crawlers separately.
2. Look at what they're reading. Crawling your public pages at a polite rate = Door 1 working as intended. Crawling thousands of pages an hour = Door 3 territory, and worth a rate limit.
3. Check for traffic that's fast in a human-impossible way. Form submissions arriving in bursts, booking attempts at machine cadence, login failures in volume. Anything machine-shaped on the transaction floor is your Door 2 policy being tested — and the existing protections (CAPTCHA, rate limits) are the answer.

If you find nothing: you spent ten minutes learning that, filed the one-pager, and moved on. That's the correct outcome for most sites today. The check is cheap precisely because today's traffic is small — the point is having the policy written and the habit established before it isn't.

The honest boundaries

• Blocking is cost-raising, not a wall. Agent traffic can spoof user agents. Your policy doesn't make abuse impossible; it makes casual abuse get throttled and makes the persistent kind visible in logs. That's a realistic goal — perfection isn't on the menu.
• Don't over-rotate on one research report. A single documented wild fleet and a lab's IoT warning are early signals, not an established threat pattern. The one-page policy and log check are proportional responses. Hiring a security firm or rebuilding your site's architecture is not.
• The sales path is the mirror image. This policy governs who gets in. If you also sell through channels where customers' agents act for them, the separate question — whether your pricing, booking, and intake survive being read by a literal-minded assistant — is its own audit, and it's on the other side of the counter.

Tonight's version

Write the three columns. Run the log check. Email the one-pager to whoever manages your site with the line: "if an agent misbehaves, rate-limit first, block second." Total time: half an hour, and your site has a policy for a visitor class that's about to get crowded.

Want the permission frameworks and review checklists for putting AI to work in your business — on both sides of the counter? The Boring Automation Pack includes the templates, approval gates, and guardrail checklists that keep automation useful without becoming a liability.