Shufti Know Your Agent łączy działania AI ze zweryfikowanymi właścicielami i uprawnieniami

Shufti uruchomiło Know Your Agent 28 października, rozszerzając weryfikację tożsamości na agentów AI i rozdzielając zweryfikowane właścicielstwo od uprawnienia do działania. Shufti Know Your Agent jest skierowane do firm otrzymujących zautomatyzowane żądania od oprogramowania działającego w imieniu klientów lub pracowników. Jego główna teza jest konkretna: zidentyfikowanie posiadacza konta nie dowodzi, że każde działanie podjęte w imieniu tej osoby zostało autoryzowane.

Ogłoszenie wywiera presję na firmy łączące agentów z transakcjami i wrażliwymi informacjami. Agent AI, czyli oprogramowanie wybierające i wykonujące zadania w dążeniu do celu, potrzebuje użytecznych uprawnień. Jednak zbyt szeroko przyznane uprawnienia mogą zmienić legalnego asystenta w źródło nieautoryzowanych zmian. Firma otrzymująca żądanie musi odróżnić zatwierdzoną prośbę od działania, które jedynie dociera z ważnymi poświadczeniami.

Microsoft Entra Agent ID oferuje użyteczne porównanie poprzez zarządzanie tożsamościami agentów, własnością i dostępem. Shufti podkreśla powiązanie między zewnętrznym agentem, jego zweryfikowanym właścicielem a mandatem tego właściciela, czyli granicami delegowanych uprawnień. Podejścia te dotyczą nakładających się problemów, ale wychodzą z różnych punktów. Kluczowe pytanie brzmi, czy autoryzacja pozostaje egzekwowalna, gdy agent przechodzi od instrukcji do faktycznej transakcji.

Shufti Know Your Agent dodaje właścicielstwo i mandaty do weryfikacji agentów

Wprowadzenie weryfikacji agentów przez Shufti opisuje usługę łączącą tożsamość agenta, ludzką autoryzację i kontrole uprawnień. Firma twierdzi, że łączy agentów z osobami lub firmami za pomocą istniejących procesów weryfikacji klientów i przedsiębiorstw. Właściciele określają dozwolone działania, limity, termin wygaśnięcia i odwołanie, czyli wycofanie wcześniej przyznanych uprawnień. Shufti twierdzi, że mandaty te mają zastosowanie do każdego żądania.

Ogłoszona zmiana polega na połączeniu zidentyfikowanego właściciela z ograniczonym działaniem, a nie wyłącznie na weryfikacji tożsamości.

To rozróżnienie ma znaczenie, ponieważ firma otrzymuje żądanie, a nie całą rozmowę, która je wywołała. Klient może poprosić asystenta o uporządkowanie dokumentacji finansowej. Taka instrukcja nie musi jednak upoważniać do przelewu pieniędzy, zmiany danych konta czy udostępnienia dokumentów innej usłudze. System odbierający potrzebuje egzekwowalnej interpretacji tego, co klient faktycznie delegował.

Shufti informuje, że agenci otrzymują wygasające poświadczenia, które firmy mogą odwołać. Jego relacja z 30 października dotycząca autoryzacji agentów opisuje również rejestry łączące żądania, decyzje i cofnięte uprawnienia z agentami oraz właścicielami. Nadal są to deklarowane możliwości produktu. Materiał nie potwierdza niezależnie wyników dotyczących ograniczania oszustw, niezawodności operacyjnej ani adopcji przez klientów.

Wprowadzenie produktu zmienia więc dostępną propozycję produktową, nie przesądzając o jej skuteczności. Firmy mogą ocenić usługę wyraźnie zorganizowaną wokół delegowanych uprawnień agentów. Nadal potrzebują dowodów, że jej decyzje odpowiadają ich własnym regułom transakcyjnym. Wynik weryfikacji jest użyteczny tylko wtedy, gdy aplikacja go otrzymująca dokładnie rozumie, na co ten wynik zezwala.

Istnieje też istotna różnica między rozpoznaniem oprogramowania a rozpoznaniem jego bieżących uprawnień. Asystent może pozostać tym samym rozpoznawalnym produktem, pracując jednocześnie dla różnych klientów. Ten sam klient może zlecać odrębne zadania z różnymi ograniczeniami. Firma nie może wnioskować o uprawnieniu wyłącznie na podstawie marki asystenta, jego wcześniejszego zachowania ani faktu pomyślnego uwierzytelnienia.

Token dostępu, czyli poświadczenie przedstawiane w celu uzyskania dostępu, może zawierać ograniczone uprawnienia, gdy zostanie prawidłowo wdrożony. Argument Shufti należy zatem rozumieć jako krytykę niewystarczającego projektowania autoryzacji, a nie jako dowód, że tokeny z natury nie mają granic. Praktyczne pytanie brzmi, czy uprawnienia reprezentowane przez poświadczenia odpowiadają konkretnemu działaniu biznesowemu.

Takie ujęcie utrzymuje ogłoszenie w realistycznych ramach. Shufti oferuje kolejny sposób łączenia tożsamości i delegowanych uprawnień. Nabywcy powinni oceniać to powiązanie przez pryzmat tego, co egzekwują systemy odbierające, w tym tego, co dzieje się, gdy skądinąd legalny agent żąda czegoś, czego jego właściciel nigdy nie zatwierdził.

Firmy odbierające żądania dziedziczą problem uprawnień

Bezpośrednia presja spada na organizacje przyjmujące żądania od agentów kontrolowanych przez klientów. Banki, platformy handlowe i dostawcy oprogramowania biznesowego muszą zdecydować, które zautomatyzowane działania mieszczą się w zwykłych procesach. Potrzebują też możliwej do obrony odpowiedzi, gdy klient kwestionuje dane działanie. Akceptacja automatyzacji rozszerza zakres podmiotów, które muszą obsłużyć istniejące mechanizmy kontroli kont.

Firma akceptująca aktywność agentów potrzebuje wyraźnej granicy między intencją klienta a swobodą działania oprogramowania.

Rozważmy hipotetycznego asystenta zakupowego, któremu polecono wymienić urządzenie biurowe. Klient zezwala na określoną kategorię produktu i lokalizację dostawy. Podczas finalizacji zakupu asystent napotyka niedostępny produkt i wybiera alternatywę. Sprzedawca staje wtedy przed decyzją biznesową: czy taka zamiana nadal mieści się w uprawnieniach klienta?

Instrukcja typu „znajdź coś odpowiedniego” pozostawia pole do oceny. System transakcyjny potrzebuje bardziej wyraźnych warunków. Ograniczenia dotyczące produktów, dane odbiorcy, limity zakupów i wymogi zatwierdzenia określają, czy działanie powinno zostać wykonane. Jeśli warunki te pozostają ukryte w rozmowie z agentem, sprzedawca nie może ich niezawodnie stosować.

Powoduje to pracę w kilku zespołach. Menedżerowie produktu muszą określić, które działania agenci mogą wykonywać bez przerwy. Zespoły bezpieczeństwa muszą zapewnić, że aplikacje egzekwują te definicje. Obsługa klienta potrzebuje zapisów wyjaśniających prostym językiem, co się wydarzyło. Właściciele biznesowi muszą zdecydować, które wyjątki wymagają ponownego zatwierdzenia.

Programiści stoją przed pokrewnym problemem integracyjnym. Interfejs programowania aplikacji, czyli interfejs oprogramowania używany do wymiany żądań, często udostępnia działania oddzielnie. Odczytanie rekordu, jego edycja, eksport i usunięcie mogą wymagać różnych uprawnień. Ogólne pozwolenie na „korzystanie z konta” nie wyjaśnia, jaką kombinację działań klient miał na myśli.

Trudność staje się wyraźniejsza, gdy agent zmienia kierunek w trakcie zadania. Klient może zatwierdzić badanie dostawców, ale oczekiwać osobnej decyzji przed złożeniem zamówienia. Asystent dążący do ukończenia zadania może potraktować zamówienie jako naturalny kolejny krok. Firma odbierająca żądanie potrzebuje mechanizmu kontroli, który rozpozna to przejście.

Taka kontrola wpływa także na doświadczenie klienta. Wymaganie zatwierdzenia dla każdej nieszkodliwej operacji czyni delegowanie niewygodnym. Zezwolenie na szerokie uprawnienia usuwa okazje do wychwycenia istotnych błędów. Firma musi wybrać, w którym miejscu przerwanie procesu zapewnia ochronę wystarczającą, by uzasadnić koszt uwagi i czasu realizacji.

Dlatego ogłoszenie Shufti wykracza poza zespoły tożsamości. Propozycja produktu zależy od zasad odzwierciedlających rzeczywiste decyzje biznesowe. Weryfikacja może identyfikować zaangażowane strony, lecz organizacja nadal musi określić, które działania wymagają zgody. Bez tej pracy zweryfikowany właściciel zostaje po prostu przypisany do zbyt szerokiego przyznania uprawnień.

Wynikająca z tego presja ma charakter organizacyjny równie mocno jak techniczny. Firmy potrzebują porozumienia co do tego, kto tworzy reguły uprawnień, kto zatwierdza zmiany i kto obsługuje wyjątki. Produkt bezpieczeństwa agentów nie może samodzielnie rozwiązać sprzecznych oczekiwań dotyczących wygody, kontroli klienta i ryzyka operacyjnego.

Konkurencja dotyczy miejsca egzekwowania uprawnień

Dokumentacja Microsoft opisuje zarządzanie tożsamościami agentów z uwzględnieniem własności, sponsorowania, uprawnień i rejestrów aktywności. Daje administratorom sposób na kontrolę agentów i zarządzanie ich dostępem. Ogłoszenie Shufti koncentruje się na firmach weryfikujących agentów działających w imieniu osób fizycznych lub organizacji. Porównanie dotyczy tego, gdzie każdy system ustanawia zaufanie i stosuje kontrolę.

Główny podział przebiega między rozpoznaniem legalnego agenta a egzekwowaniem granic jego konkretnego zadania.

Funkcje te mogą się wzajemnie uzupełniać. Organizacja może centralnie zarządzać tożsamością agenta pracownika, podczas gdy inna firma ocenia żądanie zakupu składane przez tego agenta. System wewnętrzny ustanawia odpowiedzialność organizacyjną. System odbierający nadal musi zdecydować, czy żądany zakup mieści się w przedstawionych uprawnieniach.

Żadna ze stron nie powinna zakładać, że druga odpowiedziała na wszystkie pytania. Wewnętrzna zgoda na obsługę agenta nie upoważnia automatycznie do każdej zewnętrznej transakcji. Zewnętrzna weryfikacja pracownika nie dowodzi, że pracownik może zobowiązać organizację. Każdy system odbierający potrzebuje dowodów istotnych dla własnej decyzji.

To rozróżnienie zniechęca do uproszczonego porównywania dostawców. Produkt skoncentrowany na katalogu i usługa weryfikacji klientów nie muszą się wzajemnie zastępować. Ich wartość zależy od środowiska, zaangażowanych relacji tożsamościowych i już wdrożonych mechanizmów kontroli. Same nazwy produktów nie mogą potwierdzić równoważnego zakresu ochrony.

Shufti Know Your Agent wchodzi na ten rynek z naciskiem na delegowane działania klientów. Jego wyróżnik będzie zależeć od tego, jak skutecznie firmy będą mogły przełożyć te mandaty na egzekwowalne zachowanie aplikacji. Decyzja dotycząca uprawnień, która pozostaje odłączona od wykonania, zapewnia ograniczoną ochronę. Aplikacja musi faktycznie odrzucać operacje wykraczające poza zatwierdzony zakres.

Szersza zasada bezpieczeństwa poprzedza to ogłoszenie. Wytyczne OWASP dotyczące nadmiernej sprawczości wskazują zagrożenia wynikające z nadmiernej funkcjonalności, uprawnień i autonomii. Zalecają egzekwowanie autoryzacji w systemach niższego szczebla zamiast polegania na ocenie modelu językowego. Model językowy generuje odpowiedzi na podstawie wyuczonych wzorców i kontekstu, co czyni jego wynik nieodpowiednim jako jedyną granicę uprawnień.

W tej historii wytyczne te stanowią niezależny punkt odniesienia, a nie poparcie dla Shufti. Istotne pytanie brzmi, czy oddzielna kontrola może zatrzymać nieautoryzowane działanie pomimo dążenia agenta do jego ukończenia. Tożsamość i polityka muszą pozostać skuteczne nawet wtedy, gdy agent błędnie rozumie swoje zadanie.

Wyobraźmy sobie hipotetycznego asystenta biznesowego, który może przygotować wiadomość do dostawcy, lecz nie może jej wysłać. To rozróżnienie przetrwa tylko wtedy, gdy usługa wiadomości je egzekwuje. Prośba, by asystent pamiętał o ograniczeniu, pozostawia ostateczną decyzję w tym samym systemie, który popełnia błąd. Usługa odbierająca, która odrzuca wysłanie wiadomości, ustanawia silniejszą granicę.

To jest test konkurencyjny stojący za ogłoszeniem. Dostawcy mogą różnie opisywać agentów, właścicieli i przepływy zatwierdzeń. Nabywcy muszą ustalić, gdzie zachodzi decydująca kontrola uprawnień. Najistotniejszą możliwością jest kontrola nad wykonaniem, gdy ważna tożsamość przedstawia nieważne żądanie.

Kontrole ludzkie wymieniają nieprzerwaną automatyzację na dodatkową kontrolę

Shufti opisuje dodatkową weryfikację z udziałem człowieka, gdy żądania wykraczają poza zakres upoważnienia lub przekraczają próg ryzyka. Według firmy proces ten może obejmować kontrolę „liveness” na podstawie selfie, oceniającą, czy obecna jest żywa osoba. Dodaje to punkt decyzyjny wymagający udziału człowieka do skądinąd zautomatyzowanego procesu. Jego użyteczność zależy od tego, co dana osoba ma faktycznie zatwierdzić.

Potwierdzenie obecności osoby i potwierdzenie świadomej zgody rozwiązują różne problemy.

Osoba może przejść kontrolę tożsamości, nie rozumiejąc proponowanej transakcji. Ekran zatwierdzenia, który mówi jedynie „kontynuuj”, przekazuje mniej informacji niż taki, który wskazuje odbiorcę, działanie i konsekwencje. Wartość dla bezpieczeństwa zależy częściowo od tego, czy interfejs czyni decyzję zrozumiałą. Sama obecność nie może uzupełnić brakującego kontekstu.

To ograniczenie analityczne, a nie dowód, że implementacja Shufti zawodzi. Ogłoszenie opisuje mechanizm eskalacji, ale nie ustala niezależnie, jak klienci interpretują ekrany zatwierdzania. Nabywcy muszą sprawdzić rzeczywiste doświadczenie użytkownika. Powinni odróżniać udaną weryfikację tożsamości od jasno zakomunikowanej decyzji autoryzacyjnej.

Hipotetyczna płatność ilustruje tę różnicę. Agent zaczyna z uprawnieniem do opłacenia stałego dostawcy, a następnie otrzymuje instrukcje użycia innego odbiorcy. Dodatkowa kontrola tworzy okazję do zatrzymania tej zmiany. Osoba musi jednak zobaczyć, że odbiorca się zmienił, zamiast jedynie ponownie zostać poproszona o potwierdzenie tożsamości.

Zatwierdzenie musi również pozostawać powiązane z ostatecznie wykonywanym działaniem. Jeśli później zmienią się istotne szczegóły transakcji, wcześniejsza decyzja może już nie opisywać tego, co się wydarzy. To kwestia projektowa dla aplikacji odbierającej i jej integracji z weryfikacją. Zatwierdzone żądanie i wykonane żądanie muszą mieć zgodne granice.

Przerwanie procesu wprowadza także wybory operacyjne. Agent może działać, gdy jego właściciel jest niedostępny. Gdy zatwierdzenie staje się konieczne, system potrzebuje zdefiniowanego rezultatu: wstrzymania, odrzucenia lub zachowania wersji roboczej. Ciche rozszerzanie uprawnień, aby kontynuować zadanie, podważyłoby cel kontroli.

Uwagę zasługują także dostępność i odzyskiwanie dostępu. Uprawniony klient może nie być w stanie ukończyć oczekiwanej metody weryfikacji. Firma potrzebuje alternatywy, która zachowuje wymagany poziom pewności. W przeciwnym razie mechanizm zaprojektowany, by wspierać autoryzowaną automatyzację, może stać się przeszkodą dla klientów mających ważne uprawnienia.

To samo napięcie pojawia się w zwykłej pracy z wiedzą. Znajdowanie informacji, przygotowanie odpowiedzi, jej wysłanie i zmiana współdzielonego rekordu oznaczają różne poziomy konsekwencji. Zespoły budujące przeszukiwalną bazę wiedzy stają przed podobną granicą między pozyskiwaniem materiału a autoryzowaniem kolejnego działania. Dostęp do użytecznego kontekstu sam w sobie nie daje zgody na jego publikację ani modyfikację.

Kompromis jest więc konkretny. Dodatkowa weryfikacja może przywrócić ludzką kontrolę w istotnych momentach, jednocześnie przerywając delegowanie zadań. Firmy potrzebują progów odzwierciedlających ryzyko transakcji i oczekiwania użytkowników. Traktowanie każdego przerwania jako sukcesu bezpieczeństwa pomijałoby pytanie, czy osoba otrzymała wystarczające informacje, by podjąć znaczącą decyzję.

Twierdzenia z ogłoszenia pozostawiają otwarte kwestie skuteczności i odpowiedzialności

Według stanu na 2 listopada przeanalizowane źródła potwierdzają ogłoszenie i deklarowany projekt rozwiązania. Nie przedstawiają jednak niezależnej oceny kompletnej usługi. To rozróżnienie ma znaczenie, gdy produkt łączy kontrole tożsamości, reguły uprawnień i zabezpieczenia transakcji. Pomyślne działanie komponentu nie dowodzi skuteczności całego procesu.

Luka weryfikacyjna dotyczy tego, czy kompletny system wymusza właściwą decyzję w realistycznych warunkach awarii.

Użyteczna ocena powinna analizować zarówno nieautoryzowane żądania, jak i legalne działania. Zablokowanie atakującego ma znaczenie, ale równie ważne jest umożliwienie klientowi zakończenia dozwolonego zadania. Jeśli system zbyt często odrzuca zwykłą pracę, firmy będą pod presją, by złagodzić jego zasady. Bezpieczeństwo i użyteczność należy mierzyć łącznie.

Publiczne ogłoszenie nie ustala, jak szybko cofnięte uprawnienia zatrzymują aktywność w połączonych aplikacjach. To istotne pytanie implementacyjne. Agent może mieć żądania oczekujące na wykonanie, gdy jego właściciel anuluje zgodę. Nabywcy muszą zrozumieć, czy te żądania przechodzą kolejną kontrolę przed zakończeniem.

Łańcuchy zadań tworzą kolejną nierozstrzygniętą kwestię. Asystent może poprosić inną usługę lub agenta o wykonanie części zadania. Firma odbierająca musi wtedy ustalić, czy pierwotne uprawnienie obejmuje takie delegowanie. Bez wyraźnych ograniczeń jasne początkowe upoważnienie może stać się niejednoznaczne w dalszej części procesu.

Rozpoznawanie zachowań rodzi odrębne pytania dotyczące oceny. Oprogramowanie może zmienić zachowanie po aktualizacji lub napotkać nieznane zadanie. Nabywcy powinni pytać, jak system odróżnia uzasadnioną zmienność od podejrzanej aktywności. Przeanalizowane materiały premierowe nie ustalają niezależnie zmierzonej dokładności w takich warunkach.

Tych pytań nie należy przedstawiać jako wykrytych podatności. Wskazują one dowody potrzebne do oceny twierdzeń firmy. Żadne z przeanalizowanych źródeł nie pokazuje, że usługa Shufti nie przechodzi tych testów. Równocześnie samo ogłoszenie nie dowodzi, że przechodzi je w środowisku produkcyjnym.

Odpowiedzialność wymaga podobnej ostrożności. Rejestr wiążący agenta z właścicielem może pomóc śledczym odtworzyć sekwencję zdarzeń. Nie rozstrzyga automatycznie, czy właściciel rozumiał żądanie, czy dane uwierzytelniające zostały przejęte ani czy aplikacja wykonała działanie poprawnie. Są to nadal odrębne kwestie faktyczne.

Rejestry stają się bardziej użyteczne, gdy zachowują kontekst decyzji. Śledczy muszą wiedzieć, jakie uprawnienia obowiązywały po nadejściu żądania i jakie działanie ostatecznie nastąpiło. Bieżące ustawienie konta nie musi wyjaśniać wcześniejszej transakcji. Dowody powinny pozwolić osobom dokonującym przeglądu odróżniać późniejsze zmiany konfiguracji od uprawnień istniejących wcześniej.

Krajowe działania na rzecz standardów wzmacniają znaczenie tych nierozstrzygniętych pytań. We wrześniu projekt NIST dotyczący tożsamości agentów opisał tworzenie oprogramowania jako pierwszy przypadek zastosowania wdrożeniowego po uzyskaniu opinii interesariuszy. Praca ta zapewnia szerszy kontekst do oceny tożsamości i autoryzacji. Nie certyfikuje produktu Shufti ani nie rozstrzyga skuteczności żadnego komercyjnego podejścia.

Dla nabywców wniosek jest prosty. Traktujcie premierę jako konkretną propozycję produktu z twierdzeniami, które można testować. Wymagajcie dowodów dotyczących granic istotnych dla zamierzonego wdrożenia. Szerokie zapewnienia o zaufanych agentach powinny ustąpić konkretnym odpowiedziom o dozwolonych działaniach, warunkach odmowy i odtwarzaniu incydentów.

Obserwuj dowody integracji, niezależne testy i przenośność uprawnień

Kolejne użyteczne sygnały powinny pokazać, jak propozycja działa poza materiałami premierowymi. W nadchodzących miesiącach uwagę zasługują — w tej kolejności — dowody integracji, niezależne testy i przenośność uprawnień. Przenośność uprawnień oznacza zachowanie zrozumiałych granic upoważnień między różnymi usługami. Każdy sygnał testuje inną część ogłoszonego podejścia.

Postęp należy oceniać na podstawie obserwowalnej kontroli nad działaniami agentów, a nie liczby ogłoszonych możliwości.

Po pierwsze, warto obserwować udokumentowane wdrożenia wyjaśniające, w jaki sposób aplikacja odbierająca egzekwuje upoważnienie. Przydatny opis wskazywałby dozwolone zadanie, zakazaną zmianę oraz reakcję, gdy agent przekroczy tę granicę. Nazwy klientów bez szczegółów operacyjnych ustalałyby mniej. Konkretne dowody integracji wzmacniałyby argument za praktycznym wdrożeniem.

Takie dowody powinny obejmować wyjątki, a nie tylko udane transakcje. Wdrożenie staje się bardziej informacyjne, gdy wyjaśnia, co dzieje się podczas anulowania, nieudanej weryfikacji lub niedostępności właściciela. Takie sytuacje pokazują, czy proces zachowuje swój model uprawnień pod presją. Opis ograniczony do pomyślnego ukończenia pozostawia te pytania bez odpowiedzi.

Po drugie, warto obserwować niezależne testy kompletnego procesu autoryzacji. Najbardziej użyteczne wyniki analizowałyby podszywanie się, przejęte dane uwierzytelniające, zmienione szczegóły transakcji i cofnięte uprawnienia. Testy powinny również obejmować legalną aktywność, którą system omyłkowo przerywa. Dowody z obu kategorii ułatwiłyby ocenę skuteczności.

Niezależne testy zwiększyłyby zaufanie, gdyby pokazały, że mechanizmy kontroli działają w realistycznych granicach aplikacji. Wąskie demonstracje wspierałyby węższe wnioski. Wyniki powinny wskazywać, co testowano, a co pozostało poza zakresem. Nabywcy powinni unikać rozszerzania dowodów dotyczących kontroli tożsamości na niepoparte twierdzenia o każdej dalszej transakcji.

Po trzecie, warto obserwować, jak Shufti i inni dostawcy tożsamości obsługują uprawnienia ponad granicami organizacyjnymi. Autoryzacja właściciela musi mieć znaczenie, które firma odbierająca potrafi zinterpretować. Jeśli każda integracja wymaga niepowiązanych definicji, wdrożenie staje się trudniejsze do utrzymania. Jasne mapowania między uprawnieniami wspierałyby bardziej spójne egzekwowanie zasad.

Przenośność również potrzebuje ograniczeń. Uprawnienie akceptowane przez sprzedawcę nie powinno po cichu stać się upoważnieniem wobec niepowiązanych systemów biznesowych. Interoperacyjność jest cenna, gdy zachowuje ograniczenia razem z tożsamością. Dowody, że uprawnienia pozostają ograniczone podczas przekazywania między systemami, wzmocniłyby centralną tezę ogłoszenia.

Shufti Know Your Agent daje nabywcom konkretną propozycję do oceny: połączyć agenta, jego właściciela i dozwolone działania. Kolejna decyzja dotyczy tego, czy to połączenie przetrwa rzeczywiste procesy pracy. Poproście o demonstrację z wykorzystaniem zadania, które wasza organizacja faktycznie deleguje, w tym żądania przekraczającego uprawnienie oraz anulowania podczas wykonania. Sprawdźcie, co aplikacja blokuje, co widzi osoba i co wyjaśniają później rejestry. Utrzymujcie ocenę przy konkretnej granicy biznesowej, takiej jak przygotowanie wersji roboczej versus wysłanie albo badanie versus zakup. Przed rozszerzeniem dostępu agentów: czy wasz zespół potrafi wskazać dokładnie, gdzie ta granica jest egzekwowana, i pokazać, że pozostaje skuteczna, gdy zadanie się zmienia?