Откъм криптографията: Web Bot Auth променя проверката на AI агентите

От години разчитаме на слаби сигнали за разпознаване на ботове. User-Agent хедъри. IP адреси. Обратни DNS проверки. Това стига за обикновени случаи, но сериозен нападател ги подправя за минути. Със AI агентите навсякъде в мрежата, този подход вече не държи. Като да проверяваш паспорти с лупа, вместо с биометрия.

Тук идва Web Bot Auth – експериментален протокол от IETF, който Google тества активно. Той обръща наопаки цялата логика за автентикация на ботове.

Защо старите методи са проблем

Да сме честни: класическата проверка разчита на нищо стабилно:

• User-Agent хедъри – сменят се за секунди
• IP репутация – зависи от локацията и често лъже
• Обратни DNS – контролираш го ти ли?
• Шаблони в заявките – пълни с грешки

Работи някак си, но е реактивно. Спира дребни злоупотреби, не и професионалисти. А когато законен AI агент блокираш заради смяна на IP? Клиентска ада.

Какво прави Web Bot Auth

Протоколът вкарва криптографска сигурност. Вместо да гадаеш "дали е от Google", проверяваш "дали Google е подписал заявката".

Ключовата идея: агентите подписват с крипто ключове. Ти валидираш подписа самостоятелно. Независи от IP адреси. Защо е гениално:

• Облачните агенти сменят IP често – край на списъците с разрешени адреси.
• Подправянето е невъзможно – криптография, не хедъри.
• Пълна видимост – знаеш точно кой агент е идвал и кога.

Като подписан договор срещу усмено споразумение.

Експериментът в реалността

Спрем се тук: все още е тестова фаза. Google не подписва всичко. IETF спецификацията се доработва. Не сменяй системата си веднага – подготвяй се.

Какво значи на практика:

• Само част от трафика на Google е подписан
• Не всички агенти го ползват
• Може да се промени според отзиви

Затова запази старите методи. IP, DNS, User-Agent остават. Web Bot Auth е допълнение, не заместител.

Как да го включиш сега

Ако ползваш голям CDN или платформа (Cloudflare, AWS WAF, Akamai), провери дашборда – често има бутон за включване.

За самостоятелна проверка, ето стъпките:

1. Изтегли публичните ключове

Вземи ги от https://agent.bot.goog/.well-known/http-message-signatures-directory. Кеширай според Cache-Control. Това е твоята база.

2. Търси Signature-Agent хедъра

Подписаните заявки носят Signature-Agent с g="https://agent.bot.goog". Знак, че има подпис.

3. Валидирай по RFC 9421

Провери Signature срещу Signature-Input с HTTP Message Signatures. Тук криптата потвърждава автентичността.

4. Внимавай с изтичанията

Подписите изгарят. Ключовете също. Проверявай ги отделно.

5. Винаги имей резервен план

Не всички заявки са подписани. Комбинирай с IP, DNS и User-Agent.

Съвет за бързи сайтове: валидирай асинхронно. Отговори веднага, провери после – и блокирай бъдещи заявки от лош агент. Без забавяне.

Защо да те е грижа за инфраструктурата ти

Ако имаш API, SaaS или сайт с трафик, това решава проблеми:

• Точна класификация – законни агенти vs. крадци на данни
• Чисти данни – аналитиката е реална, без фалшиви IP
• По-малко грешки – нямаш ядосани клиенти от блокади
• Готовност за бъдещето – AI агентите ще са норма

Мрежата става място, където машините имат доказуема самоличност.

Какво да направиш днес

1. Провери доставчика си – Cloudflare, AWS? Виж WAF настройките за Web Bot Auth.

2. Прегледай проверките си – Запиши какво ползваш. Къде са слабостите?

3. Следи IETF групата – Промени са неизбежни. Бъди в крак.

4. Тествай с Google – Свържи се с екипа им за опит.

5. Планирай стъпките – С third-party или custom, начертай пътя.

Голямото видение

Web Bot Auth показва: бот трафикът е тук завинаги. Вместо да воюваш с него, дай му крипто самоличност. Сайтовете решават информирано.

Сега е експеримент. После стандарт. После основа. Ако мислиш за ботове, действай предварително.

Краят на доверчивия стискане на ръце. Започва ерата на крипто проверките.