Ostrzeżenie Microsoftu dotyczące bezpieczeństwa agentów AI stawia autonomię przedsiębiorstw pod znakiem zapytania

Microsoft ostrzegł 19 października, że korporacyjni agenci AI mogą stać się wewnętrznym zagrożeniem dla bezpieczeństwa, nawet jeśli żaden atakujący ich nie przejmie. Ostrzeżenie Microsoftu dotyczące bezpieczeństwa agentów AI podważa wygodne założenie: oprogramowanie wdrożone przez firmę zasługuje na taki sam dostęp jak jej pracownicy. Proponowana odpowiedź, Guardian Agents, rodzi kolejne pytanie: kto kontroluje systemy nadzorujące tych agentów?

Visual Studio Magazine ponownie zwrócił uwagę na to ostrzeżenie 28 października, opisując stanowisko Microsoftu dotyczące agentowego ryzyka wewnętrznego. Agenci AI, czyli systemy wykorzystujące modele i narzędzia do realizacji zadań, wprowadzają decyzje między żądaniem a jego wykonaniem. Pracownik może zatwierdzić cel, nie przewidując każdego działania wybranego przez agenta.

Kluczowy kompromis dotyczy użytecznej autonomii i egzekwowalnych uprawnień. CrowdStrike i Okta rozwijają powiązane mechanizmy kontroli, oferując przedsiębiorstwom konkurencyjne podejścia do oceny. Dla programistów, zespołów bezpieczeństwa i właścicieli firm najpilniejsze pytanie brzmi, gdzie kończą się uprawnienia agenta, gdy jego interpretacja zadania się zmienia.

Bezpieczeństwo agentów AI Microsoftu zwraca się ku zagrożeniu wewnętrznemu

Wiceprezes wykonawcza Microsoft Security, Hayete Gallot, przedstawiła stanowisko firmy we wpisie z 19 października dotyczącym zabezpieczania agentowych zagrożeń wewnętrznych. Argumentowała, że modele realizują cele, nie rozumiejąc z natury organizacyjnej oceny sytuacji. To sprawia, że ich zachowanie budzi obawy, nawet gdy nikt nie ukradł poświadczeń ani nie zmienił ich oprogramowania.

Microsoft proponuje Guardian Agents do nadzorowania aktywności i reagowania na zmiany ryzyka. Podejście to rozwija Project Perception, ogłoszony przez firmę w lipcu. Gallot wzywa także do zwiększenia widoczności zachowania modeli przy jednoczesnym utrzymaniu kontroli ochronnych poza inteligencją, którą te kontrole regulują.

Microsoft prosi przedsiębiorstwa, aby traktowały zadanie agenta i jego uprawnienia jako odrębne decyzje bezpieczeństwa.

To rozróżnienie zmienia sposób, w jaki nabywcy powinni interpretować to ogłoszenie. Ramy ryzyka wewnętrznego opisują ekspozycję wynikającą z legalnego dostępu. Nie dowodzą, że każdy agent zachowuje się niebezpiecznie ani że zwykła automatyzacja przedsiębiorstwa nagle stała się przeciwnikiem.

Rozważmy różnicę między zleceniem pracy a zatwierdzeniem jej konsekwencji. Poproszenie systemu o rozwiązanie problemu klienta ustanawia cel. Nie upoważnia automatycznie do zwrotów pieniędzy, zmian na koncie, zobowiązań umownych ani ujawnienia informacji innego klienta.

Ten przykład ilustruje główną kwestię artykułu, a nie opisany przez Microsoft incydent. Zadanie brzmi zwyczajnie, lecz możliwe działania niosą różne konsekwencje. Szeroka instrukcja nie może rozstrzygnąć każdego pytania o uprawnienia ukrytego w jej realizacji.

Ostrzeżenie wymaga także precyzyjnej osi czasu. Materiał z 28 października powrócił do stanowiska Microsoftu z 19 października. Czytelnicy nie powinni mylić daty publikacji z osobną premierą produktu, nowo ujawnionym naruszeniem ani świeżymi dowodami mierzącymi częstotliwość incydentów.

Istnieje też różnica między zaproponowaniem architektury a potwierdzeniem jej skuteczności. Architektura opisuje, gdzie powinny znajdować się mechanizmy kontroli i jak powinny współpracować. Dowody muszą wykazać, czy te mechanizmy rozpoznają niebezpieczne działania, interweniują wystarczająco wcześnie i pozwalają nadal użytecznie wykonywać legalną pracę.

To rozróżnienie ma znaczenie, ponieważ ogłoszenia dotyczące bezpieczeństwa często łączą wiarygodny problem z proponowaną odpowiedzią komercyjną. Uznanie problemu nie wymaga akceptowania każdego twierdzenia o rozwiązaniu. Nabywcy mogą zgodzić się, że uprawnienia agentów wymagają ograniczeń, jednocześnie żądając dowodów, że konkretna implementacja je egzekwuje.

Praktyczna zmiana dotyczy więc ciężaru wyjaśnienia. Sponsor agenta powinien wyjaśnić zadanie, dozwolone działania i osobę odpowiedzialną. Dostawca powinien wyjaśnić, jak jego produkt egzekwuje te granice, gdy agent obierze nieoczekiwaną ścieżkę.

Presja spada na tych, którzy przyznają dostęp

Ostrzeżenie to najbardziej bezpośrednio wywiera presję na osoby łączące agentów z systemami biznesowymi o istotnych konsekwencjach. Ich decyzje określają, czy błędna interpretacja pozostaje szkicem, czy staje się zdarzeniem operacyjnym. Odpowiedzialność ta obejmuje rozwój oprogramowania, bezpieczeństwo informacji, właścicieli aplikacji i zarządzanie biznesowe.

Wdrożenie agenta potrzebuje właściciela jego uprawnień, a także właściciela jego wyników.

Przydatnym sposobem zbadania tej odpowiedzialności jest hipotetyczny proces sprzedażowy. Asystent przygotowuje podsumowanie konta na podstawie wewnętrznych notatek i korespondencji z klientem. Jego pierwotny cel ma charakter informacyjny, lecz ktoś później łączy go z narzędziami aktualizującymi dane konta.

Zadanie pisarskie i zadanie zmieniające dane zasługują na odrębne rozpatrzenie. Niedokładne podsumowanie może wprowadzić czytelnika w błąd. Niedokładna aktualizacja może stać się częścią systemu, na którym polegają inni pracownicy, rozszerzając konsekwencje poza pierwotną rozmowę.

To rozróżnienie nie wymaga zakładania złośliwych intencji. Agent może źle zrozumieć żądanie, nadinterpretować nieformalny komentarz lub wybrać niewłaściwą drogę do osiągnięcia skądinąd uzasadnionego celu. Pytanie bezpieczeństwa dotyczy tego, na co system pozwala, gdy te niepewności pozostają nierozstrzygnięte.

Dla programistów presja ujawnia się w projektowaniu interfejsów. Narzędzie łączące odczyt, edycję i publikację w jednej szerokiej operacji tworzy inną ekspozycję niż odrębne operacje. Istotnym wyborem projektowym jest to, czy aplikacja potrafi wyrazić granicę faktycznie zamierzoną przez firmę.

Dla sponsorów biznesowych presja dotyczy delegowania. Menedżer może opisać pożądany rezultat, pozostawiając przypadki wyjątkowe niezdefiniowane. Jeśli agent napotka wyjątek, system potrzebuje wyraźnego miejsca docelowego dla tej decyzji, zamiast zakładać, że ukończenie zawsze ma pierwszeństwo.

Dla zespołów bezpieczeństwa presja dotyczy przypisywania odpowiedzialności, czyli zdolności do powiązania działania z odpowiedzialnym podmiotem. Jeśli rekord się zmieni, dochodzenie musi odróżnić żądanie pracownika od interpretacji agenta i wykonania przez narzędzie. W przeciwnym razie sama nazwa konta przedstawia niepełną historię.

Pracownicy wiedzy napotykają pokrewną kwestię, gdy łączą osobiste badania ze współdzielonymi zasobami. Osobista baza wiedzy służy innemu celowi niż przestrzeń robocza zawierająca dane organizacyjne. Decyzje o dostępie powinny odzwierciedlać zamierzone grono odbiorców i dozwolone wykorzystanie każdego źródła.

Dlatego krótkoterminowa odpowiedź powinna zacząć się od jasności co do delegowania. Które wyniki mogą być realizowane automatycznie, które wymagają przeglądu, a które pozostają poza zakresem zadania? Są to decyzje biznesowe wyrażane przez mechanizmy techniczne, a nie pytania, które model powinien rozstrzygać samodzielnie.

Z czasem ta jasność staje się również wymogiem zakupowym. Nabywcy potrzebują produktów, które odzwierciedlają ich rzeczywiste granice zatwierdzania. System, który wykonuje użyteczną pracę, lecz nie potrafi odróżnić przygotowania od zobowiązania, pozostawia organizacji obowiązek rozwiązania tej niejednoznaczności gdzie indziej.

Użyteczna autonomia wymaga ograniczeń poza modelem

Proponowany przez Microsoft mechanizm oddziela decyzje generowane przez model od egzekwowania uprawnień. W towarzyszącej mu architekturze ograniczania agentów firma opisuje Dynamic Permissions, które ograniczają zakres dostępu do zatwierdzonego zadania. Dynamic Agent Risk aktualizuje ocenę wraz ze zmianą aktywności, a Dynamic Conditional Access dostosowuje zakres działań dostępnych dla agenta.

Microsoft twierdzi, że te dostosowania mogą zachować możliwość odczytu przy blokowaniu zapisu, zawężać dostępne zasoby lub wymagać zatwierdzenia przez człowieka. Opisuje także izolowane środowiska wykonawcze, które ograniczają zasoby dostępne dla działającego oprogramowania. Są to proponowane warstwy ochrony, a nie dowód, że każde wdrożenie już otrzymuje identyczny zakres ochrony.

Przykład firmy dotyczący przetwarzania wydatków pokazuje zamierzoną sekwencję. Agent napotyka prompt injection, czyli złośliwe instrukcje osadzone w czytanych przez niego materiałach, i próbuje wykonać niepowiązaną czynność. Microsoft twierdzi, że system bezpieczeństwa powinien rozpoznać rosnące ryzyko i ograniczyć uprawnienia agenta.

Decydującą granicą jest to, czy zewnętrzny mechanizm kontroli może odrzucić działanie, które model chce wykonać.

Ta granica nadaje kompromisowi autonomii konkretny kształt. Organizacja może pozwolić na elastyczne rozumowanie, jednocześnie ograniczając wykonanie działań o istotnych konsekwencjach. Model może zaproponować drogę, lecz inny system decyduje, czy żądane działanie mieści się w już przyznanych uprawnieniach.

Hipotetyczny proces pracy z dokumentami ułatwia dostrzeżenie tej różnicy. Agent może przygotowywać poprawki, porównywać wersje i wskazywać nierozstrzygnięte pytania. Opublikowanie tych poprawek na publicznej stronie internetowej stanowi odrębne zobowiązanie, nawet jeśli model uznaje publikację za konieczną do zakończenia pracy.

Wartość granicy zależy od miejsca jej działania. Ostrzeżenie wyświetlone po publikacji nie służy temu samemu celowi co kontrola przed publikacją. Nabywcy powinni analizować moment, w którym decyzja staje się działaniem, zamiast oceniać ochronę po wyglądzie pulpitu monitorującego.

Wyjaśnia to również, dlaczego sama instrukcja w języku naturalnym pozostawia niepełny mechanizm kontroli. Polecenie agentowi, by działał zgodnie z polityką, komunikuje oczekiwanie. Odrębny system uprawnień określa, czy próba wyjątku rzeczywiście może zostać zrealizowana.

Podobnej analizy wymaga prośba o zatwierdzenie. Osoba zatwierdzająca potrzebuje wystarczającego kontekstu, aby zrozumieć proponowaną operację, jej cel i jej skutki. Pytanie, czy użytkownik chce kontynuować, daje niewielką pewność, jeśli sama operacja pozostaje niejasna.

Ta sama zasada obowiązuje, gdy zadanie się rozszerza. Odkrycie, że dodatkowy dostęp pomógłby ukończyć zadanie, nie oznacza, że dostęp ten jest właściwy. Rozszerzenie powinno uruchamiać decyzję podjętą przez podmiot odpowiedzialny za dany zasób.

Istnieje produktywna wersja tego kompromisu. Jasne ograniczenia mogą ułatwić szersze eksperymentowanie, ponieważ zespoły wiedzą, które konsekwencje pozostają ograniczone. Jest to jednak argument architektoniczny, a nie gwarancja, że konkretny produkt nadzorczy go zapewni.

CrowdStrike i Okta wybierają różne punkty kontroli

Propozycja Microsoftu wpisuje się w szerszą rywalizację o to, gdzie należy kontrolować aktywność agentów w przedsiębiorstwach. CrowdStrike kładzie nacisk na wykonanie na urządzeniach, podczas gdy Okta podkreśla tożsamość powiązaną z żądaniem. Oba podejścia rozwiązują ten sam problem autonomii z różnych pozycji.

CrowdStrike przedstawił Falcon Guardian 1 września. W ogłoszeniu dotyczącym bezpieczeństwa środowiska wykonawczego agentów opisano wykrywanie agentów, łączenie ich aktywności ze zdarzeniami na urządzeniach oraz egzekwowanie kontroli dostępu. Środowisko wykonawcze oznacza okres, w którym oprogramowanie jest uruchomione, więc istotne pytanie brzmi, co agent faktycznie robi na maszynie.

Okta opisuje Agent Gateway jako pośrednika między agentami a narzędziami przedsiębiorstwa. Jego podejście do egzekwowania tożsamości w czasie działania weryfikuje zarówno użytkownika składającego żądanie, jak i działającego agenta. Okta podaje, że polityka jest stosowana w chwili wywołania narzędzia, czyli żądania wykonania operacji.

Konkurencyjne podejścia sprawiają, że zakres ochrony i egzekwowanie zasad są bardziej użytecznymi punktami porównania niż etykieta przypisana strażnikowi.

Są to opisy dostawców, a nie niezależnie porównywalne wyniki wydajności. Wskazują różnice w akcentach, lecz nie wyłaniają zwycięzcy. Kupujący nadal musi ustalić, które działania produkt obserwuje, które może zablokować oraz gdzie musi przejąć kontrolę inne zabezpieczenie.

Hipotetyczny przepływ pracy programistycznej pokazuje, dlaczego to rozróżnienie ma znaczenie. Agent może edytować lokalne pliki, zanim poprosi o dostęp do zewnętrznej aplikacji biznesowej. Operacje te przekraczają różne granice, choć pracownik odbiera je jako element jednego, ciągłego zadania.

Kontrola skoncentrowana na urządzeniu oraz pośrednik skoncentrowany na tożsamości mogą zatem odpowiadać na różne pytania. Czy proces wykonał nieoczekiwaną operację? Czy ten konkretny agent był upoważniony do zażądania tego konkretnego narzędzia w imieniu tego użytkownika?

Żadne z tych pytań nie eliminuje drugiego. Wiedza o tym, kto zażądał operacji, sama w sobie nie przesądza, czy operacja ma sens biznesowy. Obserwowanie operacji na maszynie nie określa samo w sobie pełnego zakresu przekazanych pracownikowi uprawnień.

Porównanie architektury powinno podążać za przepływem pracy, a nie za kategorią dostawcy. Kupujący mogą prześledzić, gdzie informacje trafiają do systemu, gdzie zapadają decyzje i gdzie możliwe stają się zewnętrzne skutki. Każde przejście ujawnia miejsce, w którym twierdzenie dotyczące ochrony wymaga konkretnego wyjaśnienia.

Dyskusje zakupowe powinny również odróżniać obecne działanie od planowanej rozbudowy. Demonstracja wykrywania dowodzi czegoś innego niż demonstracja blokowania. Planowana integracja dowodzi czegoś innego niż działające połączenie w środowisku klienta.

Szersze znaczenie dla branży polega na przesunięciu w stronę możliwości kontrolowania delegowania zadań. Microsoft, CrowdStrike i Okta opisują różne sposoby łączenia aktywności agentów z kontrolą przedsiębiorstwa. Ich twierdzenia zasługują na ocenę przez pryzmat tych samych pytań operacyjnych, nawet gdy ich produkty zajmują różne miejsca w środowisku.

Dla kupujących tworzy to możliwość wymagania konkretów. Zamiast pytać, czy produkt zabezpiecza agentów AI, warto pytać, którymi istotnymi operacjami zarządza. Odpowiedź powinna wskazać punkt egzekwowania zasad, mającą zastosowanie tożsamość oraz dowody dostępne później.

Agenci strażniczy niosą własny ciężar weryfikacji

Wykorzystanie agentów do nadzorowania innych agentów wprowadza drugą warstwę niepewności. Nadzorca musi interpretować aktywność, odróżniać akceptowalne odchylenia od niebezpiecznych oraz wybrać odpowiednią reakcję. Ocena tych osądów powinna towarzyszyć ocenie zachowania nadzorowanego systemu.

W relacji z 23 października Dark Reading podał, że nowe możliwości Guardian Agent pozostawały ograniczone do Microsoftu i wybranych klientów. Omówienie ograniczeń nadzoru nad agentami obejmowało również obawy analityka Forrester, Andrasa Csera, dotyczące nieprzewidywalnych nadzorców. CTO Suzu Labs, Denis Calderone, ostrzegł, że szkodliwe skutki mogą wystąpić w ramach autoryzowanego dostępu.

Te obserwacje wskazują odrębne problemy. Granica uprawnień może być egzekwowana prawidłowo, a mimo to dopuścić szkodliwą decyzję biznesową. Nadzorca może także błędnie zinterpretować uzasadnione działanie i przerwać użyteczną pracę.

Strażnik zasługuje na zaufanie dzięki mierzalnym decyzjom i możliwym do wyegzekwowania ograniczeniom własnych uprawnień.

Rozważmy hipotetycznego agenta upoważnionego do aktualizowania danych klientów. Może on wpisać błędny wniosek do właściwego pola, używając właściwego narzędzia. Każda kontrola dostępu może zakończyć się powodzeniem, podczas gdy wynik biznesowy nadal pozostaje błędny.

Ten przykład wyjaśnia, dlaczego kontrola uprawnień nie może nieść całego ciężaru zapewnienia jakości. Autoryzacja określa, czy podmiot może wykonać operację. Nie ustala, czy stojący za nią osąd jest trafny, odpowiedni lub poparty dostępnymi dowodami.

Nadzorca również potrzebuje zdefiniowanej granicy reakcji. Wykrycie podejrzanej aktywności i zaproponowanie ograniczenia różni się od samodzielnej zmiany danych biznesowych lub wyłączenia niepowiązanych usług. Kupujący powinni pytać, co strażnik może zmieniać i kto zatwierdza rozszerzenie tych uprawnień.

Ocena musi obejmować zarówno niepotrzebną interwencję, jak i przeoczone zagrożenie. System blokujący zwykłą pracę tworzy presję, by go omijać. System tolerujący zbyt wiele wątpliwej aktywności pozostawia organizację narażoną, mimo uspokajającego interfejsu nadzoru.

Użyteczna ocena powinna zatem obejmować zwykłe zadania, niejednoznaczne żądania i jasno zakazane operacje. Istotnym dowodem jest wynikające z nich zachowanie oraz wyjaśnienie. Kupujący muszą zobaczyć, czy produkt konsekwentnie stosuje zamierzoną politykę w tych przypadkach.

Twierdzenia dotyczące przejrzystości zasługują na równie staranne traktowanie. Wyjaśnienie modelu może pomóc badaczowi sformułować hipotezę dotyczącą działania. Powinno zostać sprawdzone względem faktycznego żądania, aktywności narzędzia, dostępu do zasobów i wynikającej z tego zmiany.

Rozróżnienie dotyczące dostępności pozostaje kluczowe. Ograniczone użycie przez klientów może przynieść cenną wiedzę, ale nie potwierdza szerokiej niezawodności w różnych środowiskach przedsiębiorstw. Ogłoszenie uzasadnia analizę podejścia; nie rozstrzyga, czy kupujący powinien polegać na każdej proponowanej funkcji.

Bezpieczeństwo agentów AI Microsoftu stoi zatem przed wielowymiarowym ciężarem weryfikacji. Firma musi wyjaśnić zakres ochrony, zachowanie podczas interwencji oraz stan wdrożenia. Klienci potrzebują dowodów, że mechanizmy kontroli odpowiadają ich własnym przepływom pracy i granicom zatwierdzania.

Sceptyczne stanowisko nie musi odrzucać nadzoru nad agentami. Pyta ono, czy nadzorca pozostaje rozliczalny, gdy jego osąd jest błędny. To pytanie powinno należeć do decyzji wdrożeniowych od samego początku, zamiast pojawiać się dopiero po przerwaniu pracy lub szkodliwym działaniu.

Kolejnymi sygnałami będą dostępność, interoperacyjność i wyniki

Nadchodzące miesiące oferują konkretne sposoby oceny kierunku Microsoftu bez zakładania ani sukcesu, ani porażki. Najbardziej użyteczne sygnały dotyczą tego, co klienci mogą wdrożyć, jakimi systemami mechanizmy kontroli mogą zarządzać oraz co dzieje się podczas rzeczywistych przepływów pracy. Każdy z nich testuje inną część kompromisu związanego z autonomią.

Najmocniejsze dowody połączą zadeklarowaną politykę z obserwowalną decyzją, zanim nastąpi istotne działanie.

Po pierwsze, warto obserwować precyzyjne informacje o dostępności. Microsoft powinien rozróżniać ogłoszoną architekturę, dostęp ograniczony, funkcje w wersji zapoznawczej i funkcje ogólnie dostępne. Szerszy dostęp wzmocniłby argument, że propozycja staje się operacyjna, podczas gdy utrzymująca się niejednoznaczność ograniczałaby wnioski, jakie kupujący mogą rozsądnie wyciągać.

Szczegóły dostępności powinny wskazywać odpowiednie środowisko i wymagania wstępne. Możliwość dostępna w wybranym wdrożeniu nie potwierdza automatycznie zakresu ochrony gdzie indziej. Klienci potrzebują wystarczających informacji, aby odtworzyć chroniony przepływ pracy, zamiast wywnioskować dostępność z szerokiej nazwy produktu.

Po drugie, warto obserwować zademonstrowaną interoperacyjność, czyli skoordynowane działanie produktów różnych dostawców. Użytecznym dowodem jest kompletny przepływ pracy przekraczający systemy organizacyjne, z zachowaniem kontekstu tożsamości i polityki. Samo ogłoszenie partnerstwa pozostawia pytanie operacyjne bez odpowiedzi.

Przekonująca demonstracja pokazałaby, gdzie decyzja została wyegzekwowana i co stało się po zmianie dostępu. Jeśli ograniczenie pojawia się na pulpicie, lecz operacja w dalszym systemie nadal kończy się powodzeniem, mechanizm kontroli nie zapewnił zamierzonej granicy. Działające egzekwowanie zasad wzmocniłoby twierdzenie dotyczące szerszej architektury.

Po trzecie, warto obserwować mierzone wyniki wdrożeń u klientów. Użyteczne raportowanie rozróżniałoby zablokowane szkodliwe działania, niepotrzebne przerwania oraz incydenty poza zakresem ochrony produktu. Opisanie testowanego środowiska uczyniłoby te wyniki bardziej znaczącymi niż pojedyncza historia sukcesu.

Istotne porównanie dotyczy tego, czy zespoły zyskują użyteczną autonomię, zachowując jednocześnie zamierzone granice zatwierdzania. Dowody niezawodnej interwencji wspierałyby tezę Microsoftu. Częste obchodzenie mechanizmów, niejasna odpowiedzialność lub szkodliwe działania w ramach zatwierdzonych uprawnień ujawniłyby obszary wymagające dodatkowej kontroli.

Dla programistów te sygnały pomagają podejmować decyzje dotyczące interfejsów i wdrożeń. Dla kupujących w przedsiębiorstwach kształtują kryteria oceny i pytania kontraktowe. Dla pracowników określają, czy rosnące możliwości agenta pojawiają się wraz ze zrozumiałymi ograniczeniami.

Bezpieczeństwo agentów AI Microsoftu powinno być ostatecznie oceniane w punkcie, w którym instrukcja staje się konsekwencją biznesową. To tam obietnica delegowanej pracy spotyka się z odpowiedzialnością organizacji za to, co wydarzy się dalej.

Przed rozszerzeniem zakresu zadania agenta prześledź istotną operację od żądania pracownika do jej ostatecznego skutku. Ustal, kto ją autoryzował, który system mógł ją odrzucić i jakie dowody wyjaśniłyby rezultat. Następnie poproś dostawcę o zademonstrowanie tej granicy przy użyciu rzeczywistych zasad zatwierdzania. Uwzględnij zwykłe zadanie, niejednoznaczne żądanie oraz działanie, które musi pozostać zakazane. Celem jest ustalenie, gdzie spoczywa odpowiedzialność, gdy model wybierze nieoczekiwaną drogę. Skup ocenę na obserwowalnym zachowaniu, a nie na zapewnieniach dotyczących intencji. Jeśli agent jutro zaproponuje istotne działanie, kto ma uprawnienie, by zatrzymać je, zanim nastąpi?