Poprzedni wpis kończył się wnioskiem, że trzeba pytać rzadziej. To brzmi jak nowy postulat dla agentów.
Nie jest nowym postulatem. Ktoś to już próbował — pięć razy, przez przynajmniej czterdzieści lat, na miliardach ludzi. I za każdą z tych prób ktoś zapłacił rachunek, o którym warto wiedzieć wcześniej.
Ta seria zaczęła się od okna, które kłamie: GhostApproval pokazał, że asystent kodujący potrafi wyświetlić deweloperowi jedną ścieżkę, a zapisać pod inną. Wnioskiem był parytet informacji — człowiek ma widzieć w momencie decyzji dokładnie to, co wie agent.
Drugi wpis był o tym, co zostaje, gdy parytet jest już zachowany. Okno mówi prawdę, człowiek patrzy, i tak klika „akceptuj” po ułamku sekundy, bo klikał już dziś czterdzieści razy. Nazwałem to zeszklonym zatwierdzaniem i skończyłem w niewygodnym miejscu: nie da się tego naprawić lepszym oknem, bo im lepsze okno, tym częściej się odzywa, a im częściej się odzywa, tym mniej znaczy.
Ten wpis domyka serię, wracając do pytania, którego tam nie zadałem: a co, jeśli ktoś już próbował?
Bo próbował. Kopiowanie plików pytało o każdy nadpisywany plik z osobna. sudo dostało pamięć czasową w latach osiemdziesiątych. Vista zapytała o wszystko i przegrała publicznie. Chrome przeprojektował ostrzeżenia certyfikatów i zmierzył wynik. Android przez dekadę przesuwał moment pytania. A systemy ERP — o których w dyskusji o agentach nie mówi nikt — rozwiązały część problemu w sposób, którego branża AI jeszcze nie odkryła.
Wszystko to są eksperymenty na tym samym problemie, przeprowadzone na skali, której nikt z nas nigdy nie osiągnie. Szkoda ich nie przeczytać.
Piąty tryb awarii, którego nie było na mojej liście
Zanim przejdę do strategii — poprawka do poprzedniego wpisu.
Wymieniłem tam cztery mechanizmy, przez które zgoda przestaje być zgodą: obcięty kontekst, zmęczenie częstotliwością, mylące opisy, przeciążenie zgodą. Wszystkie zakładają, że gdyby człowiek spojrzał uważnie, podjąłby dobrą decyzję.
Pamiętacie ScanDisk? Niebieskie okno, mrugające sektory, i po dwudziestu minutach: „Znaleziono utracone klastry. Przekształcić w pliki czy zwolnić?”.
To okno mówiło prawdę. Parytet informacji zachowany. Częstotliwość niska — jedno pytanie na całe skanowanie, więc żadnego zmęczenia. Człowiek patrzył. Czytał. I nadal nie miał żadnej podstawy do decyzji, bo żeby ją podjąć, trzeba rozumieć tablicę alokacji plików. Więc wciskał domyślne i szedł zrobić herbatę.
To jest piąty tryb: awaria kompetencji. Okno mówi prawdę, człowiek patrzy uważnie, i nadal nie wie. Nie dlatego, że jest niedbały ani zmęczony — dlatego, że pytanie wymaga wiedzy, której nie ma i nie powinien mieć.
Nie jest to problem historyczny. „Agent chce wykonać npm install left-pad@1.3.0” — deweloper widzi pełne polecenie, dokładną wersję, wszystko zgodnie z checklistą z pierwszego wpisu. I nie ma jak ocenić, czy ta konkretna wersja nie została przejęta wczoraj wieczorem. Zgoda formalnie udzielona, decyzja faktycznie nie podjęta.
Ten tryb jest ważny, bo nie naprawisz go ani rzadszym oknem, ani lepszym oknem. Naprawisz go tylko przenosząc decyzję do kogoś, kto potrafi ją podjąć — skanera, polityki, listy dozwolonych wersji, albo drugiego człowieka o innych kompetencjach. To pierwsza rzecz, którą historia mówi wprost: część pytań nie powinna trafiać do tego konkretnego człowieka w ogóle, niezależnie od tego, jak dobrze je zadasz.
Strategia 1: zbierz zgody w jedną
Najstarsza i najbardziej intuicyjna. Skoro pytanie o każdy element męczy — zapytaj raz o wszystkie.
Każdy, kto kopiował katalog w Windows 95 albo przetwarzał dokumenty wsadowo, zna oba końce tej historii. Najpierw system pyta o każdy nadpisywany plik osobno. Po dwudziestym pliku człowiek przestaje czytać nazwy. Więc dokładasz „Zastosuj do wszystkich” — i problem znika.
Tylko że nie znika. Zmienia postać.
Zauważ, co się właśnie stało: „zastosuj do wszystkich” to jest dokładnie przeciążenie zgodą — czwarty mechanizm z poprzedniego wpisu. Poprawka na pierwszy mechanizm stała się czwartym. Człowiek, który zatwierdził zbiorczo dwieście plików, nie przejrzał żadnego z nich, a formalnie zgodził się na każdy. To nie jest wada implementacji. To jest cena tej strategii, wbudowana w jej konstrukcję.
I tu pierwsza rzecz, którą ERP rozwiązał lepiej niż interfejsy konsumenckie: potwierdzenie zbiorcze z listą pozycji odstających. Nie „zatwierdzasz 200 dokumentów?”, tylko „zatwierdzasz 200 dokumentów, w tym 3, które przekraczają limit kredytowy kontrahenta — oto one”. Zgoda zbiorcza przestaje wtedy ukrywać ten jeden groźny przypadek, bo ten jeden groźny jest wyciągnięty na wierzch. Uwaga człowieka nie jest rozdzielana po równo na dwieście pozycji — jest kierowana na trzy.
Dla agenta: jeśli batchujesz zgody, batchuj też różnice. Pokaż, które z dwudziestu operacji odstają od reszty — inny katalog docelowy, inny host, inna skala, inny typ zasobu. Zgoda zbiorcza bez wyróżnienia odstępstw to nie jest oszczędność uwagi, tylko jej wyłączenie.
Strategia 2: daj budżet zamiast pytania
Druga strategia jest starsza od agentów o czterdzieści lat i wygląda znajomo każdemu, kto używał terminala.
sudo nie pyta o hasło przy każdym poleceniu. Pyta raz, a potem przez kilkanaście minut nie zawraca głowy. To jest dokładnie budżet zamiast zgody jednostkowej, który proponowałem w poprzednim wpisie — z tą różnicą, że został wdrożony w latach osiemdziesiątych i od tego czasu nikt go poważnie nie podważył. Do tego sudoers z granulacją per polecenie: eskalacja według ryzyka, nie według typu operacji, też gotowa i przetestowana.
Ale najciekawszy materiał dowodowy dla tej strategii dała Vista.
UAC było czystym eksperymentem: zapytajmy o wszystko, co dotyka systemu. Wynik znamy — feature stał się przedmiotem reklam konkurencji. Ale Microsoft zrobił coś, za co należy mu się szacunek: opublikował liczby. Z danych Customer Experience Improvement Program (Ben Fathi, Engineering Windows 7, październik 2008) wynikało, że liczba aplikacji i zadań wywołujących monit spadła w ciągu roku z 775 312 do 168 149, a odsetek sesji z co najmniej jednym monitem — z 50% do 33%.
I jedna liczba, która powinna wisieć nad biurkiem każdego, kto projektuje okno zgody: w badaniu laboratoryjnym tylko 13% uczestników potrafiło podać konkretny powód, dla którego widzą akurat to okno UAC.
Trzynaście procent. Przy oknie, które mówiło prawdę. To jest awaria kompetencji zmierzona na próbie użytkowników, dwadzieścia lat przed agentami.
Windows 7 wycofał się z eksperymentu: suwak intensywności, automatyczna elewacja podpisanych komponentów systemowych, szesnaście punktów promptowania usuniętych, deklarowane 29% mniej monitów. Producent systemu operacyjnego publicznie przyznał, że liczba monitów była błędem projektowym — nie ich treść, nie ich wygląd, liczba.
Android przeszedł tę samą drogę wolniej i mądrzej. Do wersji 6.0 Marshmallow (2015) uprawnienia były listą przy instalacji — nikt jej nie czytał, bo pojawiała się w najgorszym możliwym momencie, gdy człowiek chce już tylko zainstalować aplikację. Marshmallow przeniósł pytanie do chwili, w której uprawnienie jest faktycznie potrzebne. Android 11 (2020) dołożył „Tylko tym razem” oraz automatyczne wygaszanie uprawnień aplikacji nieużywanych od miesięcy. Kierunek jest jednoznaczny: od zgody wieczystej udzielonej hurtem, przez zgodę kontekstową, do zgody z terminem ważności.
Ten ostatni element najczęściej umyka przy agentach. Zgoda może wygasać. Uprawnienie nadane agentowi w poniedziałek nie musi obowiązywać w piątek.
Strategia 3: uczyń rzecz odwracalną
Trzecia strategia jest najbardziej radykalna, bo nie ulepsza pytania — usuwa je.
W lipcu 2007 Aza Raskin opublikował w A List Apart tekst „Never Use a Warning When You Mean Undo”. Teza: jeśli dokładasz ostrzeżenie, bo boisz się, że użytkownik zrobi coś, czego pożałuje, to zwykle nie potrzebujesz ostrzeżenia. Potrzebujesz cofnięcia.
I tu rzecz, która robi wrażenie po dziewiętnastu latach: ten tekst nazywa zeszklone zatwierdzanie wprost. Mówi o habituacji — tendencji do klikania OK, gdy dostajesz serię powtarzalnych zadań — jako o powodzie, dla którego ostrzeżenia nie działają. Zjawisko, które opisywałem jako „nowe tempo, stary mechanizm”, zostało zdiagnozowane i opisane w magazynie o projektowaniu stron, zanim powstał iPhone.
Gmail jest najbardziej znanym wdrożeniem. Nie pyta „czy na pewno wysłać?”. Wysyła i daje kilka sekund na cofnięcie. Zero monitów, zero zmęczenia, a skutek lepszy niż przy pytaniu — bo pytanie przed wysyłką pada, gdy jeszcze nie widzisz błędu, a okienko „cofnij” pojawia się dokładnie w chwili, gdy błąd rzuca ci się w oczy.
Dla agenta: to jest najbardziej niedoceniona strategia w całym agentic web, bo wymaga pracy po stronie architektury, nie interfejsu. Zapis pliku z kopią w katalogu tymczasowym jest odwracalny. Commit bez pusha jest odwracalny. Draft maila jest odwracalny. Żadna z tych operacji nie potrzebuje bramy — potrzebuje logu i przycisku. A uwaga zaoszczędzona na operacjach odwracalnych to dokładnie ta uwaga, której zabraknie przy nieodwracalnych.
Warunek jest jeden i twardy: cofnięcie musi być realne, nie deklarowane. „Cofnij” przy zapisie do ~/.ssh/authorized_keysnie ma sensu, bo klucz atakującego zdążył już posłużyć. Nieodwracalność liczy się od momentu, w którym skutek staje się widoczny na zewnątrz, nie od momentu, w którym da się przywrócić plik.
Strategia 4: nie przekonuj — przechyl
Czwarta strategia jest najmniej znana i ma najlepszy materiał dowodowy.
Chrome przez lata mierzył, ilu ludzi klika przez ostrzeżenie o certyfikacie. Wyniki były fatalne. Zespół Adrienne Porter Felt przeprojektował ostrzeżenie zgodnie z całą literaturą o warning design i zmierzył efekt w polu (CHI 2015).
Wniosek jest zaskakujący i wart zapamiętania: celu nie osiągnęli. Autorzy piszą wprost, że nie udało im się zbudować ostrzeżenia, które użytkownicy rozumieją. Zrozumienie pozostało niskie. A mimo to blisko 30% więcej użytkowników zostało po bezpiecznej stronie.
Zadziałało coś, co nazwali opinionated design — projektowanie, które ma zdanie. Bezpieczne wyjście jest dużym, oczywistym przyciskiem. Ryzykowne istnieje, ale schowane pod „Zaawansowane”. Kolor, ikona i układ pchają w jedną stronę. Nie tłumaczysz człowiekowi zagrożenia — projektujesz tak, żeby jego niepewność prowadziła do bezpiecznego wyniku.
To jest właściwa odpowiedź na awarię kompetencji. Skoro część ludzi nigdy nie zrozumie, o co pytasz, to zamiast tłumaczyć piątą wersją komunikatu, uczyń domyślną ścieżkę bezpieczną, a ryzykowną — wymagającą świadomego wysiłku.
Ten sam mechanizm w innej formie: GitHub przy usuwaniu repozytorium każe wpisać jego nazwę. To jest dokładnie „działanie, które nie jest kliknięciem w to samo miejsce co zawsze”, które postulowałem w poprzednim wpisie — z tą różnicą, że działa od lat i wszyscy znamy je z autopsji. Nie da się tego zrobić odruchowo, bo odruch nie zawiera nazwy repozytorium.
Dla agenta: jeśli masz dwa rodzaje zgód, poważna musi łamać wzorzec fizycznie, nie kolorystycznie. Inne umiejscowienie przycisku. Wymagane wpisanie ścieżki docelowej. Domyślnie zaznaczone „odrzuć”. Przy agentach dochodzi możliwość, której nie ma w interfejsach desktopowych: domyślną odpowiedzią może być zatrzymanie zadania, nie odrzucenie operacji. Agent nie musi pytać „mogę?” — może powiedzieć „przerywam i oddaję to człowiekowi w całości”.
Strategia 5: wyjmij decyzję z momentu
Cztery powyższe strategie mają wspólne założenie, którego żadna nie kwestionuje: że decyzja zapada wtedy, kiedy operacja się dzieje. Różnią się tylko tym, jak ułożyć pytanie, kiedy je zadać i jak je ograniczyć.
Systemy ERP założyły coś innego i dlatego zasługują na osobne miejsce w tej historii. To jest strategia, o której w dyskusji o nadzorze nad agentami praktycznie nie mówi się wcale — a pracuje w tle w każdej firmie produkcyjnej w Polsce.
Odpowiedź ERP na powtarzalne pytania nie brzmi „pytajmy rzadziej”. Brzmi: niech to pytanie w ogóle nie należy do tego człowieka.
Widać to w trzech mechanizmach, które warto rozdzielić.
Uprawnienia i role zamiast pytań. Magazynier nie dostaje okna „czy na pewno wydać towar poniżej ceny zakupu?”. On po prostu nie ma prawa tego zrobić — a jeśli sytuacja tego wymaga, dokument idzie do kogoś, kto ma. Decyzja została podjęta raz, przy konfiguracji, przez osobę z odpowiednimi kompetencjami i w spokoju, a nie sto razy dziennie przez osobę, która akurat klika. To jest dokładnie lekarstwo na awarię kompetencji: pytanie o marżę trafia do kontrolera finansowego, nie do magazyniera, i trafia tam raz.
Blokada typu dokumentu zamiast dialogu. Zamknięty okres rozliczeniowy nie pyta, czy na pewno chcesz księgować wstecz. On odmawia. Nie ma okna, nie ma przycisku „mimo wszystko”, nie ma czego kliknąć odruchowo. Klasa operacji została wyłączona, a nie obwarowana ostrzeżeniem — i właśnie dlatego nikt się do tego nie przyzwyczaja.
Limity zamiast potwierdzeń. Limit kredytowy kontrahenta nie generuje monitu przy każdym zamówieniu. Generuje go dopiero przy przekroczeniu — i wtedy monit coś znaczy, bo pojawia się rzadko i zawsze z tego samego powodu.
Wspólny mianownik: decyzja zostaje przeniesiona z momentu wykonania do momentu konfiguracji, i z osoby wykonującej na osobę odpowiedzialną. Człowiek przy klawiaturze nie jest wtedy bramą, którą trzeba przekonać — jest wykonawcą działającym w ramach, które ktoś inny ustalił świadomie.
Dla agenta to przekłada się bezpośrednio i jest to chyba najbardziej niedoceniony wniosek z całej tej serii. Agent nie potrzebuje pytać, czy może zapisać poza katalogiem roboczym, jeśli po prostu nie ma do tego uprawnień systemowych. Nie potrzebuje pytać o wywołanie płatnego API po raz setny, jeśli ma limit, po którym przestaje działać. Nie potrzebuje pytać o operację na produkcji, jeśli produkcja jest dla niego zamknięta jak zamknięty okres rozliczeniowy.
I najważniejsze: osoba, która konfiguruje agenta, i osoba, która z nim pracuje, to nie musi być ta sama osoba. W ERP to jest oczywistość od trzydziestu lat. W agentic web wciąż domyślnie zakładamy, że deweloper sam sobie ustawia granice i sam siebie pyta o zgodę — czyli że nadzorującym i nadzorowanym jest jeden człowiek w jednej sesji. To jest architektura, której żaden system finansowy by nie zaakceptował.
Cena, o której nie napisałem w poprzednim wpisie
Tu jest miejsce na uczciwe sprostowanie, bo poprzedni wpis miał lukę i to najgroźniejszą z możliwych.
Napisałem: nie pytaj, gdzie dodać zgodę, pytaj, ile zgód możesz usunąć. Podtrzymuję. Ale nie napisałem, czym za to płacisz — a płacisz konkretnie i mierzalnie.
Próg zamiast pytania przy każdym zapisie oznacza, że agent ma teraz swobodę w całym katalogu roboczym. Budżet zamiast zgody jednostkowej oznacza sto wywołań bez ani jednego spojrzenia. Auto-elewacja podpisanych komponentów — rozwiązanie Microsoftu z Windows 7 — oznacza, że atak na podpisany komponent omija UAC całkowicie. Każda z tych poprawek zdejmuje monit i w zamian oddaje obszar.
Przy agencie to nie jest ryzyko teoretyczne. Agent czyta treści, które mogą zawierać instrukcje — README, dokumentację, wynik wyszukiwania, opis narzędzia MCP. To jest agent hijacking, wektor opisany w słowniku i wykorzystywany w praktyce. W chwili, gdy agent zostanie przejęty, jedyne, co go ogranicza, to granice, które mu zostawiłeś. Jeśli właśnie usunąłeś monit przy zapisie w katalogu roboczym, to przejęty agent ma teraz cały katalog roboczy — bez jednego pytania.
Powiedzmy to więc wprost, bo poprzedni wpis tego nie powiedział: oddajesz szerokość pokrycia za głębokość uwagi.To jest dobra wymiana, bo bariera, przez którą człowiek przechodzi wzrokiem, nie jest barierą. Ale ktoś przeczyta „mniej monitów”, wdroży samo „mniej monitów” i się na tym przejedzie.
Reguła, która domyka tamten wpis: każdy obszar, z którego usuwasz pytanie, musi w zamian dostać inne zabezpieczenie. Ograniczenie uprawnień systemowych, sandbox, log z alertem, limit, po którym agent się zatrzymuje — cokolwiek, co działa bez udziału ludzkiej uwagi. To zresztą dokładnie strategia piąta: monit usunięty z momentu wykonania powinien odrodzić się jako granica ustawiona w konfiguracji. Usunięcie monitu bez rekompensaty nie jest uproszczeniem nadzoru. Jest jego skróceniem.
Czego nikt nie rozwiązał
Uczciwie na koniec, bo ten wpis nie ma happy endu.
Medycyna ma najdłuższą i najlepiej udokumentowaną historię walki z tym problemem — i najbardziej przygnębiające wyniki. Odsetki odrzucania alertów o interakcjach lekowych podawane w literaturze mieszczą się mniej więcej między połową a niemal wszystkimi; w badaniu alertów opioidowych z dwóch szpitali w Bostonie sięgnął w 2013 roku prawie 90%. A praca z 2014 roku o wymownym tytule „no evidence of progress” stwierdziła, że mimo dekady intensywnych wysiłków nad ulepszaniem systemu i ograniczaniem liczby alertów wskaźniki odrzuceń pozostały takie same jak dziesięć lat wcześniej.
Warto przy tej okazji rozdzielić dwie rzeczy, bo w poprzednim wpisie postawiłem je za blisko siebie.
Zmęczenie alertami i zeszklone zatwierdzanie nie są synonimami, choć mechanizm mają wspólny. Zmęczenie alertami dotyczy ostrzeżeń — sygnału informacyjnego, który wolno zignorować i który nie zmienia niczyjego statusu. Zeszklone zatwierdzanie dotyczy bramek decyzyjnych: człowiek autoryzuje, więc powstaje formalna odpowiedzialność za decyzję, której faktycznie nikt nie podjął. Lekarz, który odrzucił alert, zignorował podpowiedź. Deweloper, który kliknął „akceptuj”, udzielił zgody — i to jego podpis widnieje w logu, gdy trzeba ustalić, kto dopuścił operację. To jest realna różnica i to ona uzasadnia osobną nazwę.
Podobne rozróżnienie należy się symetrii, którą opisywałem między agentem a nadzorcą. Pisałem, że okno kontekstowe agenta i uwaga człowieka mają „dokładnie tę samą właściwość”. To za mocno. Context rot to rozmycie uwagi w miarę zapełniania okna, zeszklone zatwierdzanie to aktualizacja przekonań na podstawie serii nieszkodliwych obserwacji. Ten sam kształt, inny mechanizm. Wniosek praktyczny zostaje bez zmian — uwaga po obu stronach pętli ma budżet i oba trzeba liczyć — ale nie należy z tego robić tożsamości.
Wracając do bilansu: czterdzieści lat prób, pięć strategii, miliardy użytkowników — i problem nadal jest. Jeśli szukałeś w tym wpisie rozwiązania, to go nie ma.
Jest za to coś innego i moim zdaniem cenniejszego: branża zbiegła się do zgody co do tego, kiedy w ogóle pytać. Nie w formie standardu, nie w formie specyfikacji, tylko w formie czterdziestu lat niezależnych eksperymentów, które wszystkie skończyły się w tym samym miejscu. To jest wiedza starsza od agentów i naprawdę nie trzeba jej wymyślać od zera.
Checklista: którą strategię wybrać dla której akcji
Przejdź przez każdą akcję agenta, przy której prosisz człowieka o zgodę, i zadaj pytania w tej kolejności.
- Czy ten człowiek jest w stanie ocenić to pytanie? Jeśli nie — to awaria kompetencji i żadne okno jej nie naprawi. Przenieś decyzję do skanera, polityki, listy dozwolonych albo osoby o innych kompetencjach. Nie pytaj o rzeczy, na które człowiek może tylko zgadywać.
- Czy tę decyzję da się podjąć raz, przy konfiguracji? Uprawnienie, limit, zamknięty obszar. Jeśli tak — to jest najtańszy nadzór, jaki istnieje, bo nie zużywa uwagi w ogóle. Pytaj tylko o przekroczenie granicy, nie o wykonanie operacji.
- Czy da się to cofnąć, zanim skutek wyjdzie na zewnątrz? Jeśli tak — usuń pytanie, dodaj log i cofnięcie.
- Czy to operacja policzalna i powtarzalna? Jeśli tak — daj budżet zamiast zgody jednostkowej. I zapisz sobie, jaki obszar właśnie oddałeś bez nadzoru, bo ten obszar potrzebuje teraz innego zabezpieczenia.
- Czy to nieodwracalne i poważne? Dopiero tu zostaje zgoda. I dopiero tu ma sens łamanie wzorca: inny układ, domyślne „odrzuć”, wymagane wpisanie celu, bezpieczne wyjście jako duży przycisk.
- Ile z zadanych pytań kończy się odrzuceniem? Mierz to razem z resztą telemetrii. Odsetek bliski zeru ma trzy możliwe odczyty i warto ustalić który: pytasz o rzeczy, o które nie trzeba pytać; ludzie przestali czytać; albo agent jest dobrze skonfigurowany i naprawdę nie próbuje rzeczy, które trzeba odrzucać. Trzeci przypadek jest sukcesem, nie problemem — ale nie zakładaj go bez sprawdzenia, bo z zewnątrz wygląda identycznie jak dwa pierwsze.
Na koniec
Trzy wpisy, trzy zdania, które razem układają się w całość.
Pierwszy: człowiek musi widzieć to, co za chwilę zrobi maszyna. Drugi: człowiek musi mieć powód, żeby spojrzeć — a powód bierze się z rzadkości. Ten dokłada trzecie: człowiek musi być w stanie ocenić to, na co patrzy — a jeśli nie jest, to pytanie trafiło pod zły adres i trzeba je przenieść, a nie przeredagować.
Nadzór nie jest funkcją liczby pytań. Jest funkcją tego, ile z nich trafia do kogoś, kto potrafi na nie odpowiedzieć — i ile uwagi zostaje mu na to jedno, które naprawdę było ważne.
Ten wpis zamyka trzyczęściową serię o oknie zgody w Anatomii agenta AI: „Human-in-the-loop, który kłamie” o oknie, które pokazuje nieprawdę, „Zeszklone zatwierdzanie” o oknie, które mówi prawdę i tak nie chroni, oraz ten — o tym, czego próbowano wcześniej i czym za to zapłacono. Pojęcia człowiek w pętli, agent hijacking, parytet informacji i zeszklone zatwierdzanie znajdziesz w Słowniku Agentic Web. Stronę organizacyjną — co znaczy zgoda, której nikt nie przeczytał, gdy trzeba ustalić odpowiedzialność — prowadzimy w hubie agentic enterprise.
Dwa sprostowania do poprzedniego wpisu, zebrane w jednym miejscu. Po pierwsze: rada „usuwaj monity” była niepełna bez wskazania ceny — każdy obszar zwolniony z pytania musi dostać w zamian zabezpieczenie działające bez udziału ludzkiej uwagi. Po drugie: symetria między context rot a zmęczeniem nadzorcy to ten sam kształt, ale inny mechanizm, nie „dokładnie ta sama właściwość”.
Źródła: Aza Raskin, „Never Use a Warning When You Mean Undo”, A List Apart, 13 lipca 2007 · Ben Fathi, „User Account Control”, Engineering Windows 7 blog, październik 2008 (dane Customer Experience Improvement Program) · A. P. Felt i in., „Improving SSL Warnings: Comprehension and Adherence”, CHI 2015 · dokumentacja Android Developers: uprawnienia runtime (API 23) i zmiany uprawnień w Androidzie 11 (API 30) · M. Topaz i in., „High Override Rate for Opioid Drug-allergy Interaction Alerts”, 2015 · „Drug interaction alert override rates in the Meaningful Use era: no evidence of progress”, 2014 · Y. T. Shen, K. Toyoda, A. Leung, „MCP-38: A Comprehensive Threat Taxonomy for Model Context Protocol Systems”, arXiv:2603.18063, marzec 2026 — jedna z kilku konkurencyjnych taksonomii zagrożeń dla MCP z tego samego kwartału (por. arXiv:2602.11327, arXiv:2604.05969).
