Владельцы сайтов последние два года решают, пускать ли AI-краулеры, блокировать их или считать как новый источник визитов. Обсуждение вокруг Known Agents показало более жёсткую практическую проблему: запрос с именем ClaudeBot, Googlebot или другим знакомым crawler в заголовке User-Agent не доказывает, что он пришёл от этого crawler. Это может быть обычный сканер уязвимостей, который взял уважаемое имя.

Панель firewall проверяет подозрительные User-Agent заголовки AI-краулеров Поводом стал тред Hacker News от 12 августа 2026 года со ссылкой на Known Agents и заголовком “Someone is running mass vulnerability scans, spoofing AI bots like ClaudeBot”. Он важен не как судебный протокол, а как снимок того, что администраторы и так видят в журналах: пробы /wp-login.php, .env, admin-панелей, API-маршрутов и тестовых инструментов всё чаще приходят под именами, похожими на поисковых роботов или AI-ассистентов. Публичный Agentic Web Index от Known Agents добавляет контекст: автоматизированный трафик уже не редкость, а измеримая часть веб-инфраструктуры.

Что подтверждено и где нужна осторожность

Аккуратная формулировка такая: Known Agents классифицирует автоматизированный трафик по типам, среди них AI assistants, AI agents, AI coding agents, AI data scrapers, AI search crawlers, поисковые роботы, security scanners, обычные scrapers и undocumented AI agents. На момент исследования страница insights показывала 35 процентов bot traffic, 29 процентов AI-related внутри bot traffic, 0,1 процента AI chat referral volume от human visits и 98,5 процента robots.txt effectiveness. Это метрики продукта на выборке сайтов, а не перепись всего интернета, поэтому их лучше читать как операционный сигнал, а не универсальный закон.

В обсуждении Hacker News многие участники напоминали, что User-Agent легко подделать, поэтому надо смотреть на IP, ASN, reverse DNS и контекст хостинга. Другие говорили, что массовые сканы были всегда. Оба тезиса совместимы. Новизна не в существовании сканеров, а в том, что легитимный AI-трафик даёт злоумышленникам удобную маскировку.

Нельзя писать, что Anthropic, OpenAI или Google проводят вредоносные сканы только потому, что их bot names встречаются в логах. Официальная документация описывает легитимных crawlers и правила robots.txt; злоумышленник может скопировать строку без отношения к компании. Разница между “ClaudeBot” и “traffic claiming to be ClaudeBot” — суть проблемы.

Почему User-Agent не паспорт

Заголовок User-Agent легко отправить. Это самоописание клиента, а не криптографическая личность. Любой скрипт, сканер, proxy или скомпрометированный сервер может поставить ClaudeBot/1.0, Googlebot, ChatGPT-User, строку браузера или выдуманное имя. Журнал честно сохранит label, но не подтвердит владельца соединения.

Раньше это было терпимо для базовой аналитики. Теперь тот же field иногда используют, чтобы разрешать массовый crawling, считать AI referrals, снижать rate limits, освобождать traffic от bot challenge или приглушать alerts. Поддельное имя загрязняет dashboards, прячет probes в trusted buckets и заставляет incident response начинать с неверной гипотезы.

Поэтому поисковые системы давно публикуют инструкции verification. Google советует проверять Googlebot через reverse DNS и обратное совпадение DNS, а не верить строке. Cloudflare разделяет verified bots и неподтверждённый automated traffic, отдельно описывает AI bots. Практический вывод один: identity требует подтверждения через сеть, документацию поставщика и поведение.

Практическая проблема AI-внедрения

AI меняет среду тремя способами. Во-первых, легитимных автоматических fetchers стало больше: search crawlers, assistant fetchers, training crawlers, coding-agent browsers и data scrapers имеют разные цели. Во-вторых, бизнес хочет считать видимость в answer engines и referrals из AI-чата. В-третьих, attackers выигрывают от путаницы: bot name, который раньше выглядел подозрительно, теперь звучит стратегически важным.

Отсюда ловушка governance. Блокировать все AI-labelled requests — можно потерять полезные citations и assistant visibility. Разрешать всех, кто назвался известным AI crawler, — дать scanners бесплатный костюм. Считать robots.txt access control — путать добровольный протокол с защитным слоем. Robots.txt полезен для cooperative crawlers, но не остановит поиск секретов.

Для SaaS риск шире, чем scraping. Быстрые internal tools, AI-generated dashboards, preview deployments и забытые admin panels стали обычными. Scanner с дружелюбным именем будет проверять именно такие места: exposed environment files, debug routes, старые WordPress endpoints, test APIs, временные uploads и unauthenticated health checks.

Таксономия для журналов

Сначала классифицируйте traffic, а не решайте allow/block. AI assistant fetcher открывает страницу по запросу пользователя. AI search crawler индексирует её для answer products. Training или data-scraping crawler собирает content at scale. Coding-agent browser ходит по docs, package pages, GitHub files или application previews. Security scanner ищет known weaknesses. Malicious impersonator берёт имена любой из этих групп.

Каждой категории нужна отдельная policy. Assistant fetchers можно пускать на умеренной скорости, если они соблюдают robots.txt и clearly identify themselves. Training scrapers часто требуют licensing и жёстких limits. AI search crawlers лежат между marketing opportunity и content-control concern. Security scanners допустимы только если это ваш vendor, bug-bounty partner или known research organization. Unknown traffic с известным именем должен оставаться suspicious до verification.

В логах нужны raw User-Agent, source IP, ASN, hosting provider, reverse DNS, forward-confirmed DNS where available, path, status code, rate, robots.txt behavior, challenge result и final policy decision. Без этих полей post-incident analysis превращается в спор впечатлений.

Что делать сейчас

Перестаньте писать rules, доверяющие name alone. WAF rule “allow if User-Agent contains ClaudeBot” слишком мягкое. Замените его проверкой vendor-documented identity, network reputation, request rate, path sensitivity и behavior. Если полной проверки нет, используйте low-trust lane: public content at conservative rates, challenge unusual behavior, block sensitive paths.

Разведите robots policy и security policy. Robots.txt говорит cooperative crawlers, что можно для training, search или assistant retrieval. Он не защищает private routes, staging hosts, admin tools и API endpoints. Sensitive paths требуют authentication, network controls, deny rules и monitoring независимо от имени бота.

Держите purpose-specific allowlists. Список поисковых роботов не равен списку AI assistants, security vendors и analytics tools. У каждой записи должны быть reason, owner, documentation, allowed paths и rate. Удаляйте entries, которые никто не может обосновать.

Защитите скучные paths: .env, /admin, /wp-login.php, /debug, /api/user, staging hostnames и forgotten test tools. Rate-limit probes, возвращайте consistent denials, не отдавайте stack traces. Preview deployments и AI-built prototypes должны наследовать базовые controls production.

И не смешивайте AI referral analytics с bot identity. Полезно знать, пришёл ли человек из ChatGPT, Claude или Perplexity. Это другое, чем решение, можно ли automated request crawl. Marketing хочет visibility, security хочет confidence, а header string не даёт ни того ни другого.

Чего не делать

Не блокируйте весь AI traffic рефлекторно, если бизнес-модель этого не требует. Некоторым сайтам нужны citations, assistant retrieval и developer traffic. Blanket block бывает верным для paid archives, private docs или fragile infrastructure, но это должно быть explicit decision.

Не разрешайте famous names по умолчанию. Именно это показывает история spoofing. Известное имя — claim, требующий проверки. Не глушите alerts только потому, что label говорит Googlebot, ClaudeBot или ChatGPT-User. Не пускайте такие labels в staging, internal search, admin paths и unpublished APIs.

Не ждите, что один vendor product решит policy problem. WAF, bot scores, reverse DNS, verified-bot feeds, rate limits и SIEM enrichment полезны, но organisation всё равно должна решить, какие automated uses welcome.

Дальше нужны подписанные агенты

Долгосрочный ответ — более сильная identity для automated agents: signed crawler requests, verified-agent registries, mTLS-like relationships for high-value APIs, token-based partner access, platform attestations и standard disclosure of agent purpose. У каждого пути есть цена: меньше spoofing, но больше centralization и барьеров для small crawlers.

Пока стандарты не созрели, сайтам нужны layered heuristics. Проверяйте network там, где есть документация. Challenge или rate-limit ambiguous traffic. Отделяйте public content от sensitive systems. Делайте logs достаточно богатыми. И явно признавайте trade-off: видимость в AI answers имеет ценность, но uptime, security, licensing и trust тоже имеют цену.

Короткий рабочий чек-лист

За неделю проверьте пять вещей. В logs добавьте User-Agent, IP, ASN, reverse DNS и final bot decision. В firewall пересмотрите rules для known crawlers, sensitive paths, high-rate requests, failed challenges и suspicious hosting providers. В robots.txt разделите AI training, AI search и generic crawling там, где vendors поддерживают distinctions. В analytics отделите human AI referrals от automated bot visits. В engineering убедитесь, что preview deployments, internal dashboards и AI-generated tools требуют authentication до выхода в public internet.

Главный урок прост: AI traffic стал обычным infrastructure traffic. Поэтому его надо измерять и управлять им. Но это также привлекательная маскировка. Если crawler name может набрать кто угодно, имя не паспорт. Это claim; проверяйте всё, что можно проверить, и проектируйте систему так, чтобы forged label не становился security decision.

Источники

Known Agents Agentic Web Index и страницы ClaudeBot и ChatGPT-User; Hacker News item 49272569; документация Anthropic о crawler; документация OpenAI bots; Google Search Central по robots.txt и verifying Googlebot; Cloudflare bot, verified bot и AI bot documentation.