Gdy człowiek odwiedza stronę — granice tego co może zrobić są naturalnie wyznaczone przez interfejs. Może kliknąć to co widzi, wypełnić formularze które są widoczne, kupić to co jest w ofercie. Nie może zrobić nic czego interfejs nie przewiduje.
Gdy agent AI odwiedza stronę — te naturalne granice znikają. Agent może odpytywać API bezpośrednio, pomijając interfejs. Może wykonywać sekwencje działań szybciej niż człowiek — i błąd w jednej decyzji multiplikuje się przez kolejne kroki. Może działać bez nadzoru użytkownika godzinami.
Agent permissions to odpowiedź na pytanie: jak zdefiniować granice dla agenta który nie ma naturalnych ograniczeń interfejsu?
Czym są agent permissions
Agent permissions to zestaw zdefiniowanych możliwości i ograniczeń agenta AI na danej stronie — co może zrobić (czytać, kupować, rezerwować) a czego nie może bez dodatkowej autoryzacji użytkownika.
To nie jest pojęcie czysto techniczne. To jest przecięcie trzech warstw — technicznej, biznesowej i prawnej — które razem definiują przestrzeń działania agenta.
Warstwa techniczna — co strona fizycznie pozwala agentowi wywołać. Które endpointy API są dostępne bez autoryzacji, które wymagają tokenu, które są zablokowane całkowicie. Formularze które agent może wypełnić, akcje które może wywołać przez WebMCP.
Warstwa biznesowa — co właściciel strony chce żeby agent robił. Sklep może chcieć żeby agent mógł przeglądać produkty ale nie finalizować zakupów bez potwierdzenia użytkownika. Serwis z treściami może chcieć żeby agent mógł czytać artykuły ale nie pobierać ich masowo do bazy danych.
Warstwa prawna — co użytkownik autoryzował. Czy wysyłając agenta do zadania użytkownik wiedział że agent może wykonać zakup? Czy wyraźnie to zlecił? AP2 rozwiązuje ten problem przez mandaty — kryptograficznie podpisane dokumenty które dowodzą że użytkownik autoryzował konkretny zakres działań.
Spektrum autonomii — od asystenta do pełnomocnika
Nie ma jednego modelu uprawnień który pasuje do wszystkich sytuacji. Warto myśleć o spektrum.
Tryb tylko do odczytu — agent może przeglądać, wyszukiwać, pobierać dane. Nie może nic modyfikować, nie może inicjować transakcji. To jest tryb domyślny dla AI crawlerów i agentów badawczych.
Tryb z potwierdzeniem — agent może proponować działania ale każde wymaga zatwierdzenia przez użytkownika przed wykonaniem. Human-in-the-loop wbudowany w każdy krok. Bezpieczny ale wolny — użytkownik musi być obecny.
Tryb z granicami — agent może działać autonomicznie w zdefiniowanych ramach. Może kupować produkty do 200 złotych, może rezerwować wizyty w określonych godzinach, może wysyłać emaile z określonej listy odbiorców. Granice są zdefiniowane przez Intent Mandate w AP2 — kryptograficzny dokument który użytkownik podpisuje gdy deleguje agentowi zakres uprawnień.
Tryb pełnomocnika — agent działa w pełni autonomicznie w szerokim zakresie. Ryzykowny bez solidnej infrastruktury tożsamości i autoryzacji. Odpowiada modelowi w którym użytkownik całkowicie ufa agentowi i deleguje mu szerokie pełnomocnictwa.
Większość produkcyjnych wdrożeń dziś działa w trybie z potwierdzeniem lub z wąskimi granicami. Pełna autonomia czeka na dojrzałość infrastruktury tożsamości opisanej w filarze 5.
Jak agent permissions łączy się z human-in-the-loop
Te dwa pojęcia są ze sobą ściśle powiązane — warto je rozdzielić.
Human-in-the-loop opisuje model nadzoru — czy i kiedy człowiek jest włączony w pętlę decyzyjną agenta. To jest odpowiedź na pytanie: kiedy agent pyta użytkownika o zgodę?
Agent permissions opisuje zakres uprawnień — co agent może robić bez pytania, co wymaga pytania, czego nie może robić w ogóle. To jest odpowiedź na pytanie: co agent ma prawo zrobić?
Razem definiują autonomię operacyjną agenta. Szerokie permissions + brak human-in-the-loop = pełna autonomia. Wąskie permissions + human-in-the-loop przy każdym kroku = asystent który tylko sugeruje.
Optymalny punkt zależy od zadania i kontekstu. Agent który przeszukuje sieć w poszukiwaniu informacji nie potrzebuje human-in-the-loop przy każdym zapytaniu. Agent który finalizuje zakup za pieniądze użytkownika — powinien mieć przynajmniej moment potwierdzenia.
Jak definiować permissions — strona kontra agent kontra platforma
Problem z agent permissions jest taki że trzy różne podmioty mają na nie wpływ — i ich interesy nie zawsze są zbieżne.
Strona definiuje co agent może technicznie zrobić — przez API, przez WebMCP, przez robots.txt i dokumentację. Sklep który nie wystawia endpointu do zakupu przez API efektywnie blokuje pełną autonomię agenta zakupowego.
Platforma agenta (OpenAI, Anthropic, Google) definiuje domyślne ograniczenia dla agentów działających na jej infrastrukturze. Claude Code nie będzie wykonywał destrukcyjnych operacji bez potwierdzenia — to jest ograniczenie po stronie platformy, nie strony.
Użytkownik definiuje uprawnienia delegowane konkretnemu agentowi. Przez Intent Mandate w AP2, przez OAuth flow w WebMCP, przez ustawienia w interfejsie platformy agentowej.
Permissions które faktycznie obowiązują to przecięcie wszystkich trzech — agent może tylko to co mu pozwala strona, platforma i użytkownik jednocześnie.
Ryzyko zbyt szerokich permissions — agent hijacking
Jest jeden scenariusz który agent permissions bezpośrednio adresuje jako ryzyko bezpieczeństwa.
Agent z szerokimi uprawnieniami który czyta dane ze stron może zostać zaatakowany przez prompt injection — złośliwe instrukcje ukryte w treści strony które przejmują kontrolę nad agentem. Jeśli agent ma uprawnienia do wysyłania emaili, dostępu do kalendarza i realizacji płatności — złośliwa strona może go skłonić do wykonania wszystkich tych operacji naraz.
Badania bezpieczeństwa MCP z kwietnia 2025 opisały ten scenariusz wprost: kombinowanie narzędzi może prowadzić do eksfiltracji danych nawet jeśli żadne pojedyncze narzędzie nie ma uprawnień do pełnej operacji.
Zasada minimalnych uprawnień — agent powinien mieć dostęp tylko do tego czego potrzebuje do konkretnego zadania — jest fundamentem bezpiecznego wdrożenia agentów. Nie dawaj agentowi który ma wyszukać informacje dostępu do API płatności. Nie dawaj agentowi który ma zarezerwować wizytę dostępu do całego kalendarza.
Co właściciel strony może zrobić dziś
Dokumentuj co agent może zrobić. Na stronie /dla-agentow lub w llms.txt — jasna lista: agent może wyszukiwać produkty, agent może sprawdzać dostępność, agent nie może finalizować zakupów bez potwierdzenia użytkownika. To jest polityka uprawnień w formie czytelnej dla agentów i ludzi.
Projektuj API z permissions w głowie. Endpointy które wystawiasz dla agentów powinny mieć granularne uprawnienia — nie jeden token który pozwala na wszystko. Read-only token dla agentów przeszukujących, osobny token dla agentów transakcyjnych.
Implementuj human-in-the-loop dla wrażliwych operacji. Finalizacja zakupu, usunięcie danych, wysłanie wiadomości — te operacje powinny wymagać potwierdzenia użytkownika niezależnie od tego jak szerokie są uprawnienia agenta.
Śledź co agenty robią. Logi API pokazują które operacje agenty wykonują najczęściej. Anomalie — agent który nagle wysyła 100 zapytań do endpointu płatności — mogą świadczyć o przejęciu przez prompt injection.
Pojęcia powiązane w słowniku: Human-in-the-loop, Agent hijacking, Tożsamość agenta, AP2, WebMCP, MCP, Filar 5 — tożsamość, Filar 6 — governance
Powiązane artykuły na webflux.pl: Klient, pasożyt, złodziej, Tożsamość agenta i trzecia ewolucja zaufania, MCP i bezpieczeństwo