Gdy wykrywanie przechodzi z pojedynczych cech na całą sesję, rosną wymagania wobec klienta: spójność wewnętrzna środowiska, izolacja środowisk, ciągłość stanu oraz zgodność wyjścia sieciowego z parametrami geograficznymi.
W ciągu ostatniego roku AI Agents coraz głębiej wchodzą w procesy biznesowe: od wywoływania narzędzi przeglądarkowych po logowanie do systemów zaplecza, obsługę zamówień i odpowiadanie na e-maile. Jednocześnie zmienia się sposób działania systemów kontroli ryzyka: zamiast obserwować pojedynczą cechę przeglądarki, coraz częściej analizują całą sesję.
Wykrywanie przenosi się z pojedynczych cech na całą sesję
Gdy platformy opisują swoje możliwości wykrywania AI, wskazują sygnały behawioralne z całej sesji: czy ruch wskaźnika jest zbyt regularny, czy szybkość i rytm pisania są nietypowe, czy wprowadzanie danych trwa mimo braku fokusu strony, czy pojawia się aktywność wskaźnika, gdy strona nie jest widoczna, oraz czy przebieg działań pozostaje spójny od początku do końca.
Sygnały te mają wspólną cechę: nie zależą od prawdziwości jednego parametru, lecz od ciągłości w czasie. Dlatego manipulowanie pojedynczą cechą niewiele daje wobec tego rodzaju oceny.
Poza sesją istnieje jeszcze warstwa korelacji
Oprócz sygnałów behawioralnych szersza kontrola ryzyka może łącznie analizować środowisko przeglądarki, Cookie, stan logowania, środowisko sieciowe i historię konta: czy środowisko pozostaje spójne, czy Cookie, pamięć lokalna i stan logowania zachowują ciągłość, czy środowisko nie zmienia się zbyt często, czy w sieci nie występują nietypowe skoki, czy wiele kont korzysta z tego samego środowiska przeglądarki oraz czy zachowanie odpowiada normalnemu procesowi biznesowemu.
Te oceny można podzielić na dwie warstwy. Pierwsza to środowisko wykonawcze przeglądarki, które decyduje, czy środowisko i stan logowania mogą zachować ciągłość. Druga to strategia wykonania Agent, która wpływa na to, czy cały przebieg wygląda jak automatyzacja. Problem w dowolnej z tych warstw utrudnia stabilne działanie zadania.
Dlaczego niespójność środowiska może zostać uznana za automatyzację
Łatwiej zrozumieć to od drugiej strony. Prawdziwy użytkownik korzystający z jednej strony na jednym urządzeniu zostawia wiele wzajemnie zgodnych wskazówek: jeśli wyjściowy adres IP znajduje się w określonym regionie, strefa czasowa systemu powinna zwykle być zbliżona; najczęściej używany język powinien rozsądnie odpowiadać regionowi IP; rozdzielczość ekranu, lista czcionek i informacje o GPU powinny do siebie pasować; a Cookie i stan logowania powinny zmieniać się stopniowo, zamiast przy każdej wizycie zaczynać od zera.
Sama niespójność jest anomalią. Wyjście we Frankfurcie przy strefie czasowej przeglądarki ustawionej na Los Angeles; jeden zestaw czcionek i rozdzielczości w tej godzinie, a inny w następnej; pięć kont zalogowanych w ciągu dziesięciu minut w tym samym środowisku. Każdy z tych przypadków jest podejrzany osobno, a razem trudno je wyjaśnić jako zwykłe zachowanie człowieka.
Logika platformy jest prosta: normalni użytkownicy zazwyczaj tak nie działają. W rezultacie koszt utrzymania spójności spoczywa na kliencie.
Cztery obszary przygotowania po stronie klienta
Po pierwsze, wewnętrzna spójność środowiska: strefa czasowa, język, rozdzielczość, czcionki, GPU i powiązane parametry nie powinny sobie przeczyć.
Po drugie, niezależność środowisk: każde zadanie powinno mieć własny katalog danych, własne parametry i własne wyjście sieciowe, aby wiele tożsamości nie było łączonych z tym samym środowiskiem urządzenia.
Po trzecie, ciągłość stanu: Cookie, pamięć lokalna i stan logowania powinny być przechowywane oddzielnie dla każdego środowiska i odtwarzane po restarcie, zamiast wymuszać logowanie od zera za każdym razem.
Po czwarte, zgodność wyjścia z parametrami geograficznymi: gdy region wyjściowy zmienia się na inny kraj, strefa czasowa i język środowiska także powinny się odpowiednio zmienić, aby uniknąć długotrwałych sprzeczności.
Pierwsze dwa punkty dotyczą głównie warstwy środowiska. Dwa ostatnie leżą częściowo w warstwie środowiska, a częściowo w logice planowania. Gdy zespół uruchamia jednocześnie dziesiątki Agents, potrzeby te zwykle trafiają do zarządzania środowiskami, gdzie łącznie obsługuje się odizolowane środowiska, niezależne wyjścia i konfigurację zbiorczą. PurpleMark jest jednym z narzędzi zapewniających tę warstwę.
Kilka starszych metod działa już gorzej
Zmiana wyłącznie User-Agent jest popularna, ale jeśli cechy bazowe pozostają takie same, sprzeczność między UA a rzeczywistym środowiskiem staje się jeszcze bardziej widoczna. Sama zmiana IP ma ten sam problem: cechy urządzenia i rytm zachowania się nie zmieniają, więc inne wyjście nie rozwiązuje kwestii. Tryb incognito wpływa na pamięć lokalną, a nie na cechy urządzenia.
Umieszczanie wielu zadań w tym samym środowisku również nie jest korzystne. Przy równoległym uruchomieniu mogą nadpisywać sobie Cookie i stan logowania, a wiele tożsamości pochodzących z tego samego środowiska samo w sobie jest sygnałem korelacji. Podobnie ustawienie wszystkich czasów oczekiwania na jedną stałą wartość tworzy regularność, którą również można rozpoznać.
Kryteria oceny
Zamiast zastanawiać się, czy poszczególne cechy zostały wystarczająco głęboko ukryte, lepiej zadać inne pytanie: czy środowisko jest wewnętrznie logiczne, czy środowiska są od siebie niezależne i czy rytm zachowania przypomina normalnego człowieka? Dopiero spełnienie wszystkich trzech warunków pozwala mówić o stabilnym działaniu.
Granice
Przejście wykrywania nie oznacza uzyskania pozwolenia na działanie. Należy przestrzegać warunków korzystania i reguł robots platformy docelowej, nie używać fałszywych danych tożsamości, nie omijać technicznych środków ochrony, kontrolować częstotliwość żądań i nie zakłócać normalnego działania usług drugiej strony.
