Monity o zatwierdzenie działań agentów AI nie są autoryzacją

OpenAI Agents SDK traktuje teraz zatwierdzenie przez człowieka jako stan środowiska wykonawczego: wywołanie wrażliwego narzędzia może wstrzymać wykonanie, pokazać przerwanie, zapisać decyzję w RunState i wznowić ten sam przebieg po zatwierdzeniu albo odrzuceniu.¹

Ta forma produktu trafia w jedną ważną rzecz. Zatwierdzenie powinno należeć do środowiska wykonawczego, a nie tylko do zapisu rozmowy.

Trudniejsze pytanie pojawia się zaraz potem: co człowiek faktycznie autoryzował?

Monit o zatwierdzenie w rodzaju „Zezwolić na polecenie powłoki?” albo „Zatwierdzić wywołanie narzędzia?” prosi użytkownika o zaufanie do chwili. Prawdziwy zapis autoryzacji ogranicza zakres działania, nazywa ryzyko, zapisuje dowody, wygasa i tworzy ścieżkę możliwą do późniejszego przeglądu. Agenci AI potrzebują tej drugiej formy, bo planują przez wiele kroków, wywołują zagnieżdżone narzędzia, ponawiają próby po odrzuceniu i wnoszą płynne uzasadnienia do decyzji, przy których człowiek może czuć presję, by kliknąć „tak”.

W skrócie

Monity o zatwierdzenie działań agentów AI nie są autoryzacją. Monit może wstrzymać pracę, ale autoryzacja musi określać, kto nadaje uprawnienie, który agent je otrzymuje, które narzędzie może zostać uruchomione, jakiego zasobu może dotknąć, który poziom ryzyka ma zastosowanie, jak długo obowiązuje zgoda, jakie dowody wspierały decyzję i jak operator może ją odwołać. Zespoły powinny projektować zatwierdzenia jako obiekty uprawnień o ograniczonym zakresie, a nie jako przerwania w czacie. Właściwe pytanie nie brzmi: „czy ktoś kliknął zatwierdź?”. Właściwe pytanie brzmi: „jakie konkretne działanie odpowiedzialna osoba autoryzowała i pod jakimi ograniczeniami?”.

Najważniejsze wnioski

Dla zespołów produktowych: - Zatwierdzenie należy pokazywać jako typowany obiekt decyzji: działanie, zasób, ryzyko, dowody, wygaśnięcie i ścieżkę wycofania. - Potwierdzenia niskiego ryzyka trzeba oddzielić od autoryzacji wysokiego ryzyka.

Dla zespołów bezpieczeństwa: - Powtarzające się monity o zatwierdzenie należy traktować jako powierzchnię ataku, nie tylko jako problem UX. - Trzeba rejestrować każde zezwolenie, odmowę, automatyczne zezwolenie, automatyczną odmowę, wygaśnięcie i odwołanie.

Dla twórców agentów: - Wstrzymanie powinno następować przed działaniem nieodwracalnym, nie po tym, jak agent już ukształtował wynik. - Odrzucenie należy przekazywać modelowi jako ograniczoną instrukcję, a nie jako niejasną porażkę.

Dla operatorów: - Nie należy zatwierdzać wywołania narzędzia, jeśli nie widać zasobu docelowego, zakresu uprawnień i ścieżki wycofania. - Lepiej stosować krótkotrwałe zgody o ograniczonym zakresie niż utrwalać nawyk „zawsze zatwierdzaj”.

Dlaczego monity o zatwierdzenie zawodzą?

Monity o zatwierdzenie zawodzą wtedy, gdy decyzję wymagającą bogatego kontekstu sprowadzają do kliknięcia bez kontekstu.

Agent ma więcej kontekstu, niż pokazuje monit. Mógł przeczytać pliki, streścić wątek, zaplanować sekwencję, wybrać narzędzie, uzupełnić argumenty i dobrać moment wykonania. Monit o zatwierdzenie często pokazuje tylko ostatni krok. Użytkownik widzi polecenie, wywołanie API, akcję w przeglądarce albo zdanie napisane przez tego samego agenta, który prosi o zgodę.

Taki interfejs tworzy cztery rodzaje problemów:

OWASP Agentic Top 10 nazywa problem perswazji wprost. Wpis ogłaszający wydanie mówi, że pewnie brzmiące wyjaśnienia mogą wprowadzać operatorów w błąd i skłaniać ich do zatwierdzania szkodliwych działań w ramach ASI09, Human-Agent Trust Exploitation.² Ryzyko nie wymaga złośliwego modelu. Pomocny agent nadal może przesadnie sprzedać słaby plan, pomniejszyć niepewność albo ukryć ryzykowne wywołanie narzędzia w sekwencji nieszkodliwych działań.

Zatwierdzenie potrzebuje więc lepszej formy. Człowiek powinien zatwierdzać zapis działania, a nie dymek z prośbą.

Co powinno autoryzować zatwierdzenie?

Poważne zatwierdzenie powinno autoryzować jedno konkretne działanie w ograniczonych warunkach.

Artykuł „Authenticated Delegation and Authorized AI Agents” ujmuje szerszy problem jako delegowanie uprawnień: użytkownicy potrzebują sposobu ograniczania uprawnień agentów i utrzymywania jasnych łańcuchów odpowiedzialności z użyciem poświadczeń specyficznych dla agenta, metadanych oraz audytowalnych konfiguracji kontroli dostępu.³

To ujęcie dobrze przekłada się na projekt produktu. Zatwierdzenie powinno zawierać:

Bez tych pól zatwierdzenie staje się przeczuciem z przyciskiem. Model może poprosić uprzejmie. Człowiek może kliknąć szybko. Żadne z tych zdarzeń nie dowodzi, że działanie było właściwe.

Jak powinien działać stan zatwierdzenia?

Stan zatwierdzenia powinien przetrwać pauzę, ale pozostać wąski.

Dokumentacja OpenAI Agents SDK opisuje użyteczny wzorzec środowiska wykonawczego. Narzędzia mogą deklarować needs_approval; runner ocenia regułę zatwierdzenia przed wykonaniem; nierozstrzygnięte zatwierdzenia pojawiają się jako przerwania; deweloper może zatwierdzić albo odrzucić każdy oczekujący element; a przebieg wznawia się z RunState.¹ Dokumentacja opisuje też decyzje trwałe, takie jak always_approve i always_reject, dla późniejszych wywołań w tym samym przebiegu.¹

Maszyna stanów ma znaczenie, bo wstrzymany przebieg agenta nie powinien startować ponownie z pamięci, odtwarzać intencji ani tracić kontekstu zatwierdzenia. Powinien wznowić działanie od przerwanego miejsca z dołączoną decyzją.

Opcja trwałej decyzji tworzy następny wymóg projektowy: każde trwałe zatwierdzenie potrzebuje zakresu i wygaśnięcia.

Trwałe zatwierdzenie może zmniejszyć zmęczenie. Zbyt szerokie trwałe zatwierdzenie może zamienić jedno zmęczone kliknięcie w pełny zasięg skutków danego przebiegu.

Gdzie zatwierdzenie powinno znajdować się w środowisku wykonawczym?

Zatwierdzenie powinno znajdować się przed punktem nieodwracalnego skutku.

Punkt nieodwracalnego skutku to chwila, w której agent przechodzi od pracy odwracalnej do efektu ubocznego: modyfikacji zasobu produkcyjnego, wysłania wiadomości, wydania pieniędzy, opublikowania treści, usunięcia danych, rotacji klucza, zmiany uprawnień albo wdrożenia kodu. Zatwierdzenie przez człowieka po tym punkcie jest reakcją na incydent, a nie autoryzacją.

Literatura o nadzorze człowieka wspiera to rozróżnienie. Artykuł z 2026 roku w AI and Ethics oddziela sprawczość operacyjną, w której AI generuje lub działa, od sprawczości oceniającej, w której człowiek może ocenić, zakwestionować i nadpisać decyzję.⁴ Skuteczny nadzór nie może zależeć od osoby obserwującej każdy token. Interfejs musi rezerwować osąd człowieka dla miejsc, w których osąd nadal może zmienić wynik.

Daje to produktom agentowym prostą zasadę:

Monit, który pojawia się po tym, jak agent wykonał już ryzykowną część, tworzy tylko pozór kontroli. Człowiek nie może skorzystać ze sprawczości oceniającej, jeśli system już zużył uprawnienie.

Jak zapobiegać zmęczeniu zatwierdzeniami?

Zmęczenie zatwierdzeniami jest błędem bezpieczeństwa, bo zmęczenie zmienia decyzję.

Jeśli przebieg prosi o 40 zatwierdzeń, produkt prawdopodobnie zawiódł, zanim użytkownik kliknął. Operator przestaje oceniać każdy element i zaczyna zarządzać irytacją. Atakujący mogą wykorzystać ten wzorzec, generując powtarzające się żądania, ukrywając ryzykowne działania w partiach albo używając języka, który sprawia, że niebezpieczne wywołanie wygląda rutynowo.

OWASP Agentic Top 10 traktuje wykorzystywanie zaufania człowiek-agent jako kategorię ryzyka pierwszej klasy.² Badania nad bezpieczeństwem agentów dochodzą do podobnego ujęcia od strony systemowej. Systematyzacja bezpieczeństwa agentic AI z marca 2026 roku mapuje granice zaufania w obszarach wstrzykiwania instrukcji, zatruwania baz wiedzy, exploitów narzędzi i pluginów oraz zagrożeń wieloagentowych; wskazuje też potrzebę monitorowania środowiska wykonawczego i kontroli reagowania na incydenty.⁵ Artykuł z maja 2026 roku o agentach audytowalnych pod kątem bezpieczeństwa argumentuje, że statyczne zestawienia materiałów i logi wykonawcze dają rozproszone dowody, jeśli system nie potrafi połączyć możliwości, pamięci, celów, trajektorii rozumowania i działań w możliwe do odpytywania ścieżki audytu.⁶

Projekt zatwierdzeń powinien zmniejszać zmęczenie przez usuwanie monitów o niskiej wartości i podnoszenie jakości monitów o wysokiej wartości:

Celem nie jest mniej kontroli. Celem jest mniej kontroli pozbawionych znaczenia.

Co powinien pokazywać UI zatwierdzenia?

UI zatwierdzenia powinien pokazywać decyzję, a nie osobowość agenta.

Najpierw kompaktowa karta decyzji:

Taka karta pomaga użytkownikowi odpowiedzieć na jedno pytanie: czy żądane działanie pasuje do dowodów i zakresu?

Karta nie powinna ukrywać dokładnych argumentów. Nie powinna chować odmowy. Nie powinna sprawiać, że „zatwierdź” jest jedyną zaprojektowaną ścieżką, a „odrzuć” zachowuje się jak wyjątek. Dobra powierzchnia zatwierdzenia traktuje odrzucenie jako normalny sygnał sterujący. Agent powinien otrzymać precyzyjną wiadomość: „Odrzucono, ponieważ URL źródłowe nie zostały zweryfikowane” albo „Odrzucono, ponieważ polecenie dotyka plików poza zakresem wydania”.

Co zespoły powinny zbudować najpierw?

Zanim powstanie ładniejszy monit, warto zbudować rejestr zatwierdzeń.

Minimalne pola rejestru:

1. ID przebiegu.
2. ID agenta.
3. ID operatora.
4. Nazwa narzędzia.
5. Argumenty narzędzia.
6. Zasób docelowy.
7. Poziom ryzyka.
8. Reguła zatwierdzenia, która została wyzwolona.
9. Wskaźniki dowodów.
10. Decyzja: zatwierdzono, odrzucono, zatwierdzono automatycznie, odrzucono automatycznie, wygasło albo odwołano.
11. Czas decyzji.
12. Warunek wygaśnięcia.
13. Wynik po wykonaniu.
14. Wskaźnik wycofania albo ograniczenia skutków.

Rejestr zamienia zatwierdzenie ze zdarzenia UI w zapis odpowiedzialności. Pozwala też zespołom zadawać później lepsze pytania:

• Które narzędzia zbyt często proszą o zatwierdzenie?
• Którzy operatorzy najszybciej zatwierdzają działania wysokiego ryzyka?
• Które reguły zatwierdzeń wywołują fałszywe alarmy?
• Które odrzucone działania znalazły później bezpieczne alternatywy?
• Które zatwierdzone działania spowodowały wycofanie?
• Które trwałe zgody pozostawały aktywne zbyt długo?

Artykuł z maja 2026 roku o bezpieczeństwie systemów operacyjnych argumentuje, że agenci mierzą się ze znanymi problemami w stylu OS: izolacją zasobów, separacją uprawnień i mediowaną komunikacją.⁷ Zatwierdzenie należy do tej samej rodziny. Środowisko wykonawcze powinno mediować uprawnienia tak, jak system operacyjny mediuje operacje uprzywilejowane: wąsko, konsekwentnie i z logami, które żyją dłużej niż samo żądanie.

Krótkie podsumowanie

Zatwierdzenia agentów AI muszą stać się obiektami autoryzacji. Monit typu pauza i kliknięcie może zatrzymać wywołanie narzędzia, ale sam nie przeniesie odpowiedzialności. Użyteczne systemy zatwierdzania definiują aktora, działanie, zasób, ryzyko, dowody, czas trwania, wygaśnięcie, odwołanie i audyt.

Lekcja produktowa jest prosta: praca niskiego ryzyka powinna być cicha, praca wysokiego ryzyka wyraźna, a człowiek nigdy nie powinien zatwierdzać płynnego uzasadnienia, gdy system może zamiast tego pokazać zapis działania o ograniczonym zakresie.

FAQ

Jaka jest różnica między zatwierdzeniem a autoryzacją w przypadku agentów AI?

Zatwierdzenie jest zdarzeniem decyzyjnym człowieka. Autoryzacja jest ograniczonym uprawnieniem, które pozwala agentowi wykonać konkretne działanie w określonych warunkach. Silne systemy agentowe łączą oba elementy: zatwierdzenie przez człowieka tworzy wąski zapis autoryzacji z polami zasobu, ryzyka, wygaśnięcia, dowodów i audytu.

Czy każde wywołanie narzędzia przez agenta AI powinno wymagać zatwierdzenia?

Nie. Zespoły powinny kierować zatwierdzenia według ryzyka. Odczyty niskiego ryzyka w znanym zakresie mogą działać cicho, z logami. Działania średniego ryzyka można grupować do przeglądu. Działania wysokiego ryzyka, takie jak wysyłanie wiadomości, publikowanie, usuwanie, wdrażanie, wydawanie środków, eksportowanie albo zmiana uprawnień, powinny wstrzymywać wykonanie przed startem.

Czy trwałe zatwierdzenia są bezpieczne dla agentów AI?

Trwałe zatwierdzenia mogą pomagać, gdy zakres pozostaje wąski, krótkotrwały i widoczny. Zgoda ograniczona do przebiegu dla narzędzia tylko do odczytu może mieć sens. Szerokie trwałe zatwierdzenie dla powłoki, wdrożeń, płatności, wysyłki e-maili albo usuwania tworzy zbyt duże uprawnienie z jednej decyzji.

Co powinien zawierać monit o zatwierdzenie agenta AI?

Monit o zatwierdzenie powinien zawierać działanie, zasób, argumenty narzędzia, aktora, poziom ryzyka, dowody, wygaśnięcie, ścieżkę wycofania i wskaźnik audytu. Monit powinien też oferować decyzje: odrzuć, poproś o dowody i podziel zakres, a nie tylko zatwierdź.

Jak zespoły mogą ograniczyć zmęczenie zatwierdzeniami w produktach agentowych?

Zespoły mogą ograniczać zmęczenie przez automatyczne zezwalanie na działania niskiego ryzyka w ramach zasad, grupowanie decyzji średniego ryzyka, przerywanie tylko w punktach nieodwracalnego skutku, pokazywanie ustrukturyzowanych dowodów, wygaszanie zgód i rejestrowanie odmowy jako normalnej ścieżki sterowania. Lepsze zatwierdzenia zadają mniej niejasnych pytań, a więcej precyzyjnych.

Źródła