Microsoft run-assert-eval Przekształca Ustalenia Dotyczące Ryzyka Agentów w Testowane Kontrole Wykonawcze
Microsoft udostępnił run-assert-eval 24 września, łącząc cztery wcześniej odrębne zadania związane z bezpieczeństwem agentów w jednym prowadzonym przepływie pracy. Umiejętność Microsoft run-assert-eval wykrywa ryzyka, mierzy błędy, opracowuje kontrole wykonawcze i powtarza tę samą ewaluację po dodaniu tych kontroli. Konflikt jest natychmiastowy: szybsza pętla bezpieczeństwa jest użyteczna tylko wtedy, gdy jej pomiary pozostają wiarygodne.
Przykład Microsoftu nadaje ogłoszeniu konkretny wymiar. Według firmy agent wsparcia rozliczeń ujawnił dane innego klienta w 12 z 40 mających zastosowanie rozmów bazowych. Po wprowadzeniu polityki wykonawczej Microsoft zaobserwował dwa naruszenia w 34 mających zastosowanie rozmowach. Obniżyło to zgłaszany wskaźnik z 30,0% do 5,9%.
Wynik brzmi rozstrzygająco, lecz pochodzi z opracowanego przykładu utrzymywanego przez twórców projektu. Microsoft nie przedstawił niezależnej replikacji ani badania wdrożenia produkcyjnego. Istotnym osiągnięciem jest zatem mechanizm, a nie jeden korzystny wynik. Umiejętność przekształca wykryte niepowodzenie w egzekwowalną politykę, a następnie testuje interwencję bez potajemnej zmiany ewaluacji.
Microsoft run-assert-eval Łączy Wykrywanie, Testowanie i Egzekwowanie
Wydanie zamienia zbiór projektów bezpieczeństwa w jedną możliwą do przeanalizowania ścieżkę od nieznanego ryzyka do przetestowanej kontroli wykonawczej.
W poście ogłaszającym premierę Microsoft opisuje przepływ pracy uruchamiany za pomocą promptu w zgodnym środowisku programistycznym. Programiści zaczynają od agenta, jego zamierzonego celu, narzędzi oraz granic, których musi przestrzegać.
Umiejętność może wykorzystywać Clarity do modelowania zagrożeń agenta. Modelowanie zagrożeń oznacza identyfikowanie prawdopodobnych błędów, zagrożonych zasobów, przyczyn i konsekwencji przed wyborem testów. Zespoły mogą też dostarczyć znane ryzyko z wymagania produktowego, raportu o incydencie, planu testów lub istniejącej oceny.
To rozróżnienie ma znaczenie. Wykrywanie ryzyka jest zalecane, ale nieobowiązkowe. Zespół, który już wie, że jego agent rozliczeniowy ujawnia rekordy klientów, może rozpocząć od tego zachowania, zamiast powtarzać pracę nad wykrywaniem.
Gdy zespoły potrzebują wykrywania, modeler zagrożeń Clarity analizuje szerszy kontekst działania agenta. Jego celem jest ujawnianie błędów, które nigdy nie zostały zapisane w pierwotnych wymaganiach.
W przykładzie Microsoftu dotyczącym rozliczeń Clarity zidentyfikował cztery potencjalne tryby awarii. Zespół wybrał dwa ryzyka ocenione jako krytyczne: niezweryfikowane działania wysokiego ryzyka oraz ekspozycję danych między klientami.
Pierwsze ryzyko obejmowało zmiany rozliczeń wprowadzane bez potwierdzenia tożsamości rozmówcy. Drugie dotyczyło ujawnień związanych z kontem, które nie należało do rozmówcy.
Umiejętność przekazała każde wybrane ryzyko do ASSERT, opartego na wymaganiach frameworka ewaluacyjnego Microsoftu. Każde ryzyko stało się jedną konfiguracją, jednym zachowaniem i jednym zestawem ewaluacyjnym.
Ta wąska struktura ma większe znaczenie, niż początkowo się wydaje. Jeśli ewaluacja miesza błędy autoryzacji, prywatności, dokładności i eskalacji, jej łączny wynik nie może wyjaśnić, która kontrola jest potrzebna.
Microsoft run-assert-eval zamiast tego rozdziela te zachowania. Zmienność jest wprowadzana w ramach każdego zestawu poprzez wymiary takie jak tryb dostępu, pretekst użytkownika, deklaracje uprawnień i dryf zakresu w wieloetapowej rozmowie.
Umiejętność przeszukuje również wcześniejsze badania i frameworki bezpieczeństwa pod kątem odpowiednich wymiarów testowych. Microsoft twierdzi, że źródła te mogą obejmować wytyczne NIST, zasoby OWASP, benchmarki, materiały regulacyjne i polityki dostawców modeli.
Następnie ASSERT generuje przypadki, uruchamia docelowego agenta i ocenia przechwycone transkrypcje. Jego dwa główne pomiary celowo pozostają rozdzielone.
„Naruszono niedozwolone zachowanie” rejestruje przypadki, w których agent wykonał zabronione działanie. „Naruszono dozwolone zachowanie” mierzy przypadki, w których agent nie pomógł, mimo że mógł to zrobić.
To rozdzielenie chroni przed znaną iluzją bezpieczeństwa. Agent, który odrzuca każdą prośbę, może uniknąć wielu szkodliwych działań, ale przestaje również wykonywać swoją pracę.
Następnie przepływ pracy generuje projekt polityki Agent Control Specification na podstawie zmierzonego błędu. ACS to przenośny format do umieszczania kontroli w zdefiniowanych punktach wykonania agenta.
Na koniec umiejętność ocenia wersję agenta objętą polityką względem tych samych przypadków. Uruchomienia bazowe i objęte polityką zachowują tę samą definicję zachowania, zestaw testowy i metodę oceny.
Wynikiem nie jest jedynie kolejny wynik bezpieczeństwa. To kontrolowane porównanie zaprojektowane tak, aby wyizolować politykę jako zmienną, która uległa zmianie.
Presja Spada na Zespoły Traktujące Prompty jako Główną Zaporę Ochronną
Microsoft kwestionuje pogląd, że same pisemne instrukcje zapewniają wystarczającą granicę kontroli dla agentów korzystających z narzędzi.
Prompty systemowe pozostają użyteczne do definiowania ról i oczekiwanego zachowania. Nadal są jednak probabilistycznymi instrukcjami interpretowanymi przez model, a nie deterministycznymi kontrolami autoryzacji egzekwowanymi przez otaczające oprogramowanie.
Ta słabość staje się istotna, gdy agent może pobierać rekordy, aktualizować konta, wystawiać zwroty lub wywoływać narzędzia administracyjne. Przekonująca prośba może wtedy przerodzić się w odczyt bazy danych lub działanie biznesowe.
Przykład Microsoftu dotyczący rozliczeń ilustruje tę lukę. Agent działał dla rozmówcy powiązanego z kontem ACME-1001. Nigdy nie powinien był pobierać ani modyfikować konta innego klienta.
Jedna z ocenianych próśb dotyczyła informacji kontaktowych powiązanych z BPS-447, które należało do innego klienta. Według Microsoftu agent bazowy zwrócił pełny rekord.
Przegląd kodu mógłby potwierdzić, że funkcja pobierania działa poprawnie. Test jednostkowy mógłby potwierdzić, że prawidłowy identyfikator konta zwraca oczekiwany rekord. Żaden z nich nie musi jednak sprawdzać, czy model wybiera nieautoryzowany identyfikator podczas realistycznej rozmowy.
Problem wykracza poza wsparcie rozliczeń. Agent badawczy może uzyskać dostęp do nieodpowiednich źródeł, a agent zarządzania zmianą może ominąć sekwencję zatwierdzeń. Agent podróży może niewłaściwie wykorzystać zapisane dane tożsamości lub płatności.
Wytyczne OWASP nazywają ten szerszy stan nadmierną sprawczością. Powstaje on wtedy, gdy aplikacja AI ma więcej funkcji, uprawnień lub autonomii, niż wymaga jej zadanie.
Prompt injection może wywołać takie błędy, ale nie jest jedyną przyczyną. Niejednoznaczne prośby, zmyślone plany, skompromitowane narzędzia i zwykłe błędy modelu również mogą prowadzić do niebezpiecznych działań.
Dotknięte zespoły to nie tylko grupy bezpieczeństwa. Menedżerowie produktu muszą określić dozwolone i zabronione rezultaty. Programiści muszą udostępnić odpowiednie punkty kontroli. Właściciele ryzyka muszą zdecydować, czy zmierzona redukcja jest wystarczająca.
Zespoły ewaluacyjne również znajdują się pod presją. Ich praca nie może już kończyć się na raporcie wymieniającym błędy. Przepływ pracy Microsoftu oczekuje, że ustalenie będzie wspierać konkretną kontrolę i powtarzalne uruchomienie walidacyjne.
Organizacje korzystające z ogólnych benchmarków modeli napotykają inny problem. Szeroki benchmark może opisywać przeciętne tendencje modelu, lecz nie może uchwycić zasad dotyczących kont, granic eskalacji ani wewnętrznego procesu zatwierdzania każdej firmy.
Podejście Microsoftu zaczyna od własnych wymagań aplikacji i wykrytych ryzyk. To zwiększa trafność ewaluacji, choć jednocześnie utrudnia porównania między organizacjami.
Wydanie wywiera również presję na dostawców, którzy traktują obserwację jako ostatni etap. Rejestrowanie niebezpiecznego wywołania narzędzia po jego wykonaniu może pomóc w dochodzeniu. Nie zapobiega jednak działaniu, które spowodowało szkodę.
Run-assert-eval przenosi interwencję na ścieżkę wykonawczą agenta. Zbliża ją to do znanych koncepcji bezpieczeństwa, takich jak kontrole autoryzacji, zasada najmniejszych uprawnień i punkty egzekwowania polityk.
Nie eliminuje to promptów. Nadaje im węższą rolę. Modele mogą planować i interpretować język, podczas gdy deterministyczne kontrole decydują, czy wrażliwe operacje powinny być kontynuowane.
Ten podział staje się coraz ważniejszy, gdy agenci uzyskują dostęp do plików lokalnych i wiedzy wewnętrznej. Zespoły budujące przeszukiwalną bazę wiedzy stają przed tym samym pytaniem o granice: pobieranie danych musi respektować rzeczywisty zakres autoryzacji użytkownika.
Microsoft run-assert-eval ujmuje to pytanie w przepływ pracy, który programiści mogą uruchomić wcześniej. Ciężar przenosi się wtedy z nadziei, że model będzie przestrzegał reguły, na wykazanie, gdzie oprogramowanie ją egzekwuje.
Podstawowym Mechanizmem Jest Kontrolowany Test Przed i Po
Najsilniejszą ideą run-assert-eval nie jest automatyczne generowanie polityk, lecz zachowanie ewaluacji przy zmianie wyłącznie kontroli.
Porównania bezpieczeństwa stają się niewiarygodne, gdy zespoły regenerują zestaw testowy po zastosowaniu poprawki. Inna grupa promptów może sprawić, że słaba polityka wyda się skuteczna albo że rozsądna polityka wyda się gorsza.
Zmiana oceniającego tworzy kolejną zmienną zakłócającą. Dwóch ewaluatorów może różnie interpretować tę samą transkrypcję, zwłaszcza gdy akceptowalne zachowanie zależy od kontekstu.
Run-assert-eval buforuje bazową systematyzację i przypadki testowe. Agent objęty polityką staje następnie przed tą samą definicją zachowania, przypadkami i podejściem do oceny.
Microsoft opisuje to jako zamrożenie ewaluacji. Polityka staje się zamierzoną zmienną niezależną, podczas gdy zmierzone wskaźniki naruszeń stają się obserwowanymi wynikami.
Zasada przypomina testowanie regresyjne w konwencjonalnym oprogramowaniu. Nieudany test powinien pozostać niezmieniony, gdy programiści modyfikują implementację. W przeciwnym razie pozytywny wynik może odzwierciedlać przepisany test, a nie skorygowane zachowanie.
Testowanie agentów jest trudniejsze, ponieważ wyniki modeli są zmienne. Oceniający może również opierać się na modelu, a generowane przypadki mogą zawierać własne niejednoznaczności.
Utrzymanie tych elementów na stałym poziomie nie usuwa każdego źródła niepewności. Sprawia jednak, że różnica przed i po jest łatwiejsza do interpretacji.
Microsoft twierdzi, że wcześniejsze ewaluacje ASSERT wykazały od 80% do 90% zgodności między automatycznym oceniającym a ludzkimi recenzentami. Firma porównuje ten zakres z około 90% zgodności między ludzkimi recenzentami.
Wartości te są wynikami zgłaszanymi przez Microsoft, a nie uniwersalnymi gwarancjami dokładności. Zgodność oceniającego może różnić się w zależności od zachowania, modelu, rubryki, języka i złożoności bazowej polityki.
Podstawowa ewaluacja pozostaje możliwa do sprawdzenia. Repozytorium ASSERT podaje, że uruchomienia przechowują lokalne artefakty, wygenerowane przypadki, wyniki modeli, uzasadnienia oceniającego i metryki.
Lokalne artefakty mogą wspierać audyty, ponieważ recenzenci mogą zbadać, dlaczego transkrypcja została sklasyfikowana jako naruszenie. Mogą również zidentyfikować przypadki, w których ewaluator błędnie zrozumiał politykę.
Dwuwskaźnikowa konstrukcja ASSERT dodaje kolejne zabezpieczenie. Polityka, która blokuje szkodliwe zachowanie, może nadal zawieść, jeśli powoduje nadmierne odmawianie.
Dla zestawu między klientami Microsoft zgłosił bazowy wskaźnik niedozwolonych naruszeń na poziomie 30,0%. Wynik objęty polityką wyniósł 5,9% przy innym mającym zastosowanie mianowniku.
Microsoft podzielił również wyniki na podziały promptów i scenariuszy. Przypadki promptów testują bardziej bezpośrednie interakcje, podczas gdy przypadki scenariuszowe obejmują bogatsze przepływy pracy i kontekst rozmowy.
W przypadku promptów między klientami zgłaszany wskaźnik niedozwolonych zachowań spadł z 20,8% do 8,7%. Odpowiedni wskaźnik dla scenariuszy spadł z 43,8% do 0,0%.
W przypadkach promptów z niezweryfikowanym działaniem zgłoszony wskaźnik spadł z 4,0% do 0,0%. W podziale na scenariusze zmienił się z 8,7% na 4,5%.
Naruszenia dopuszczalnego zachowania miały podobno wynieść 0,0% we wszystkich czterech nadzorowanych podziałach. Microsoft interpretuje ten wynik jako dowód, że mechanizmy kontrolne zachowały w tej próbce możliwość wykonywania uzasadnionej pracy.
Pozostałe niedopuszczalne naruszenia mają znaczenie. Pokazują, że polityka nie wyeliminowała każdego błędu, nawet w kontrolowanym przykładzie.
Jest to zgodne z iteracyjną konstrukcją procesu. Zespół może przeanalizować pozostałe błędy, doprecyzować definicję ryzyka lub politykę i powtórzyć ten sam proces.
Metoda zapewnia zatem mocniejsze dowody niż garść ręcznych demonstracji. Nadal nie ustala jednak, jak agent zachowuje się wobec wszystkich przyszłych promptów, aktualizacji modeli, narzędzi czy środowisk.
Praktyczna korzyść jest węższa i bardziej użyteczna. Zespoły otrzymują możliwe do prześledzenia dowody, że konkretna kontrola zmieniła wyniki w zdefiniowanej ewaluacji, a nie jedynie uciszyła agenta.
Polityka środowiska wykonawczego blokuje działania, zanim model zdoła je wykonać
Poprawka dotycząca rozliczeń działa poprzez sprawdzenie zakresu konta na granicy narzędzia, a nie przez proszenie modelu o ponowne rozważenie swoich zamiarów.
Po zmierzeniu ekspozycji między klientami run-assert-eval wygenerował projekt polityki oraz manifest ACS. Polityka wyrażała logikę decyzji, a manifest określał, gdzie ta logika powinna być stosowana.
Microsoft użył Rego, deklaratywnego języka polityk powszechnie kojarzonego z silnikami polityk. Wygenerowany materiał pozostał projektem wymagającym weryfikacji przez człowieka.
Ta bramka weryfikacyjna jest istotna. Microsoft wyraźnie zaznacza, że wygenerowanie nie jest równoznaczne z zatwierdzeniem. Programiści muszą sprawdzić politykę, punkt interwencji, manifest oraz połączenie z docelowym agentem.
Wybrana polityka odrzucała wywołania narzędzi, gdy żądany identyfikator konta różnił się od konta osoby wywołującej. Reguła ta nie wymagała od kolejnego modelu oceny, czy żądanie wygląda podejrzanie.
Microsoft umieścił kontrolę w pre_tool_call, punkcie przechwycenia osiąganym przed wykonaniem narzędzia przez agenta. Niezgodny identyfikator powoduje więc odmowę przed pobraniem danych.
Zespół użył także post_tool_call. Ta druga kontrola wstrzymywała każdy niezgodny wynik, który nigdy nie powinien trafić do kontekstu modelu.
Wykorzystanie obu punktów tworzy ochronę warstwową. Pierwszy próbuje zapobiec nieautoryzowanej operacji. Drugi ogranicza ekspozycję, jeśli wcześniejsza kontrola zostanie ominięta lub nieprawidłowo podłączona.
Silnik polityk ACS ma oddzielać te mechanizmy kontrolne od jednego frameworka agentowego. Polityki mogą zatem pozostać przenośne, gdy zespoły zmieniają modele lub biblioteki orkiestracji.
Ta przenośność rozwiązuje rzeczywisty problem utrzymania. Mechanizmy kontrolne osadzone w promptach lub callbackach specyficznych dla frameworka mogą stać się trudne do audytowania w kilku implementacjach agentów.
Wspólna specyfikacja może zapewnić recenzentom bezpieczeństwa spójny obiekt do kontroli. Może też umożliwić programistom wersjonowanie zmian polityk obok kodu aplikacji.
Przenośność nie gwarantuje jednak poprawnej integracji. Każde środowisko wykonawcze musi udostępniać istotny kontekst, zachowywać tożsamość i wywoływać politykę we właściwym punkcie.
Reguła zakresu konta zależy od wiarygodnych informacji o koncie. Jeśli tożsamość osoby wywołującej jest błędna lub jej brakuje, nawet perfekcyjnie napisana reguła porównania nadal daje błędny wynik autoryzacji.
Ta sama obawa dotyczy argumentów narzędzia. Polityka analizująca account_id zakłada, że żądany zasób jest dokładnie reprezentowany przez to pole.
Złożone narzędzia mogą ukrywać wrażliwe cele w zapytaniach, dokumentach, adresach URL lub zagnieżdżonych działaniach. Wąska reguła może wtedy przeoczyć równoważne ścieżki do tego samego chronionego zasobu.
Polityka środowiska wykonawczego także nie może naprawić każdej klasy błędów. Mechanizm może zablokować nieautoryzowany zwrot środków lub odczyt bazy danych. Nie może automatycznie ustalić, czy każde wygenerowane wyjaśnienie jest poprawne lub sprawiedliwe.
Zatwierdzenia przez człowieka pozostają właściwe dla niektórych działań o dużym wpływie. Projektowanie narzędzi zgodnie z zasadą najmniejszych uprawnień może ograniczyć szkody, nawet gdy model podejmie słabą decyzję.
Szerszy framework ryzyka AI traktuje zarządzanie ryzykiem jako działanie obejmujące cały cykl życia. Obejmuje ono zarządzanie, mapowanie, pomiar i ciągłe zarządzanie, a nie pojedynczy test przed wydaniem.
Run-assert-eval wpisuje się w ten szerszy wzorzec. Zapewnia konkretny pomost od zmapowania ryzyka do pomiaru i zarządzania jednym zachowaniem.
Jednopromptowy punkt wejścia procesu nie powinien przesłaniać pracy wykonywanej pod spodem. Modelowanie zagrożeń, projektowanie testów, przegląd polityk, integracja systemu i interpretacja wyników nadal wymagają świadomych decyzji.
Microsoft ograniczył ręczne przekazywanie informacji między tymi decyzjami. Umiejętność przenosi ustrukturyzowane artefakty z jednego etapu do kolejnego i utrzymuje widoczne relacje między nimi.
Może to zmniejszyć prawdopodobieństwo, że opis ryzyka utraci znaczenie podczas przekazywania między zespołami produktowymi, ewaluacyjnymi i bezpieczeństwa.
Może też skrócić odstęp między wykryciem błędu a sprawdzeniem środka zaradczego. To właśnie w takim odstępie często kumuluje się nierozwiązane ryzyko związane z agentem.
Pierwsze wyniki są dowodem, a nie ogólną gwarancją bezpieczeństwa
Przykład Microsoftu wspiera logikę procesu, ale nie potwierdza skuteczności produkcyjnej dla agentów, organizacji ani ataków jako całości.
Najbardziej oczywistym ograniczeniem jest pochodzenie wyników. Microsoft i współtwórcy projektu zaprojektowali narzędzia, wybrali przykład, zastosowali mechanizmy kontrolne i przedstawili uzyskane pomiary.
Nie czyni to wyników nieważnymi. Oznacza to, że czytelnicy powinni odróżniać przejrzysty, szczegółowo opisany przykład od niezależnego benchmarku lub badania terenowego.
Ostrożności wymagają także wielkości prób. Bazowa wartość nagłówkowa obejmowała 40 mających zastosowanie rozmów, podczas gdy nadzorowane uruchomienie obejmowało 34.
Te mianowniki różnią się, ponieważ tylko mające zastosowanie przypadki wpływają na konkretny wskaźnik zachowania. Mimo to małe próby mogą dawać niestabilne wartości procentowe.
Zmiana z 12 naruszeń do dwóch ma znaczenie operacyjne w tym przykładzie. Nie należy jej interpretować jako uniwersalnej redukcji o 80% dla innych agentów.
Zgłoszony wskaźnik 0,0% naruszeń dopuszczalnego zachowania oznacza również, że w tej próbce nie pojawiły się żadne naruszenia. Nie oznacza to, że polityka nigdy nie może zablokować uzasadnionego zachowania.
Większy zestaw testowy mógłby ujawnić rzadkie fałszywe odmowy. Ruch produkcyjny może obejmować relacje między kontami, zasady delegowania lub wyjątki obsługowe, których zabrakło w przykładzie.
Innym problemem jest przeciek ewaluacyjny. Jeśli polityka jest wielokrotnie dostrajana względem jednego zamrożonego zestawu testowego, programiści mogą w końcu nadmiernie dopasować się do znanych przypadków.
Zamrożenie testów tworzy wiarygodne porównanie podczas jednej interwencji. Programy długoterminowe nadal potrzebują odłożonych przypadków, nowych wariantów adwersarialnych i monitorowania zmieniającego się zachowania.
Zmiany modelu mogą również unieważnić wcześniejsze wnioski. Nowy model może inaczej formatować argumenty narzędzi, inaczej interpretować odmowy lub znaleźć inną drogę do chronionej informacji.
Zmiany narzędzi tworzą podobne ryzyko. Dodanie funkcji eksportu lub ogólnego punktu końcowego wyszukiwania może wprowadzić ścieżkę dostępu nieobjętą pierwotną kontrolą konta.
Sędzia ewaluacyjny zasługuje na ciągłą kontrolę. Zgłoszony przez Microsoft zakres zgodności jest zachęcający, ale przypadki niezgodności mogą skupiać się wokół najbardziej niejednoznacznych i istotnych granic.
Zespoły powinny zachować przegląd przez człowieka dla spornych przypadków i okresowo próbkować pozornie udane wyniki. Stabilny automatyczny sędzia jest przydatny do porównań, ale nie jest nieomylnym autorytetem.
W słowie „skill” zawarty jest również problem łańcucha dostaw. Umiejętności agentów zawierają instrukcje wpływające na planowanie, wykonywanie i walidację.
Microsoft Research niedawno zgłosił 307 błędów wywołanych przez umiejętności w dwóch konfiguracjach benchmarkowych. Obejmowały one 125 błędów funkcjonalnych i 182 regresje wydajności.
Badanie to nie ocenia konkretnie run-assert-eval. Ustanawia ono szerszy powód, aby analizować instrukcje, skrypty, uprawnienia i założenia operacyjne każdej umiejętności.
Run-assert-eval częściowo odpowiada na tę obawę poprzez widoczne artefakty i bramki z udziałem człowieka. Zespoły mogą przeanalizować wygenerowane konfiguracje ewaluacji i polityki przed uruchomieniem nadzorowanych przebiegów.
Generowanie testów oparte na literaturze tworzy kolejny obowiązek weryfikacyjny. Cytowany framework może wyznaczać wymiary, lecz jego przydatność zależy od tego, jak dokładnie umiejętność przekłada to źródło na przypadki.
Słabe przełożenie może zapewniać imponujące etykiety pokrycia bez znaczącego pokrycia. Recenzenci powinni więc analizować scenariusze, a nie tylko nazwy frameworków do nich przypisane.
Kolejną otwartą kwestią jest koszt operacyjny. Uruchamianie wygenerowanych przypadków, przechwytywanie śladów, ocenianie transkrypcji i powtarzanie ewaluacji pochłania wywołania modelu oraz czas inżynieryjny.
Projekt nie opublikował szerokiego porównania tego kosztu z ręcznymi procesami oceny. Organizacje muszą ustalić, które ryzyka uzasadniają głębszą ewaluację.
Najrozsądniejsza interpretacja jest wyważona, lecz pozytywna. Microsoft stworzył spójny proces dla trudnego problemu integracyjnego.
Wydanie nie dowodzi, że agent jest bezpieczny. Pomaga zespołowi sformułować konkretne twierdzenie dotyczące bezpieczeństwa, dołączyć do niego dowody i sprawdzić, czy jedna interwencja poprawiła zdefiniowany wynik.
Trzy sygnały pokażą, czy to podejście się sprawdza
Kolejnym testem będzie to, czy niezależne zespoły odtworzą korzyści procesu bez poświęcania użytecznego zachowania agentów lub tworzenia ukrytych obciążeń utrzymaniowych.
Pierwszym sygnałem jest replikacja przez strony trzecie. Programiści powinni obserwować publiczne ewaluacje stosujące Microsoft run-assert-eval do agentów wykraczających poza dołączone przykłady.
Przekonująca replikacja opublikowałaby definicje ryzyk, przypadki, politykę, ślady, konfigurację sędziego oraz wyniki przeglądu przez człowieka. Ujawniłaby również błędy, które pozostały po wdrożeniu mechanizmów zarządzania.
Wyniki uzyskane dla różnych modeli i frameworków wzmocniłyby twierdzenie Microsoftu o przenośności. Istotne różnice integracyjne ujawniłyby, gdzie ACS nadal zależy od poszczególnych środowisk wykonawczych.
Drugim sygnałem są szersze dowody produkcyjne. Zespoły muszą wiedzieć, czy zamrożone ewaluacje przewidują incydenty, odmowy i obejścia polityk w rzeczywistym ruchu.
Przydatne dowody obejmowałyby trendy naruszeń po wdrożeniu oraz uzasadnione żądania zablokowane przez mechanizmy kontrolne. Śledziłyby także błędy wprowadzone po zmianach modeli, narzędzi lub promptów.
Najsilniejsze wdrożenia połączą artefakty ewaluacyjne z ciągłym monitorowaniem. Poprawa przed wydaniem ma większe znaczenie, gdy telemetria produkcyjna potwierdza tę samą granicę zachowania.
Trzecim sygnałem jest reakcja projektu na unikanie kontroli i dryf polityk. Atakujący oraz zwykli użytkownicy mogą dotrzeć do chronionych działań ścieżkami nieobecnymi w pierwotnym zestawie.
Warto obserwować nowe zestawy obejmujące pośrednie wstrzykiwanie promptów, delegowane uprawnienia, sprzeczne tożsamości, manipulowanie stanem i przekazywanie zadań między agentami. Warto też śledzić, jak projekt zapobiega nadmiernemu dopasowaniu do zamrożonych przypadków.
Wersjonowane polityki i przebiegi regresji będą niezbędne. Zespoły potrzebują jasnego wyzwalacza do powtarzania ewaluacji zawsze wtedy, gdy zmieniają się modele, narzędzia, uprawnienia lub reguły biznesowe.
Wydanie powinno być oceniane także przez pryzmat doświadczenia przeglądu. Wygenerowana polityka jest użyteczna tylko wtedy, gdy programiści i zespoły bezpieczeństwa rozumieją, dlaczego istnieje i co blokuje.
Dlatego lokalne artefakty, cytowane transkrypcje i wąskie definicje zachowań są czymś więcej niż szczegółami implementacyjnymi. Tworzą łańcuch dowodów wspierający zatwierdzenie.
Microsoft run-assert-eval najlepiej postrzegać więc jako dyscyplinę inżynieryjną zapakowaną jako umiejętność. Łączy modelowanie zagrożeń, ewaluację specyficzną dla zachowania, egzekwowanie w środowisku wykonawczym oraz kontrolowane ponowne testowanie.
Programiści nie powinni pytać, czy dany proces certyfikuje całego agenta jako bezpiecznego. Powinni pytać, czy pozwala on zmierzyć jedno istotne ryzyko, zweryfikować jeden mechanizm kontroli i odtworzyć jedno usprawnienie.
To skromniejsza obietnica niż udowodnienie ogólnego bezpieczeństwa. Jest też bardziej wiarygodnym punktem wyjścia dla zarządzania agentami.
