Ostrzeżenie Vishala Sharmy dotyczące zero trust: agenci AI potrzebują dowodu kontroli

Vishal Sharma podważa dobrze znaną obietnicę bezpieczeństwa: polecenie agentom AI, by przestrzegali zasad, nie dowodzi, że zasady te rzeczywiście zostały zachowane. Ostrzeżenie Vishala Sharmy dotyczące zero trust dotyczy agentów AI — systemów wykorzystujących modele i narzędzia programowe do działania na rzecz określonego celu. Badacz z Queen’s University Belfast pyta, jakie dowody pozostają, gdy agent twierdzi, że usunął informacje, uszanował ograniczenie lub wykonał autoryzowane zadanie.

Argument ten wywiera presję na nabywców korporacyjnych i deweloperów, by odróżniali współpracę od egzekwowalnej kontroli. Agent, który zgłasza sukces, dostarcza odpowiedź. System, który niezależnie rejestruje istotną operację, dostarcza coś, co nabywcy mogą zbadać. Te wyniki zasługują na różne poziomy zaufania.

Historycznym punktem odniesienia jest architektura zero trust NIST — podejście do bezpieczeństwa, które odrzuca automatyczne zaufanie oparte na lokalizacji sieciowej lub własności. Wyzwanie Sharmy dotyczy tego, jak zasada ta utrzymuje się, gdy agenci interpretują informacje, delegują pracę i przenoszą kontekst między zadaniami. Kluczowy kompromis jest konkretny: użyteczna autonomia wymaga dostępu, podczas gdy rozliczalna autonomia wymaga granic, które pozostają skuteczne, gdy model popełnia błąd.

Ostrzeżenie Vishala Sharmy dotyczące zero trust zaczyna się od braku dowodów

Sponsorowana przez uczelnię analiza bezpieczeństwa agentów Sharmy, opublikowana przez IEEE Spectrum, kwestionuje sposób, w jaki organizacje weryfikują zachowanie agentów. Sponsoring ma znaczenie: czytelnicy powinni traktować ją jako instytucjonalny wkład w debatę, a nie niezależną walidację komercyjnego systemu bezpieczeństwa.

Artykuł opisuje agentów działających pod nadzorem orkiestratora, czyli oprogramowania koordynującego ich zadania. Podnosi możliwość, że późniejsze prompty odzyskują informacje, o których agent został wcześniej poinstruowany, by zapomnieć. Relacjonuje także wewnętrzny eksperyment Queen’s University Belfast, w którym ataki deautoryzacyjne koordynowane przez agenta trwały od dwóch do trzech sekund. Ataki deautoryzacyjne przerywają uwierzytelnione połączenie bezprzewodowe urządzenia.

Najmocniejszym wkładem artykułu jest żądanie dowodów, podczas gdy jego twierdzenia eksperymentalne wymagają większej liczby szczegółów, zanim będą mogły wspierać szerokie wnioski.

Opublikowany opis nie przedstawia wystarczającej metodologii, aby ustanowić ogólny punkt odniesienia dla szybkości ataku. Jego omówienie odzyskiwania kontekstu nie dowodzi również, że fizycznie usunięte informacje zostały odtworzone. Informacje pozostające gdzieś dostępne w przepływie pracy stanowią inny problem niż odzyskanie danych, które już nie istnieją.

To rozróżnienie powinno kształtować odpowiedź. Stwierdzenie o zapominaniu wymaga zdefiniowanego obiektu: wiadomości, zapisanego rekordu, dostępnego dokumentu lub wyuczonego zachowania modelu. Bez tej definicji organizacje nie mogą uzgodnić, jak wyglądałoby skuteczne usunięcie.

Rozważmy hipotetycznego asystenta profilowania klientów. Użytkownik wycofuje zgodę na wykorzystanie wcześniejszego wywiadu. Asystent potwierdza, że pominie wywiad, a następnie przedstawia rekomendację podobną do swojej wcześniejszej oceny. To podobieństwo samo w sobie nie może ustalić, czy asystent odzyskał wywiad, zachował podsumowanie, czy niezależnie doszedł do tego samego wniosku.

Dochodzenie musiałoby zbadać, co system faktycznie zachował i do czego uzyskał dostęp. Wygenerowane wyjaśnienie mogłoby dostarczyć wskazówki, lecz samo wyjaśnienie nie rozstrzygałoby kwestii. Sporne zachowanie dotyczy mechanizmów otaczających odpowiedź, w tym tego, które rekordy pozostawały dostępne.

Dla nabywców zmienia to rodzaj dowodów, o które warto pytać. Dopracowana demonstracja może pokazać, że asystent odpowiada poprawnie podczas przygotowanej sesji. Kontrolowany test awarii może ujawnić, czy ograniczenie przetrwa nieoczekiwane żądanie. Demonstracje te odpowiadają na różne pytania zakupowe.

Wartość informacyjna tej wiadomości tkwi w zmianie akcentu. Sharma kieruje uwagę na moment, w którym słowna obietnica staje się twierdzeniem operacyjnym. Gdy agent obsługuje wrażliwe informacje lub działania o istotnych konsekwencjach, punkt ten zasługuje na wyraźne zbadanie.

Tworzy to również bardziej sprawiedliwy standard dla dostawców. Dostawca nie powinien musieć obiecywać, że jego model nigdy nie wygeneruje niepożądanej odpowiedzi. Powinien być w stanie wyjaśnić ograniczenia swojego wdrożenia i przedstawić dowody odpowiednie do tych ograniczeń.

Zero Trust nadal ma zastosowanie, ale tożsamość nie rozstrzyga intencji

Architektura zero trust NIST, opublikowana w sierpniu 2020 roku, koncentruje ochronę na zasobach zamiast zakładać zaufaną sieć wewnętrzną. Rozróżnia ona uwierzytelnianie, czyli ustalanie tożsamości, od autoryzacji, czyli określania dozwolonego dostępu.

Ramy te nie stają się przestarzałe tylko dlatego, że oprogramowanie potrafi interpretować język naturalny. Stanowią użyteczny punkt wyjścia: lokalizacja agenta wewnątrz organizacji nie uzasadnia automatycznie dostępu do jej zasobów.

Problem analityczny polega na tym, jaką władzę uwierzytelniony agent powinien otrzymać dla aktualnie realizowanego zadania.

Wyobraźmy sobie asystenta upoważnionego do przygotowania porównania dostawców. Czytanie zatwierdzonych ofert odpowiada temu zadaniu. Wysłanie dostawcy poufnego briefu negocjacyjnego rodzi odrębne pytanie, nawet jeśli ten sam asystent ma techniczną możliwość wysyłania e-maili.

Pomyślne uwierzytelnienie ustaliłoby, które konto podjęło próbę wysłania wiadomości. Nie ustaliłoby jednak samo w sobie, czy użytkownik zamierzał dokonać właśnie takiego ujawnienia. Dyskusja o bezpieczeństwie musi zatem zbadać żądane działanie i uprawnienie, które je wspiera.

W tym miejscu wdrożenia agentów komplikują znane decyzje korporacyjne. Instrukcja człowieka może opisywać wynik, nie wymieniając każdego działania pośredniego. „Przygotuj porównanie” pozostawia pole do interpretacji. Organizacja nadal musi zdecydować, jakie operacje taka interpretacja może autoryzować.

Pojawia się rozsądne pytanie zakupowe: co dzieje się, gdy asystent wybiera niepotrzebny krok? Odpowiedź powinna wskazywać komponent odpowiedzialny za zezwolenie lub odrzucenie operacji. Obietnica, że asystent zwykle wybiera rozsądne kroki, dotyczy zachowania, podczas gdy nabywca pyta o uprawnienia.

To samo rozumowanie dotyczy delegowania. Załóżmy, że koordynujący asystent prosi innego agenta o zbadanie historii dostawcy. Czy takie żądanie niesie ze sobą uprawnienie do przeglądania poufnych umów? Czy zezwala na dalsze delegowanie? Które pierwotne ograniczenie pozostaje widoczne dla usługi odbierającej?

Są to hipotetyczne pytania projektowe, a nie ustalenia, że każda platforma agentowa niewłaściwie obsługuje delegowanie. Ich celem jest ujawnienie założeń, zanim nabywcy przyznają szeroki dostęp. Wdrożenie może wyglądać na uporządkowane, a jednocześnie pozostawiać słabo określony model uprawnień.

Zespoły bezpieczeństwa stają zatem przed problemem zakresu. Ocena agenta jako pojedynczej aplikacji może pominąć istotne różnice między odczytywaniem, edytowaniem, wysyłaniem i usuwaniem. Ręczna ocena każdej nieszkodliwej operacji tworzyłaby inne obciążenie. Użyteczna ocena leży między tymi skrajnościami.

Zespoły produktowe powinny więc spodziewać się pytań o relację między intencją zadania a wykonywalnym uprawnieniem. Klient pytający o tę relację prosi o właściwość systemu, a nie jedynie o kolejną instrukcję dla modelu.

Ostrzeżenie Vishala Sharmy dotyczące zero trust jest najbardziej użyteczne, gdy odczytuje się je przez ten pryzmat. Wzywa organizacje do tego, by ich założenia można było skontrolować, nie twierdząc przy tym, że wszystkie istniejące zasady kontroli dostępu zawiodły.

Pamięć utrudnia ignorowanie kompromisu

Wytyczne OWASP dotyczące bezpieczeństwa agentów AI obejmują izolację pamięci, wygasanie danych, obsługę danych wrażliwych oraz autoryzację poza kontekstem agenta. Kontekst oznacza informacje przekazywane modelowi podczas generowania odpowiedzi.

Wytyczne wskazują również na zatruwanie pamięci, czyli utrzymywanie się złośliwych informacji, które wpływają na późniejsze zachowanie. Ten problem łączy zachowane informacje z przyszłymi działaniami, zamiast traktować każdą odpowiedź jako odizolowane zdarzenie.

Dla nabywców korporacyjnych nierozstrzygniętym kompromisem jest to, jak wiele użytecznej historii asystent powinien zachowywać i na podstawie czyjego utrzymującego się uprawnienia.

Rozważmy hipotetyczny przepływ pracy badawczej, który przekształca wywiady w brief projektu. Notatki historyczne pomagają asystentowi uniknąć powtarzania pytań i zachować podjęte decyzje. Te korzyści stanowią uzasadniony powód zachowywania informacji. Jednocześnie komplikują ocenę żądań wycofania zgody.

Załóżmy, że uczestnik wywiadu prosi o usunięcie wrażliwego stwierdzenia. Nabywca musi wiedzieć, jaką obietnicę oferuje produkt. Usunięcie oryginalnej transkrypcji, wykluczenie jej z przyszłego wyszukiwania i zaktualizowanie pochodnego briefu to rozróżnialne rezultaty.

Znacząca umowa określałaby mający zastosowanie rezultat. Demonstracja testowałaby wtedy ten rezultat bezpośrednio. Pytanie asystenta, czy pamięta stwierdzenie, dostarczałoby słabszych dowodów, ponieważ pytanie opiera się na tym samym interfejsie, którego zachowanie jest kwestionowane.

To rozróżnienie ma znaczenie także dla zwykłej pracy z wiedzą. Osoba wybierająca osobistą bazę wiedzy musi rozumieć, jak łączą się gromadzenie, wyszukiwanie i usuwanie informacji. Wygoda nie odpowiada na te pytania, a kategoria produktu nie ustanawia gwarancji bezpieczeństwa.

Istnieje również napięcie między dochodzeniem a minimalizacją. Organizacja może chcieć zachować wystarczająco dużo historii, by wyjaśnić istotną rekomendację. Może jednocześnie chcieć uniknąć przechowywania niepotrzebnych danych osobowych. Żaden z tych celów nie znika tylko dlatego, że pracę wykonuje asystent.

Hipotetyczne dochodzenie ilustruje trudność. Klient kwestionuje rekomendację po usunięciu leżącego u jej podstaw wywiadu. Osoby prowadzące dochodzenie potrzebują opisu, jakie autoryzowane dowody wpłynęły na decyzję. Zachowywanie wszystkich surowych rekordów na zawsze podważałoby obietnicę usunięcia; niezachowywanie niczego utrudniałoby dochodzenie.

Implikacja redakcyjna jest taka, że „pamięć” zasługuje na bardziej precyzyjny język produktowy. Nabywcy powinni oczekiwać opisów zaangażowanych rekordów oraz gwarancji przypisanych do każdego z nich. Pojedynczy przełącznik oznaczony jako „zapomnij” pozostawia zbyt wiele miejsca na sprzeczne oczekiwania.

Presja komercyjna spada na dostawców sprzedających ciągłość pracy między projektami. Im bardziej użyteczna staje się ta ciągłość, tym ważniejsze stają się jej granice dla klienta oceniającego wrażliwą pracę. Wartość funkcji pamięci i wymagania dotyczące jej zarządzania rosną razem.

Pytanie Sharmy wykracza zatem poza nietypowy scenariusz ataku. Ujawnia podstawową kwestię zakupową: czy organizacja może zweryfikować sposób obsługi informacji po zakończeniu rozmowy.

Badania przeglądarek pokazują, dlaczego architektura zmienia stawkę

Badacze z University of Washington, Franziska Roesner i David Kohlbrenner, zbadali granice pochodzenia przeglądarek w siedmiu przeglądarkach agentowych. Ich praca dotyczy polityki same-origin — reguły przeglądarki oddzielającej wzajemnie nieufne witryny internetowe.

Ich relacja z kwietnia 2026 roku opisuje eksperymenty przeprowadzone pod koniec stycznia i na początku lutego. Przedstawia demonstrację ataku między źródłami z udziałem ChatGPT Atlas w Agent Mode. W przypadku kilku innych produktów wskazuje warunki wstępne ataku, a nie równoważne, ukończone ataki.

Scenariusz zależy od konkretnych warunków, w tym skutecznego prompt injection, czyli próby skłonienia agenta, by potraktował niezaufaną treść jako instrukcje. Znaczenie mają testowane wersje i konfiguracje. Te ustalenia nie powinny przeradzać się w niepoparte twierdzenie dotyczące każdej aktualnej wersji przeglądarki.

Szersze pytanie architektoniczne brzmi: czy dostęp asystenta tworzy ścieżkę, której zwykły kod strony internetowej nie posiadałby.

Dla nabywców pytanie to stanowi użyteczniejsze porównanie niż ogólny ranking inteligencji modeli. Zdolny asystent może działać w wąskich granicach dostępu. Inne wdrożenie może ujawniać szerszy zakres informacji, polegając w większym stopniu na ocenie asystenta.

Takie konfiguracje prowadzą do różnych decyzji zakupowych, nawet gdy ich demonstracje wyglądają podobnie. Obie mogą skutecznie podsumować stronę. Dopiero dokładniejsza analiza ujawniłaby, do jakich dodatkowych informacji każdy asystent może dotrzeć podczas tego zadania.

Rozważmy hipotetycznego pracownika proszącego o podsumowanie publicznej strony dostawcy. Zamierzony wynik dotyczy tej strony. Jeżeli proces dopuszcza również dostęp do prywatnych materiałów biznesowych, osoby oceniające muszą rozumieć, dlaczego taki dostęp istnieje i co ogranicza jego wykorzystanie.

Prośba pracownika stanowi użyteczny punkt odniesienia. Określa cel biznesowy, względem którego można ocenić dodatkowy dostęp. Udane podsumowanie nie odpowiada na pytanie, czy system ujawnił więcej informacji, niż wymagało zadanie.

Dlatego też porównania wymagają ostrożnego języka. Badacze, którzy identyfikują możliwą drogę do wyrządzenia szkody, ustalili coś wartego zbadania. Niekoniecznie jednak wykazali skuteczny atak przeciwko każdemu produktowi współdzielącemu jedną cechę konstrukcyjną.

Nabywca powinien stosować tę samą dyscyplinę wobec odpowiedzi dostawców. Załatany przykład może zamknąć zademonstrowaną drogę, nie dowodząc, że zniknęła każda powiązana droga. Z kolei starsze ustalenie badawcze nie powinno automatycznie być przedstawiane jako nierozwiązana podatność obecnie.

Wniosek dla bieżącej debaty ma charakter metodologiczny. Twierdzenia dotyczące bezpieczeństwa stają się bardziej informacyjne, gdy wskazują badaną granicę, zaangażowane warunki i zaobserwowany wynik. Same nazwy produktów nie są w stanie przekazać tego wyjaśnienia.

Wspiera to żądanie Sharmy dotyczące dowodów, jednocześnie dodając ważne ograniczenie. Dowody powinny pozostać powiązane z systemem i okolicznościami, które je wytworzyły. Rozszerzenie ich dalej wymaga dodatkowych testów, a nie silniejszej retoryki.

Lepsze Zachowanie Modelu Nie Rozstrzyga Kwestii Ograniczania

Opis Anthropic z listopada 2025 roku dotyczący ochrony przed prompt injection przedstawia szkolenie, systemy wykrywania i testy adversarialne dla korzystania z przeglądarki. Firma wyraźnie przyznaje, że agenci przeglądarkowi pozostają podatni na zagrożenia.

W dyskusji z maja 2026 roku na temat ograniczania agentów rozróżnia się zabezpieczenia modelu od ograniczeń środowiska, w którym działa agent. Ograniczanie oznacza limitowanie tego, do czego system może dotrzeć lub co może zrobić. Anthropic opisuje stosowanie granic środowiskowych obok środków mających poprawić zachowanie modelu.

Są to relacje dostawcy dotyczące jego podejścia. Ustanawiają przedstawione przez firmę uzasadnienie bezpieczeństwa, a nie niezależny dowód, że każde wdrożenie osiąga zamierzoną ochronę.

Istotne porównanie dotyczy różnicy między zmniejszeniem prawdopodobieństwa błędu a ograniczeniem konsekwencji, gdy błąd wystąpi.

Hipotetyczny asystent dokumentów konkretyzuje to rozróżnienie. Lepsza ocena sytuacji może pomóc mu odrzucić zwodniczą instrukcję zawartą w propozycji. Ograniczenie dostępu może uniemożliwić mu uzyskanie niezwiązanego z zadaniem poufnego dokumentu, niezależnie od tego, jak zinterpretuje tę instrukcję.

Te wyniki odpowiadają na odrębne pytania. Klient chce rozsądnego zachowania podczas uzasadnionej pracy. Chce też otrzymać możliwą do obrony odpowiedź na pytanie, co dzieje się w przypadku awarii. Rzetelna ocena powinna badać oba aspekty.

Stwarza to praktyczne wyzwanie dla prezentacji zakupowych. Demonstracje modeli są łatwe do zrozumienia, ponieważ pokazują widoczne zachowanie. Ograniczenia środowiskowe mogą wyglądać mniej imponująco, dopóki oceniający nie poprosi systemu o przekroczenie zakazanej granicy.

Przekonująca demonstracja uwidoczniłaby próbę przekroczenia granicy. Osoby oceniające mogłyby następnie zbadać, co ją zablokowało, jakie dowody pozostały oraz czy uzasadnione zadanie mogło być kontynuowane. Samo odrzucenie byłoby jedynie częścią wyniku.

Ocena powinna również uwzględniać koszt ograniczeń. Ściśle ograniczony asystent może wymagać dodatkowych danych od użytkownika albo nie zrealizować skądinąd rozsądnego zadania. Nie oznacza to, że ograniczenie jest niewłaściwe. Oznacza, że jego efekt operacyjny jest częścią decyzji zakupowej.

Podobnie częste przerwania nie są automatycznie dowodem lepszego bezpieczeństwa. Przerwanie zasługuje na uwagę, gdy pomaga osobie zrozumieć i autoryzować istotną konsekwencję. Niejasna prośba o zatwierdzenie może pozostawić podstawową decyzję równie niejasną.

Użyteczne pytanie nabywcy jest zatem konkretne: które proponowane działanie oczekuje na czyje upoważnienie i co dokładnie zmienia się po zatwierdzeniu? Odpowiedź powinna pozostać zrozumiała dla osoby odpowiedzialnej za wynik biznesowy.

Takie ujęcie pozwala uniknąć sztucznej rywalizacji między inteligentniejszymi modelami a silniejszymi granicami. Klienci korzystają z obu, lecz powinni prosić dostawców o wyjaśnienie wkładu każdego z nich. Poprawa w jednym obszarze nie dowodzi poprawy w każdym innym.

Zaostrza to również presję konkurencyjną. Dostawcy sprzedający szerszą autonomię potrzebują dowodów współmiernych do uprawnień, o które proszą ich produkty. Ciężar ten rośnie wraz z konsekwencjami błędnego działania.

Ostrzeżenie Vishala Sharmy dotyczące zero trust wpisuje się w tę debatę, lecz jej nie rozstrzyga. Kwestia polega na tym, czy wdrożenie przedstawia wiarygodny opis kontroli, gdy współpracujące zachowanie przestaje wystarczać.

Kolejne Dowody Powinny Pochodzić z Testów Awarii

W ciągu najbliższych trzech miesięcy najbardziej użyteczne sygnały będą dotyczyć powtarzalności, egzekwowania ograniczeń oraz zachowania w realistycznych warunkach awarii. Są to punkty obserwacyjne redakcji, a nie zapowiedziane zobowiązania wydawnicze.

Najsilniejsze dowody wyjaśnią, co zawiodło, co pozostało chronione i czy uzasadniona praca mimo to została ukończona.

Po pierwsze, warto obserwować powtarzalny opis eksperymentu Queen’s University Belfast. Pełniejsza publikacja powinna najlepiej określać sprzęt, konfigurację, metodę pomiaru czasu oraz punkt odniesienia użyty do oceny zgłoszonej szybkości ataku.

Dowody te wzmocniłyby twierdzenie eksperymentalne, gdyby niezależne zespoły uzyskały porównywalne wyniki w określonych warunkach. Węższy wynik nadal byłby informacyjny. Pomógłby czytelnikom odróżnić konkretną obserwację laboratoryjną od ogólnego twierdzenia o atakach wspomaganych przez agentów.

Ten sam standard dotyczy odzyskiwania kontekstu. Użyteczny test określałby, jakie informacje usunięto, gdzie wcześniej się znajdowały i które ścieżki odzyskiwania pozostały dostępne. Bez tych szczegółów pozorne przypominanie sobie pozostawia zbyt wiele możliwych wyjaśnień.

Po drugie, warto obserwować wydania produktów, które ułatwiają kontrolę granic uprawnień. Istotnym sygnałem jest udokumentowana zmiana powiązana z możliwym do przetestowania ograniczeniem. Sama nowa etykieta bezpieczeństwa nie dostarcza takich dowodów.

Na przykład hipotetyczne wydanie mogłoby wykazać, że asystent potrafi przygotować zewnętrzną wiadomość, podczas gdy oddzielny komponent kontroluje jej wysłanie. Osoby oceniające nadal musiałyby zbadać odbiorcę, treść i warunki autoryzacji objęte tym ograniczeniem.

Takie dowody wzmocniłyby argument, że dostawcy przekładają ogólne zasady bezpieczeństwa na możliwe do wdrożenia mechanizmy kontroli. Wydanie, które jedynie dodaje kolejną instrukcję, zapewniałoby mniejsze wsparcie dla twierdzeń o niezależnie egzekwowanych ograniczeniach.

Po trzecie, warto obserwować niezależne oceny, które testują odzyskiwanie sprawności równolegle z odpornością na ataki. Zablokowanie niepożądanej operacji jest wartościowe. Nabywcy muszą także wiedzieć, czy system potrafi się odtworzyć bez ponawiania próby, utraty autoryzowanej pracy lub wymagania nadmiernej interwencji.

Hipotetyczna ocena mogłaby porównać to samo zadanie przed i po wprowadzeniu ograniczenia dostępu. Wynik powinien opisywać zarówno zakazane działania, jak i prawidłowe ukończenie zadania. W przeciwnym razie system, który niewiele osiąga, może sprawiać wrażenie bezpiecznego z niepomocnego powodu.

Wyniki pokazujące ograniczoną szkodę i pomyślnie wykonaną autoryzowaną pracę wzmocniłyby argument za praktyczną autonomią. Wyniki pokazujące, że użyteczne ukończenie wymaga szerokiego, słabo wyjaśnionego dostępu, ujawniłyby utrzymujący się kompromis.

Sygnały te mają znaczenie, ponieważ obecny argument może w przeciwnym razie stać się kolisty. Badacze proszą o weryfikację. Dostawcy opisują zabezpieczenia. Nabywcy otrzymują zapewnienia bez wspólnego opisu tego, co te zapewnienia obejmują.

Dokładniejsze dowody umożliwiłyby węższy, bardziej produktywny spór. Jedno wdrożenie może odpowiadać do tworzenia szkiców i badań, podczas gdy inne wspiera działania o istotnych konsekwencjach. Uzasadnienie powinno określać, co każdy system może wykazać na temat własnego zachowania.

Dla programistów bezpośrednią konsekwencją jest uczynienie twierdzeń dotyczących bezpieczeństwa testowalnymi przed rozszerzeniem obowiązków agenta. Dla nabywców korporacyjnych oznacza to powiązanie żądanych dowodów z konkretną konsekwencją biznesową. Dla pracowników wiedzy oznacza to zrozumienie uprawnień związanych z asystentem przed powierzeniem mu wrażliwej pracy.

Przed kolejnym pilotażem agenta wybierz sporne działanie i określ dowody, które je rozstrzygną. Rozważ nieuprawnionego odbiorcę, wycofany dokument lub żądanie wykraczające poza pierwotne zadanie. Poproś dostawcę o pokazanie, co się dzieje, gdzie działa ograniczenie i jaki zapis pozostaje afterward. Następnie oceń, czy autoryzowane zadanie nadal zostaje ukończone. Traktuj demonstrację jako dowód dotyczący tego wdrożenia i konfiguracji, z jasno określonymi ograniczeniami. Ostrzeżenie Vishala Sharmy dotyczące zero trust stanowi użyteczne pytanie wyjściowe do tej rozmowy: gdy asystent twierdzi, że przestrzegał zasad, co ktoś inny może faktycznie zweryfikować?