Naprawiłeś okno zgody. Pokazuje rozwiązaną ścieżkę, realny skutek, ostrzeżenie przy akcji wychodzącej poza projekt. Wszystko zgodnie z checklistą.
I właśnie dlatego przestało chronić.
W poprzednim wpisie tej serii opisałem punkt kontrolny, który kłamie: okno zgody pokazujące etykietę zamiast celu, przez które deweloper zatwierdzał zapis do ~/.ssh/authorized_keys, widząc na ekranie project_settings.json. Wnioskiem był parytet informacji — człowiek ma widzieć to, co wie agent w momencie decyzji.
Ten wpis jest o tym, co zostaje, gdy parytet informacji jest już zachowany. Bo okazuje się, że to nie wystarcza — i drugi tryb awarii jest trudniejszy, bo nie naprawisz go żadną poprawką w oknie.
Dwa różne sposoby, na jakie punkt kontrolny przestaje działać
Warto je rozdzielić, bo wymagają różnych narzędzi.
Awaria informacji. Człowiek nie mógł podjąć dobrej decyzji, bo okno pokazało mu nieprawdę. Agent wiedział, dokąd prowadzi zapis, i tego nie wyświetlił. To jest problem projektowy i ma rozwiązanie techniczne: rozwiąż ścieżkę, pokaż skutek, nie zapisuj przed zgodą.
Awaria uwagi. Człowiek mógł podjąć dobrą decyzję i jej nie podjął. Okno pokazywało wszystko, co trzeba — pełną ścieżkę, ostrzeżenie, wyróżnienie. Kliknął „akceptuj” po ułamku sekundy, bo klikał już dziś czterdzieści razy i za każdym razem było w porządku.
Pierwsza awaria mówi: nie mógł wiedzieć. Druga: mógł, ale nie spojrzał.
To drugie nazywam zeszklonym zatwierdzaniem — od zeszklonego wzroku, który przechodzi przez ekran, nie zatrzymując się na treści. Człowiek patrzy i nie widzi. Formalnie jest w pętli. Faktycznie już z niej wypadł.
Dlaczego to nie jest wina człowieka
Najłatwiejszy wniosek brzmi: trzeba uważniej czytać. To wniosek fałszywy i warto zrozumieć, dlaczego.
Wyobraź sobie dewelopera, który przez tydzień pracuje z agentem i zatwierdza dwieście operacji. Sto dziewięćdziesiąt dziewięć jest nieszkodliwych. Jaki wniosek wyciągnie o dwusetnej?
Że prawdopodobnie też jest nieszkodliwa. I będzie miał rację — statystycznie. To nie jest niedbalstwo, tylko poprawne wnioskowanie z obserwacji. Człowiek nauczył się dokładnie tego, czego system go uczył: że ten monit prawie nigdy nie oznacza problemu. Zeszklone zatwierdzanie nie jest brakiem dyscypliny. Jest wyuczoną odpowiedzią na sygnał o niskiej wartości informacyjnej.
To zjawisko jest opisane poza agentami AI, i to od dawna. W badaniach nad czynnikiem ludzkim funkcjonuje jako automation bias — skłonność do przyjmowania rekomendacji systemu bez niezależnej weryfikacji, rosnąca wraz z jego wcześniejszą niezawodnością. W medycynie ma własną nazwę i własną literaturę: alert fatigue, czyli zjawisko, w którym systemy ostrzegania o interakcjach lekowych generują tyle powiadomień, że personel zaczyna je odrzucać odruchowo — łącznie z tymi, które są trafne. Wniosek z tamtych badań jest niewygodny dla każdego, kto projektuje nadzór: problemem nie była jakość ostrzeżeń, tylko ich liczba.
Agentic web odtwarza ten sam mechanizm, tylko szybciej. Asystent kodujący potrafi wygenerować w godzinę tyle próśb o zgodę, ile system szpitalny w ciągu dnia.
Cztery sposoby, na jakie zgoda traci znaczenie
Taksonomia zagrożeń dla Model Context Protocol ma dla tego osobną pozycję — jako klasa podatności, nie jako niedopatrzenie użytkownika. Wyróżnia cztery mechanizmy, przez które kontrola zatwierdzania przestaje być kontrolą:
Obcięty kontekst. Okno pokazuje opis operacji skrócony do jednej linii, z wielokropkiem w miejscu, gdzie zaczynało się to, co istotne. Formalnie informacja była dostępna. Praktycznie nie zmieściła się w widoku.
Zmęczenie częstotliwością. Prośby pojawiają się tak często, że użytkownik uczy się je zamykać bez czytania. To jest mechanizm opisany wyżej — i jedyny z czterech, którego nie da się naprawić lepszym oknem, bo to samo okno, tylko rzadsze, działałoby poprawnie.
Mylące opisy. Operacja przedstawia się nazwą, która brzmi rutynowo, a robi coś innego. „Optymalizacja konfiguracji” jako etykieta dla akcji, która modyfikuje uprawnienia.
Przeciążenie zgodą. Kilka zatwierdzeń pokazanych naraz albo jedno zbiorcze zamiast serii. Człowiek nie ma jak przejrzeć każdego z osobna, więc nie przegląda żadnego.
Warto zauważyć, że tylko dwa pierwsze są problemem projektowym po twojej stronie. Dwa kolejne mogą być celowe — i to prowadzi do niewygodnej obserwacji: skoro częstotliwość obniża czujność, to hałas przed istotną akcją jest sposobem na obniżenie czujności. Nie rozwijam tego wątku; techniki i kampanie opisuje cyberflux.pl. Tu wystarczy wniosek projektowy: liczba monitów jest parametrem bezpieczeństwa, nie tylko wygody.
Paradoks: więcej nadzoru daje mniej ochrony
Tu dochodzimy do rzeczy, która przeczy branżowej intuicji.
Kiedy zespół dowiaduje się o incydencie z agentem, odruchowa reakcja brzmi: dodajmy więcej punktów kontrolnych. Niech pyta częściej. Niech nic nie robi bez zgody.
Ta reakcja pogarsza sytuację, jeśli przekroczy próg, przy którym człowiek przestaje czytać. Punkty kontrolne mają wtedy dwa efekty naraz: podnoszą liczbę monitów i obniżają wartość każdego z nich. System jest formalnie bezpieczniejszy, mierzalnie bezpieczniejszy w audycie, a realnie mniej chroniony niż wtedy, gdy pytań było pięć dziennie i wszystkie były czytane.
Najkrócej: zgoda jest sygnałem, a sygnał, który pojawia się zawsze, nie niesie informacji. Wartość monitu bierze się z jego rzadkości, nie z jego istnienia. Punkt kontrolny, który wyskakuje przy każdej operacji, informuje dokładnie o tym samym co brak punktu kontrolnego — czyli o niczym.
To odwraca kierunek projektowania. Nie pytaj, gdzie jeszcze dodać zgodę. Pytaj, ile zgód możesz usunąć, żeby te, które zostaną, znów coś znaczyły.
Osad po stronie człowieka
Jest w tym jeszcze jedna symetria, warta odnotowania, bo łączy dwie strony tej samej serii.
Okno kontekstowe agenta ma znaną właściwość: w miarę zapełniania jakość przetwarzania spada, uwaga rozkłada się gorzej, model gubi to, co było w środku. Opisujemy to jako context rot.
Nadzorca ma dokładnie tę samą właściwość. Czterdzieste zatwierdzenie tego dnia jest przetwarzane płycej niż pierwsze — nie dlatego, że człowiek jest gorszy, tylko dlatego, że uwaga też ma budżet i też się wyczerpuje. Osad zbiera się po obu stronach pętli: w agencie, którego kontekst puchnie, i w człowieku, który go pilnuje.
Jeśli projektujesz nadzór, licz się z jednym i drugim. Agent traci trajektorię, gdy okno się zapełnia. Człowiek traci czujność, gdy zapełnia się dzień.
Jak projektować zgodę, która przetrwa powtarzalność
Poniższe nie jest listą sposobów na lepsze okno — okno masz już naprawione z poprzedniego wpisu. To jest lista sposobów na to, żeby okno pojawiało się rzadziej i wtedy, kiedy trzeba.
Progi zamiast pytań przy każdej akcji. Zamiast pytać o każdy zapis, ustal, co agent może robić bez pytania w obrębie katalogu roboczego, i pytaj tylko o to, co wychodzi poza. Zgoda przestaje dotyczyć operacji, a zaczyna dotyczyć przekroczenia granicy.
Budżet zamiast zgody jednostkowej. Dla akcji policzalnych — wywołania płatnego API, wysyłka wiadomości, operacje na rekordach — nadaj limit zamiast pytać za każdym razem. Agent działa do wyczerpania budżetu, a pytanie pojawia się dopiero przy próbie jego przekroczenia. Jedno pytanie zamiast stu.
Eskalacja według ryzyka, nie według typu operacji. Zapis pliku w projekcie i zapis pliku w katalogu domowym to ta sama operacja technicznie i zupełnie inna decyzja. Jeśli twój warunek zgody brzmi „gdy agent zapisuje plik”, pytasz sto razy o nic. Jeśli brzmi „gdy zapis wychodzi poza obszar roboczy albo dotyczy pliku z listy wrażliwych”, pytasz raz i słusznie.
Nieodwracalność jako kryterium. Zgoda jest warta swojej ceny tam, gdzie cofnięcie jest niemożliwe albo kosztowne: wysłanie, usunięcie, płatność, publikacja, zmiana uprawnień. Wszędzie tam, gdzie da się cofnąć jednym poleceniem, rozważ log zamiast bramy. Audyt po fakcie kosztuje mniej uwagi niż zgoda przed faktem, a przy operacjach odwracalnych daje porównywalną ochronę.
Wizualne odróżnienie rzadkiego od rutynowego. Jeśli mimo wszystko masz dwa rodzaje zgód — rutynowe i poważne — nie mogą wyglądać tak samo. Człowiek, który dwadzieścia razy widział identyczne okno, dwudziesty pierwszy raz przetworzy je tym samym odruchem. Poważna zgoda musi łamać wzorzec: innym układem, innym potwierdzeniem, wymaganym działaniem, które nie jest kliknięciem w to samo miejsce co zawsze.
Mierz liczbę zgód jak każdy inny parametr. Jeśli twój agent generuje więcej monitów w tygodniu niż w poprzednim, to jest regresja bezpieczeństwa, nawet jeśli żaden pojedynczy monit nie jest błędny. Warto to zliczać razem z resztą telemetrii — obserwowalność agenta po deploymencie obejmuje także to, ile razy dziennie prosisz człowieka o uwagę.
Checklista: czy twój punkt kontrolny przetrwa powtórzenie
Przejdź przez to raz w miesiącu, nie raz przy wdrożeniu — bo ten problem narasta w czasie, a nie pojawia się na starcie.
- Ile monitów dziennie generuje twój agent na jednego użytkownika? Jeśli nie znasz liczby, to jest pierwsza rzecz do zmierzenia. Bez niej nie wiesz, czy twój nadzór działa, czy tylko istnieje.
- Jaki procent zgód jest odrzucany? Jeśli bliski zeru, masz jedną z dwóch sytuacji: albo pytasz o rzeczy, o które nie trzeba pytać, albo ludzie przestali czytać. Obie wymagają tej samej reakcji — mniej pytań.
- Czy da się odróżnić zgodę rutynową od poważnej, patrząc przez pół sekundy? Bo tyle realnie trwa spojrzenie przy czterdziestej z rzędu.
- Czy pytasz o rzeczy odwracalne? Każde takie pytanie zjada uwagę potrzebną przy nieodwracalnych.
- Czy zgoda dotyczy przekroczenia granicy, czy wykonania operacji? Pierwsze zdarza się rzadko i niesie informację. Drugie zdarza się ciągle i uczy klikać.
- Czy masz limit, po przekroczeniu którego agent przestaje pytać i po prostu się zatrzymuje? Bo alternatywą dla zgody nie zawsze jest działanie. Czasem właściwą odpowiedzią jest przerwanie zadania i oddanie go człowiekowi w całości, a nie proszenie o kolejne kliknięcie.
Czego ten wpis nie rozwiązuje
Uczciwie: zeszklonego zatwierdzania nie da się wyeliminować. Da się je odsunąć — obniżyć częstotliwość, podnieść wartość pojedynczego monitu, zarezerwować uwagę na to, co nieodwracalne. Ale dopóki nadzorcą jest człowiek, a agent działa szybciej, niż człowiek czyta, napięcie zostaje.
I zostaje pytanie, na które ten wpis nie odpowiada, bo należy do innej warstwy: co znaczy zgoda, której nikt nie przeczytał, gdy trzeba ustalić odpowiedzialność za incydent. Formalnie ktoś zatwierdził. Praktycznie nikt nie podjął decyzji. Tę stronę problemu — governance, nie inżynierię — prowadzimy w hubie agentic enterprise, przy pytaniu o odpowiedzialność za błąd agenta.
Na koniec
Poprzedni wpis kończył się zdaniem, że zabezpieczeniem nie jest obecność pytania, tylko to, że człowiek widzi dokładnie to, co za chwilę zrobi maszyna.
Ten dokłada drugą połowę. Człowiek musi nie tylko widzieć — musi mieć powód, żeby spojrzeć. A powód bierze się z rzadkości. Punkt kontrolny, który odzywa się przy wszystkim, przestaje być punktem kontrolnym i staje się tłem, przez które przechodzi wzrok.
Nadzór nie skaluje się z liczbą pytań. Skaluje się z tym, ile uwagi zostaje na to jedno pytanie, które naprawdę było ważne.
Ten wpis należy do serii Anatomia agenta AI i jest kontynuacją artykułu „Human-in-the-loop, który kłamie — jak zaprojektować okno zgody, które naprawdę chroni”. Pojęcia człowiek w pętli i zeszklone zatwierdzanie znajdziesz w Słowniku Agentic Web.
Termin „zeszklone zatwierdzanie” wprowadzamy w tym wpisie jako polską nazwę zjawiska, które w literaturze anglojęzycznej nie ma jeszcze ustalonego określenia — bywa opisywane jako fatigue exploitation w taksonomiach zagrożeń albo, potocznie, jako glazed-over approvals. Zjawiska pokrewne — automation bias i alert fatigue — są opisane w literaturze o czynniku ludzkim i w badaniach nad systemami wspomagania decyzji klinicznych.
Źródła: MCP-38 — taksonomia zagrożeń dla Model Context Protocol (arXiv 2603.18063), pozycja MCP-22 „Insecure Human-in-the-Loop Bypass”
