Коли виявлення переходить від окремих ознак до аналізу всієї сесії, вимоги до клієнта зростають: внутрішня узгодженість середовища, ізоляція середовищ, безперервність стану та відповідність мережевого виходу географічним параметрам.
За останній рік AI Agents дедалі глибше входять у бізнес-процеси: від виклику браузерних інструментів до входу у внутрішні системи, обробки замовлень і відповідей на електронну пошту. Водночас змінюється і спосіб оцінювання в системах контролю ризиків: замість одного параметра браузера вони дедалі частіше аналізують усю сесію.
Виявлення зміщується від окремих ознак до повної сесії
Коли платформи описують можливості виявлення ШІ, вони згадують поведінкові сигнали протягом усієї сесії: чи не надто регулярні рухи вказівника, чи не відрізняються швидкість і ритм введення, чи триває введення, коли сторінка не у фокусі, чи є активність вказівника, коли сторінка невидима, і чи зберігається узгодженість дій від початку до кінця.
Ці сигнали мають спільну рису: вони не залежать від правдивості одного параметра, а оцінюють безперервність у часі. Тому зміна лише однієї ознаки майже не допомагає проти такого типу оцінювання.
Поза сесією є ще один рівень кореляції
Окрім поведінкових сигналів, загальний контроль ризиків може спільно аналізувати браузерне середовище, Cookie, стан входу, мережеве середовище та історію облікового запису: чи залишається середовище узгодженим, чи зберігають Cookie, локальне сховище й стан входу безперервність, чи не змінюється середовище надто часто, чи немає аномальних стрибків у мережі, чи використовують кілька облікових записів одне браузерне середовище та чи відповідає поведінка звичайному бізнес-процесу.
Ці перевірки можна поділити на два рівні. Перший — середовище виконання браузера, яке визначає, чи можуть середовище та стан входу залишатися безперервними. Другий — стратегія виконання Agent, яка впливає на те, чи виглядає весь процес автоматизованим. Проблема на будь-якому з рівнів ускладнює стабільне виконання завдання.
Чому неузгодженість середовища може вважатися автоматизацією
Якщо подивитися навпаки, логіка стає зрозумілішою. Реальна людина, яка відвідує сайт з одного пристрою, залишає багато взаємно узгоджених ознак: якщо вихідна IP-адреса розташована в певному регіоні, системний часовий пояс зазвичай має бути поруч; звична мова повинна логічно відповідати регіону IP; роздільна здатність екрана, список шрифтів та інформація про GPU мають узгоджуватися; а Cookie і стан входу повинні поступово змінюватися з часом, а не починатися з нуля при кожному відвідуванні.
Неузгодженість сама по собі є аномалією. Вихід у Франкфурті, а часовий пояс браузера — Лос-Анджелес; один набір шрифтів і роздільна здатність цієї години та інший наступної; вхід у п’ять облікових записів за десять хвилин в одному середовищі. Кожен випадок окремо вже підозрілий, а разом їх важко пояснити звичайною людською поведінкою.
Логіка платформи проста: звичайні користувачі, як правило, так не поводяться. Отже, витрати на підтримання узгодженості лягають на клієнт.
Чотири напрями підготовки клієнта
По-перше, внутрішня узгодженість середовища: часовий пояс, мова, роздільна здатність, шрифти, GPU та інші параметри не повинні суперечити один одному.
По-друге, незалежність середовищ: кожне завдання має мати власний каталог даних, власні параметри та власний мережевий вихід, щоб кілька ідентичностей не пов’язувалися з одним і тим самим середовищем пристрою.
По-третє, безперервність стану: Cookie, локальне сховище й стан входу слід зберігати окремо для кожного середовища та відновлювати після перезапуску, а не починати вхід з нуля щоразу.
По-четверте, узгодження виходу з географічними параметрами: якщо регіон виходу змінюється на іншу країну, часовий пояс і мова середовища також мають змінюватися, щоб уникнути тривалих суперечностей.
Перші два пункти переважно стосуються рівня середовища. Останні два охоплюють і середовище, і логіку планування. Коли команда одночасно запускає десятки Agents, такі потреби зазвичай переходять до керування середовищами, де разом контролюються ізольовані середовища, незалежні виходи та масова конфігурація. PurpleMark — один з інструментів, що надає цей рівень.
Кілька старих підходів працюють дедалі гірше
Зміна лише User-Agent — поширений підхід, але якщо базові характеристики не змінюються, суперечність між UA та фактичним середовищем стає ще помітнішою. Проста зміна IP має ту саму проблему: характеристики пристрою та ритм поведінки залишаються незмінними, тому інший вихід не вирішує питання. Режим інкогніто впливає на локальне сховище, а не на характеристики пристрою.
Розміщувати кілька завдань в одному середовищі також невигідно. Під час паралельного виконання вони можуть перезаписувати Cookie та стан входу одне одного, а кілька ідентичностей з одного середовища вже самі по собі є сигналом кореляції. Так само встановлення всіх пауз на одне фіксоване значення створює регулярність, яку можна розпізнати.
Критерії оцінювання
Замість питання, наскільки глибоко приховані окремі характеристики, корисніше запитати інакше: чи логічне середовище всередині, чи незалежні середовища одне від одного і чи схожий ритм поведінки на звичайне використання людиною? Лише за виконання всіх трьох умов можна говорити про стабільну роботу.
Межі
Проходження виявлення не означає отримання дозволу на виконання дій. Дотримуйтеся умов використання та правил robots цільової платформи, не використовуйте неправдиві дані особи, не обходьте технічні заходи захисту, контролюйте частоту запитів і не заважайте нормальній роботі чужого сервісу.
