Dwie linie, jeden wniosek. Przez całą tę serię oglądaliśmy okno zgody z obu stron — a odpowiedź okazuje się nie mieszkać w oknie w ogóle.
Mieszka w schemacie organizacyjnym. Księgowość zapisała ją, zanim powstało oprogramowanie.
Ta seria szła w dwóch językach i, uczciwie mówiąc, w dwóch różnych kierunkach.
Jedna linia była o nazywaniu. Polszczyzna nie miała określenia na to, co dzieje się, gdy człowiek klika zatwierdź, nie czytając — zjawisko jest opisane w trzech osobnych dziedzinach pod trzema osobnymi nazwami, z których żadna nie jest polska. Więc je nazwaliśmy: zeszklone zatwierdzanie, od zeszklonego wzroku, który przechodzi przez ekran, nie zatrzymując się na treści.
Druga linia była o tym, co zostaje. Kiedy coś pójdzie nie tak i ktoś odtwarza przebieg incydentu, zostaje linia w logu: 14:32:07 — action approved by user@company. Tę linię wytwarza identycznie przemyślana decyzja i odruch. Zapisuje kliknięcie, a opisuje je językiem zarezerwowanym dla osądu.
Różne punkty wyjścia i nie spodziewałem się, że zbiegną. Zbiegły — i obie skończyły na tym samym niedokończonym zdaniu. Napisałem je na końcu poprzedniego eseju:
To, czy ta wymiana jest właściwa, zależy od tego, co agent może dosięgnąć — a to jest pytanie o uprawnienia, nie o okna dialogowe.
Zostawiłem je tam, bo nie miałem jeszcze odpowiedzi. Mam ją teraz i jest starsza niż każdy system opisany w tej serii.
Dlaczego okno nigdy nie może być odpowiedzią
Warto sprężyć argument, bo budował się przez trzy eseje.
Okno zgody zawodzi na pięć sposobów. Może pokazać nie to, co trzeba — etykietę zamiast rozwiązanego celu. Może być obcięte. Może opisać groźną operację rutynowym językiem. Może zebrać tyle akcji naraz, że żadna nie zostanie przeczytana. I może odzywać się tak często, że człowiek poprawnie wnioskuje, że nie niesie informacji.
Naprawa trzech pierwszych to praca inżynierska i ona działa. Naprawa czwartej i piątej to gra przegrana z definicji, bo im lepsze okno, tym więcej przypadków brzegowych wychwytuje, tym częściej się odzywa, tym mniej znaczy każde pojedyncze odezwanie.
Ale jest szósty tryb awarii i to on domyka argument. Czasem okno mówi prawdę, odzywa się rzadko, zostaje przeczytane uważnie — a człowiek i tak nie umie odpowiedzieć, bo odpowiedź wymaga wiedzy, której nie ma i nie powinien mieć. Przekształcić utracone klastry w pliki czy zwolnić? Trzeba było rozumieć tablicę alokacji plików. Agent chce wykonać npm install left-pad@1.3.0 — trzeba wiedzieć, czy ta konkretna wersja nie została przejęta wczoraj wieczorem.
Nazwijmy to awarią kompetencji. Nie da się jej naprawić pytając lepiej, rzadziej ani wyraźniej. Da się ją naprawić tylko pytając kogoś innego — albo nie pytając człowieka w ogóle.
Kiedy się to przyjmie, cała rama się przesuwa. Pytanie przestaje brzmieć jak napisać dobre okno zgody, a zaczyna kto powinien o tym decydować i kiedy. A to pytanie ma odpowiedź z mniej więcej stuletnią praktyką za sobą.
Księgowość rozwiązała to przed komputerami
Zasada nazywa się rozdzieleniem obowiązków i jest fundamentem kontroli wewnętrznej. Model COSO — punkt odniesienia dla kontroli wewnętrznej nad sprawozdawczością finansową — dzieli każdą transakcję na trzy funkcje, które nie mogą leżeć w rękach jednej osoby: autoryzację (decyzję, że coś ma się wydarzyć), wykonanie lub pieczę(przeprowadzenie tego) oraz zapis i uzgodnienie (zalogowanie i późniejszą weryfikację).
Logika jest prosta i bezlitosna. Jeśli jedna osoba może wykonać operację i jednocześnie ją zaksięgować, może ukryć błąd albo nadużycie bez niczyjej pomocy. Rozdziel te funkcje, a ukrycie wymaga zmowy — trudniejszej, wolniejszej i łatwiejszej do wykrycia.
Szczegół wart odnotowania, bo mówi coś o głębokości tej zasady: ustawa Sarbanes-Oxley nigdy nie używa tego sformułowania. A mimo to audytorzy traktują słabe rozdzielenie obowiązków jako standardową przyczynę istotnej słabości kontroli w rozumieniu sekcji 404, a nierozwiązane konflikty należą do najczęstszych ustaleń audytu. Ta zasada nie jest regulacją. Jest tym, co regulacja zakłada, że już robisz.
I zwróć uwagę, czym nie jest. Nie jest technologią, oknem dialogowym, modelem uprawnień ani oprogramowaniem. Jest kształtem nałożonym na organizację, który bywa egzekwowany przez oprogramowanie. To rozróżnienie jest sednem tego eseju.
Co naprawia, czego okno naprawić nie może
Wróćmy do linii w logu.
Niewygodna obserwacja z poprzedniego eseju brzmiała: bramka, której nikt nie czyta, nie zmniejsza ryzyka — czyni skutek przypisywalnym. Ryzyko przesuwa się z organizacji, która wdrożyła agenta, na człowieka, który kliknął. A ten człowiek kliknął, bo system go tego nauczył. Budujemy mechanizmy wytwarzające odpowiedzialność z zachowania, które sami wywołaliśmy, a potem wskazujemy na zapis.
Rozdzielenie obowiązków adresuje dokładnie to i robi to, zmieniając w zgodzie trzy rzeczy naraz.
Kto decyduje. Zatwierdzający nie jest wykonawcą. Ma inne kompetencje, inne interesy i inną ekspozycję. Osoba wprowadzająca faktury nie dostaje okna z pytaniem, czy ta jedna przekracza limit kredytowy kontrahenta — po prostu nie może jej przepchnąć, a dokument trafia do kogoś, kto ma to w zakresie obowiązków.
Kiedy decyduje. Decyzja zapada raz, przy konfiguracji, na spokojnie, przez kogoś, kto myśli o całej klasie transakcji. Nie zapada czterdzieści razy dziennie u kogoś, kto ma kolejkę do wyczyszczenia. Zmęczenie nigdy nie wchodzi w grę, bo nie ma nic powtarzalnego, do czego można by przywyknąć.
Co znaczy zapis. Kiedy autoryzacja leży przy roli nadanej świadomie i osobno od wykonania, linia w logu przestaje być podpisem zebranym z odruchu. Staje się odwołaniem do decyzji, która naprawdę zapadła — tyle że wcześniej i gdzie indziej.
To jest różnica między systemem produkującym obronną dokumentację a systemem produkującym kontrolę.
Trzy mechanizmy warte podkradzenia
Systemy klasy ERP wdrażają to w sposób niemal zawstydzająco łatwy do przełożenia na agentów — i niemal całkowicie nieobecny w dyskusji o nich.
Rola zamiast pytania. Magazynier nie widzi ostrzeżenia o wydaniu towaru poniżej ceny zakupu. On nie ma do tego prawa. Jeśli sytuacja tego naprawdę wymaga, dokument idzie wyżej, do kogoś, kto prawo ma. Nie ma okna, przez które można by przeklikać, bo ograniczenie nie jest zrobione z pikseli.
Blokada zamiast dialogu. Zamknięty okres rozliczeniowy nie pyta, czy na pewno chcesz księgować wstecz. On odmawia. Nie ma „mimo wszystko", nie ma linku „zaawansowane", nie ma czego kliknąć odruchowo. Cała klasa operacji jest wyłączona, a nie obwarowana ostrzeżeniem — i właśnie dlatego nikt się do niej nie przyzwyczaja.
Limit zamiast potwierdzenia. Limit kredytowy nie odzywa się przy każdym zamówieniu. Odzywa się przy tym, które go przekracza. Monit jest rzadki, zawsze znaczy to samo i dlatego po tysięcznym zamówieniu nadal niesie informację.
Wspólny mianownik: decyzja została przeniesiona z momentu wykonania do konfiguracji, i z wykonawcy na osobę odpowiedzialną.
Przełożenie na agentów
Mapowanie jest bezpośrednie i w większości składa się z rzeczy, których dzisiejsze narzędzia nie robią.
Agent powinien być kontem, nie funkcją Twojej sesji. Potrzebuje własnej tożsamości, własnej roli i własnego zestawu uprawnień — nie Twoich uprawnień pożyczonych na czas zadania. Wszystko poniżej zależy od tego jednego punktu.
Konfigurujący i pracujący to powinny być różne osoby. To jest największa luka. Dziś zakładamy, że deweloper sam ustawia granice swojemu agentowi, a potem sam zatwierdza jego działania — nadzorujący i nadzorowany zwinięci w jednego człowieka w jednej sesji. Żaden system finansowy nie zaakceptowałby takiej architektury ani na chwilę. W zespole osoba definiująca, co agent może dosięgnąć, nie powinna być osobą przepychającą go przez zadanie o szesnastej.
Wolej odebrać prawo, niż dodać pytanie. Jeśli agent nigdy nie powinien pisać poza katalogiem roboczym, nie pytaj — odmów na poziomie systemu plików. Pytanie da się przeklikać. Brakującego uprawnienia nie da się.
Zamykaj okresy, nie tylko ścieżki. Produkcja, systemy płatnicze, baza adresowa klientów: traktuj je jak zamknięty okres rozliczeniowy. Nie obwarowane bramką — zamknięte, z ponownym otwarciem jako świadomym, zalogowanym i osobno autoryzowanym aktem.
Nie pozwól, żeby agent trzymał funkcję zapisu. Ten punkt jest subtelny i uważam go za najostrzejsze przeniesienie całej zasady. Jeśli agent wykonuje akcję i pisze log opisujący, co zrobił, oddałeś jednej stronie jednocześnie pieczę i zapis — czyli dokładnie tę kombinację, której kontrola wewnętrzna ma zapobiegać. Przejęty albo zdezorientowany agent opowiada własną historię. Ślad audytowy musi powstawać w miejscu, którego agent nie dosięga.
Czego to nie rozwiązuje
Trzy ograniczenia, postawione wprost.
Zakłada, że jest kogo rozdzielić. Solo deweloper nie ma drugiej osoby, a dwuosobowy startup ma jedną, która akurat śpi. COSO jest w tej sprawie uczciwe: tam, gdzie rozdzielenie jest niepraktyczne, stosuje się kontrole kompensujące — niezależny przegląd po fakcie, podwójną autoryzację powyżej progu ryzyka, log odporny na manipulację przeglądany przez kogoś spoza procesu, dostęp wyjątkowy z terminem ważności. Dla osoby pracującej samodzielnie realistyczna wersja polega na tym, że drugą rolę gra maszyna: skaner, polityka, twardy limit, log czytany według harmonogramu, a nie w biegu. Słabsze niż kolega z zespołu. Dużo mocniejsze niż okno dialogowe.
Zakłada, że tożsamość agenta jest realna. Role są warte tyle, ile odpowiedź na pytanie kto działa. Jeśli agent może działać na poświadczeniach człowieka, rozdzielenie obowiązków jest dekoracją. To jest problem tożsamości, zanim stanie się problemem autoryzacji — i nie jest rozwiązany.
Nie mówi, gdzie leży próg. Pisałem poprzednio, że nie wiem, ile monitów dziennie człowiek jest w stanie wchłonąć, zanim uwaga się załamie, i nadal nie wiem. Rozdzielenie obowiązków zmniejsza liczbę monitów, które w ogóle istnieją, co jest właściwym kierunkiem, ale nie produkuje liczby. Wolę zostawić to otwarte, niż ją wymyślić.
Ostatnie zdanie
Poprzedni esej kończył się testem: jeśli chcesz wiedzieć, czy Twój nadzór jest realny, nie licz bramek — policz, jak często ktoś mówi „nie".
Dopisałbym teraz jedno zdanie podrzędne. To, do którego cała ta seria zmierzała.
Policz, jak często ktoś mówi „nie" — i sprawdź, czy tym kimś nie jest ta sama osoba, która się spieszyła.
Jeśli tak, to nie masz nadzoru. Masz podpis, zebrany w warunkach, które sam zaprojektowałeś, od kogoś, kogo sam nauczyłeś go składać.
Ten tekst zamyka serię prowadzoną na trzech serwisach. Strona projektancka — jak zbudować zgodę, która przetrwa powtarzalność, oraz cztery dekady prób, które były przed nami — jest na webflux.pl. Nazwanie zjawiska i powód, dla którego polszczyzna potrzebowała na nie terminu, jest tutaj. Poprzedni esej z linii angielskiej to We didn't invent this problem with agents.
Źródła: COSO Internal Control — Integrated Framework (rozdzielenie obowiązków jako działanie kontrolne; kontrole kompensujące tam, gdzie rozdzielenie jest niepraktyczne) · Sarbanes-Oxley Act, sekcja 404, oraz praktyka audytowa traktująca niedostateczne rozdzielenie obowiązków jako przyczynę istotnej słabości kontroli · A. P. Felt i in., „Improving SSL Warnings: Comprehension and Adherence", CHI 2015 · Aza Raskin, „Never Use a Warning When You Mean Undo", A List Apart, 2007 · 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 kwartału.