Jest w historii agentowego internetu jeden epizod który lepiej niż cokolwiek innego ilustruje problem tożsamości. Amazon wprowadził techniczne blokady dla agenta Comet od Perplexity. Perplexity w ciągu 24 godzin wypuściło aktualizację która te blokady omijała. Jak? Agent przestał przedstawiać się jako Comet. Zaczął przedstawiać się jako zwykła przeglądarka Chrome.
To nie jest obraz skomplikowanego ataku hakerskiego. To jest obraz architektury w której nic nie zmusza agenta do prawdy. User-agent w nagłówku HTTP — dziś główny sposób w jaki strona rozpoznaje kto ją odwiedza — to jest deklaracja. Deklaracja którą agent może zmienić za każdym żądaniem. Nie ma podpisu, nie ma weryfikacji, nie ma rejestru.
Filar piąty agent-readiness mówi: to trzeba zmienić.
Czym jest tożsamość w kontekście agentów
Tożsamość agenta to mechanizmy weryfikacji tego kim jest agent odwiedzający stronę — czy jest tym za kogo się podaje, kto go wysłał i jakie ma uprawnienia do działania w imieniu użytkownika.
Trzy warstwy tego pytania które filar 5 adresuje:
Kim jest agent — czy to GPTBot OpenAI, agent Perplexity, osobisty asystent użytkownika, złośliwy bot który podszywa się pod coś innego? Dziś jedynym dowodem jest user-agent string. Jutro powinno być coś więcej.
Kto go wysłał — czy agent działa w imieniu konkretnego użytkownika który go autoryzował? Czy jest autonomicznym crawlerem bez właściciela? Czy jest agentem firmy który działa w ramach formalnej umowy? To jest pytanie o delegację — nie o agenta samego w sobie ale o człowieka który za nim stoi.
Co mu wolno — jakie ma uprawnienia? Czy użytkownik który go wysłał naprawdę chciał żeby kupił właśnie ten produkt? Czy agent działa w granicach mandatu który dostał? To jest pytanie o uprawnienia agenta i human-in-the-loop.
Trzecia ewolucja zaufania w webie
Jak opisuje artykuł Tożsamość agenta i trzecia ewolucja zaufania w webie — historia internetu to historia kolejnych prób odpowiedzi na pytanie „kto to jest?”.
Pierwsza ewolucja — anonimowość. Wczesny web nie pytał kto przychodzi. Każdy był równie anonimowy. Strony były publiczne, nie było sesji, nie było kont.
Druga ewolucja — federacja i OAuth. Pojawiły się konta użytkowników. Potem OAuth — „zaloguj się przez Google/Facebook” — delegacja tożsamości między platformami. Człowiek ma tożsamość, może ją udowodnić przez zaufaną trzecią stronę.
Trzecia ewolucja — tożsamość agenta. Teraz do gry wchodzi podmiot który nie jest człowiekiem ale działa w imieniu człowieka. Agent AI który wykonuje zadania ma własną tożsamość operacyjną — niezależną od tożsamości użytkownika który go wysłał. I ta tożsamość jest dziś nieweryfikowalna.
Dlaczego user-agent nie wystarczy
User-agent to string tekstowy w nagłówku HTTP który identyfikuje klienta. Przeglądarka Chrome mówi Mozilla/5.0 (Windows NT 10.0) Chrome/120. GPTBot mówi GPTBot/1.0. Comet od Perplexity mówił… cokolwiek chciał powiedzieć.
Trzy powody dla których user-agent jest fundamentalnie niewystarczający jako mechanizm tożsamości w erze agentów:
Łatwy do sfałszowania. Zmiana user-agenta to jedna linijka kodu. Żaden poważny mechanizm tożsamości nie może opierać się na danych które klient może dowolnie zmodyfikować.
Nie mówi nic o autoryzacji. User-agent identyfikuje oprogramowanie — nie użytkownika który je uruchomił ani uprawnienia które mu nadał. Agent który mówi „jestem GPTBot” nie mówi „działam w imieniu Jana Kowalskiego który autoryzował mnie do zakupu do 500 złotych”.
Nie ma rejestru. Każdy może zadeklarować dowolny user-agent. Nie ma centralnego rejestru który weryfikuje że „GPTBot” należy do OpenAI, że „ClaudeBot” należy do Anthropic, że żaden inny podmiot nie podszywa się pod te identyfikatory.
Co się buduje jako odpowiedź
Filar 5 jest najtrudniejszy do zaimplementowania spośród wszystkich sześciu filarów — bo wymaga infrastruktury której jeszcze nie ma. Ale pierwsze elementy zaczynają się pojawiać.
Web Bot Auth — HTTP Message Signatures. Standard IETF w trakcie opracowywania który pozwala botom podpisywać żądania HTTP kryptograficznie. Strona która otrzymuje żądanie może zweryfikować podpis przez publiczny klucz bota opublikowany pod /.well-known/http-message-signatures-directory. To jest coś co nie może być sfałszowane — podpis kryptograficzny jest albo ważny albo nie.
Cloudflare jako część Agents Week 2026 ogłosiło że wspiera ten standard. To jest sygnał że infrastruktura idzie w tym kierunku.
OAuth dla agentów. Standardowy OAuth flow — zaloguj się przez Google, Facebook, Apple — można rozszerzyć na agentów. Agent który chce działać na stronie w imieniu zalogowanego użytkownika może przeprowadzić OAuth flow gdzie użytkownik aktywnie wyraża zgodę na konkretne uprawnienia. Cloudflare Access wspiera to w ramach WebMCP.
/.well-known/openid-configuration wskazuje gdzie agent może znaleźć serwer autoryzacji i przeprowadzić ten flow.
Moltbook i rejestry tożsamości agentów. Meta kupiła Moltbook — platformę która zaczyna budować rejestr tożsamości agentów i ich powiązań z ludźmi. To jest bardziej ambitna wizja — nie tylko weryfikacja kryptograficzna ale semantyczna: ten agent należy do tej osoby, ma te uprawnienia, ma tę historię.
AP2 — Agent Payments Protocol. W kontekście transakcji finansowych AP2 rozwiązuje problem tożsamości przez mandaty — kryptograficznie podpisane dokumenty które dowodzą że użytkownik autoryzował konkretny zakup. To jest tożsamość agenta w kontekście płatności — najbardziej krytycznym kontekście gdzie weryfikacja musi działać.
Co właściciel strony może zrobić dziś
Filar 5 jest uczciwie najtrudniejszy do wdrożenia samodzielnie. Większość rozwiązań wymaga infrastruktury po stronie agenta — a ta infrastruktura dopiero się buduje.
Ale kilka rzeczy ma sens już teraz.
Monitoruj agent fingerprinting. Zachowanie agenta — wzorce zapytań, kolejność odwiedzanych zasobów, timing — jest trudniejsze do sfałszowania niż user-agent. Logi serwera które analizujesz pod kątem wzorców dają więcej prawdy o tym kto u Ciebie jest niż deklaracje w nagłówkach.
Wdrażaj OAuth tam gdzie masz autoryzację. Jeśli Twój serwis ma logowanie — upewnij się że obsługujesz OpenID Connect i że /.well-known/openid-configuration jest dostępny. Agenty które będą chciały działać w imieniu zalogowanych użytkowników będą tego szukać.
Śledź standardy. Web Bot Auth, HTTP Message Signatures, Moltbook — to są rzeczy które będą miały znaczenie za 12-18 miesięcy. Śledzenie ich teraz oznacza że gdy infrastruktura będzie gotowa, nie zaczniesz od zera.
Polityka jako sygnał. Jasna deklaracja na /dla-agentow lub w llms.txt czego oczekujesz od agentów — jakich się identyfikują, jakie mają ograniczenia — to nie jest weryfikowalne technicznie, ale jest sygnałem dla agentów które respektują konwencje.
Dlaczego filar 5 jest strategicznie najważniejszy
Pięć pierwszych filarów opisuje jak sprawić żeby agenty mogły używać Twojej strony. Filar 5 pyta: ale czy chcesz żeby każdy agent mógł to robić bez żadnej weryfikacji?
Gdy agenty będą wykonywać transakcje finansowe, podpisywać umowy, rezerwować usługi w imieniu użytkowników — pytanie „kto to jest” przestaje być akademickie. Staje się pytaniem prawnym, biznesowym i bezpieczeństwa jednocześnie.
Amazon vs Perplexity pokazał że brak odpowiedzi na to pytanie prowadzi do sądu. AP2 pokazał że branża finansowa bierze to poważnie. WebMCP i OAuth dla agentów pokazują że infrastruktura techniczna powstaje.
Właściciele stron którzy zaczną myśleć o tożsamości agentów zanim stanie się to obowiązkowe — będą mieli przewagę której nie da się skopiować w tydzień.
Pojęcia powiązane w słowniku: Tożsamość agenta, User-agent, Agent fingerprinting, Agent hijacking, AP2, WebMCP, Human-in-the-loop, Agent permissions, Filar 4 — operacyjność, Filar 6 — governance
Powiązane artykuły na webflux.pl: Tożsamość agenta i trzecia ewolucja zaufania w webie, Sygnały dla agentów — filar trzeci, Klient, pasożyt, złodziej