Gdy człowiek odwiedza stronę internetową, tożsamość ma znaczenie tylko w wybranych momentach. Przy logowaniu. Przy płatności. Przy dostępie do treści premium. Przez większość czasu strona nie wie kto przegląda i nie musi wiedzieć.
Agent AI zmienia tę logikę fundamentalnie.
Agent nie przegląda — agent działa. Rezerwuje, kupuje, wysyła formularze, pobiera dane, wykonuje transakcje. Robi to w imieniu kogoś. I tu pojawia się pytanie które przy zwykłej przeglądarce nie istniało: kto to jest, kto go wysłał, i czy naprawdę ma prawo robić to co robi?
Tożsamość agenta to nie ciekawostka techniczna. To fundament zaufania w ekosystemie gdzie agenty działają autonomicznie w imieniu ludzi i firm.
Trzy pytania o tożsamość
Tożsamość agenta rozkłada się na trzy odrębne pytania, które brzmią podobnie ale dotyczą różnych rzeczy.
Pierwsze: czy agent jest tym za kogo się podaje? To pytanie o autentyczność samego systemu. User-agent można sfałszować jedną linią kodu — jak pokazuje sprawa Perplexity, agent który chce ominąć blokady po prostu deklaruje że jest przeglądarką Chrome. Weryfikacja autentyczności wymaga czegoś trudniejszego do sfałszowania niż nagłówek — kryptograficznego podpisu, certyfikatu, mechanizmu który można sprawdzić zewnętrznie.
Drugie: kto go wysłał? Agent nie działa sam z siebie. Za każdym agentem stoi człowiek albo organizacja która go uruchomiła. Czy właściciel strony może to zweryfikować? Czy agent przychodzący w imieniu firmy X rzeczywiście należy do firmy X? To pytanie o łańcuch delegacji — od użytkownika przez system agentowy do konkretnej akcji na konkretnej stronie.
Trzecie: jakie ma uprawnienia? Nawet jeśli agent jest autentyczny i wiemy kto go wysłał — nie każdy agent powinien móc robić wszystko. Agent wysłany żeby sprawdzić cennik nie powinien móc składać zamówień. Agent który dostał zgodę na przeszukanie oferty nie powinien mieć dostępu do danych transakcyjnych. Uprawnienia agenta powinny być weryfikowalne — nie tylko deklarowane.
Dlaczego to najtrudniejsza warstwa agent-readiness
W sześciu filarach agent-readiness tożsamość jest opisana jako najtrudniejsza warstwa do zaimplementowania i najważniejsza strategicznie. Nie bez powodu.
Czytelność, struktura danych, operacyjność — to są problemy techniczne z konkretnymi rozwiązaniami. Dodaj semantyczny HTML, wstaw JSON-LD, wystaw API. Efekt jest mierzalny, wdrożenie jest przewidywalne.
Tożsamość agenta to problem ekosystemowy. Żeby działała — potrzebuje standardów których wszyscy przestrzegają, infrastruktury weryfikacji którą ktoś utrzymuje, i modeli zaufania które są uznawane przez wszystkie strony. Jeden właściciel strony nie może tego zbudować sam. Jeden twórca agenta nie może tego rozwiązać sam. To wymaga koordynacji na poziomie protokołów i platform.
Protokoły takie jak ACP czy mechanizmy w ramach MCP zaczynają adresować ten problem — ale w 2026 roku ekosystem jest wciąż we wczesnej fazie. Standardy istnieją, implementacje są fragmentaryczne, a większość agentów w produkcji działa na zasadzie wzajemnego zaufania bez twardej weryfikacji.
Praktyczne konsekwencje dla właściciela strony
Brak weryfikacji tożsamości agenta ma konkretne skutki już dziś.
Nie wiadomo ile ruchu na stronie pochodzi od agentów. Nie wiadomo od jakich. Nie wiadomo w czyim imieniu działają. Analytics pokazuje sesje i odsłony — nie pokazuje czy za tym siedzi człowiek czy autonomiczny system który przeszukuje ofertę w imieniu stu różnych klientów jednocześnie.
To jest zarówno problem jak i szansa. Problem — bo właściciel strony nie ma pełnego obrazu kto i jak korzysta z jego treści. Szansa — bo strona która jako jedna z pierwszych wdroży mechanizmy weryfikacji tożsamości agenta i wyraźnie zadeklaruje zasady dostępu, buduje przewagę zanim staną się one standardem.
Agent który wie że zostanie zidentyfikowany i że ma jasno określone warunki dostępu — działa przewidywalnie. Agent który wchodzi w próżnię bez zasad — robi co może.