Proof-of-Control od Advanced AI Society otwiera nowy front w bezpieczeństwie agentów

Advanced AI Society udostępniło Proof-of-Control do publicznych konsultacji 17 września, mimo nierozstrzygniętych pytań dotyczących wersji projektu, jego zakresu i gotowości. Proponowany standard wymaga od agentów AI tworzenia dowodów odpornych na manipulacje, wskazujących, że każde kontrolowane działanie pozostało w granicach przyznanych uprawnień. Przesuwa również bezpieczeństwo agentów poza poleganie na prywatnych logach dostawcy.

Ta zmiana ma znaczenie, ponieważ agenci wychodzą poza generowanie tekstu. Mogą wywoływać narzędzia, uzyskiwać dostęp do zapisów, zmieniać oprogramowanie, komunikować się z usługami zewnętrznymi i inicjować transakcje. Kwartalny audyt nie jest w stanie obserwować każdej decyzji w chwili jej podjęcia, a log kontrolowany przez operatora agenta może zapewniać ograniczone niezależne potwierdzenie.

Advanced AI Society twierdzi, że w kształtowaniu jego podejścia uczestniczyło ponad 80 liderów ds. bezpieczeństwa. Organizacja umieszcza projekt w Linux Foundation Decentralized Trust, co zapewnia mu neutralne środowisko zarządzania technicznego. Neutralne zarządzanie nie czyni jednak projektu kompletnym, podobnie jak dowody kryptograficzne nie gwarantują, że organizacja wybrała właściwe mechanizmy kontroli.

Kongres podchodzi do tego samego problemu z innej strony. Dwupartyjna propozycja Izby Reprezentantów nakazałaby NIST opracowanie praktyk bezpieczeństwa agentów obejmujących ciągłą weryfikację, ocenę bezpieczeństwa, rejestry zasobów i zapisy odporne na manipulacje. Zderzenie dobrowolnych otwartych standardów z wymogami wspieranymi przez rząd tworzy właściwą historię.

Proof-of-Control od Advanced AI Society to więcej niż ogłoszenie o członkostwie

Istotną zmianą jest publikacja możliwej do sprawdzenia propozycji weryfikacji agentów, a nie nagłówek dotyczący członkostwa, który jej towarzyszył.

Advanced AI Society opisało wrześniowe ogłoszenie jako dołączenie do Linux Foundation i LF Decentralized Trust. Dokumentacja Linux Foundation pokazuje jednak, że organizacja została członkiem stowarzyszonym LF Decentralized Trust 21 kwietnia 2026 r. Nowsze ogłoszenie łączy więc wcześniejszy rozwój związany z członkostwem z publiczną prezentacją Proof-of-Control oraz powiązanego z nim laboratorium.

To rozróżnienie ma znaczenie. Członkostwo umieszcza organizację w sieci współpracy, ale nie potwierdza zasadności każdego twierdzenia ani projektu technicznego, które organizacja publikuje. Kluczowym działaniem jest wniesienie proponowanego standardu weryfikacji do środowiska fundacji, w którym zewnętrzni współtwórcy mogą go analizować, kwestionować i rozwijać.

Kwietniowy rejestr członkostwa wskazuje Advanced AI Society jako jednego z dwóch nowych członków stowarzyszonych. Wrześniowy komunikat o uruchomieniu przedstawia Proof-of-Control jako laboratorium LF Decentralized Trust i zaprasza do publicznego zgłaszania uwag.

Proof-of-Control opiera się na bezpośrednim pytaniu: czy niezależna strona może zweryfikować, że agent AI pozostawał w granicach przypisanych mu mechanizmów kontroli? Mechanizm kontroli może uniemożliwiać agentowi przesunięcie środków bez zatwierdzenia, ograniczać zakres dostępnych mu danych klientów lub limitować narzędzia dostępne podczas zadania.

Propozycja skupia się na granicy działania, czyli punkcie, w którym agent próbuje wywołać narzędzie lub wywołać efekt zewnętrzny. Jej architektura umieszcza przy tej granicy oddzielną bramę przechwytującą. Brama ocenia proponowane działanie, blokuje działania wykraczające poza zadeklarowaną politykę i generuje dowody dotyczące decyzji.

Ten projekt jest bardziej konkretny niż konwencjonalne obietnice odpowiedzialnej AI. Określa, gdzie następuje egzekwowanie zasad, jakie dowody powinny być tworzone oraz jak inna strona może je zweryfikować. Advanced AI Society wskazuje również sześć obszarów weryfikacji: pochodzenie, prywatność, przenośność, autoryzację, tożsamość i bezpieczeństwo.

Centralna idea frameworku zakłada, że log działania agenta pozostaje jedynie twierdzeniem, gdy ten sam operator kontroluje zarówno wykonanie, jak i prowadzenie zapisów. Naruszony system mógłby pominąć działanie, zmienić zapis lub ominąć rejestrowanie. Użyteczny mechanizm weryfikacji musi zatem ujawniać modyfikacje i identyfikować założenia, od których zależą jego dowody.

Projekt proponuje kilka poziomów zapewnienia. Niższe poziomy zależą od oświadczeń operatora lub dostępu audytora. Wyższe poziomy dążą do niezależnie weryfikowalnych zapisów albo bram wykonawczych, które uniemożliwiają kontrolowane działanie bez odpowiadających mu dowodów.

Tworzy to istotne rozróżnienie między obserwowaniem działania a jego ograniczaniem. Zapis odporny na manipulacje może pomóc śledczym ustalić, co zostało zarejestrowane po incydencie. Prawidłowo wdrożona brama wykonawcza może zapobiec objętemu nią działaniu, gdy nie są spełnione warunki jego autoryzacji.

Proof-of-Control nie twierdzi, że określa, czy model bazowy jest bezpieczny, dokładny lub zgodny z założeniami. Nie rozstrzyga też, czy firma przyznała agentowi zbyt szerokie uprawnienia. Próbuje ustalić, czy zadeklarowane mechanizmy kontroli regulowały działania objęte określonym zakresem.

Ten węższy cel jest zaletą, ponieważ daje wdrażającym coś, co można przetestować. Jest również źródłem największego ograniczenia projektu. Dowody, że agent przestrzegał słabej polityki, potwierdzają jedynie zgodność z tą słabą polityką.

Kongres przekształca weryfikację agentów w kwestię zamówień

Bezpieczeństwo agentów przechodzi od technicznej preferencji do warunku prowadzenia działalności z regulowanymi nabywcami i rządem federalnym.

Proponowana ustawa Stop Rogue AI Act nakazałaby National Institute of Standards and Technology publikowanie standardów, wytycznych i najlepszych praktyk dotyczących bezpiecznego wdrażania agentów. Według opublikowanych szczegółów projektu, prace obejmowałyby ciągłe rejestry agentów, oceny bezpieczeństwa, logi odporne na manipulacje oraz weryfikację działań agentów.

Propozycję przedstawili przedstawiciele Josh Gottheimer, demokrata z New Jersey, oraz Mike Lawler, republikanin z Nowego Jorku. Większość organizacji stosowałaby wynikające z niej praktyki NIST dobrowolnie. Federalni wykonawcy konkurujący o nowe zlecenia byliby pod silniejszą presją, aby je spełniać.

Mechanizm ten ma większe znaczenie niż ogólna deklaracja regulacyjna. Wymogi zamówień publicznych mogą wpływać na rynki technologiczne bez narzucania jednej obowiązkowej architektury każdej prywatnej organizacji. Dostawcy często wdrażają mechanizmy kontroli wymagane przez administrację rządową w całej swojej ofercie, ponieważ utrzymywanie odrębnych systemów bezpieczeństwa zwiększa koszty i złożoność.

NIST pracował już nad tą dziedziną, zanim pojawiła się propozycja Izby Reprezentantów. W lutym agencja ogłosiła inicjatywę dotyczącą standardów agentów, obejmującą interoperacyjność, tożsamość, autoryzację i bezpieczeństwo. Zwróciła się również o opinie do podmiotów wdrażających, deweloperów, badaczy i dostawców infrastruktury.

Pokrywanie się z Proof-of-Control jest wyraźne. Oba działania koncentrują się na trwałej tożsamości, zdefiniowanych uprawnieniach, obserwowalnych działaniach oraz dowodach, które pozostają wiarygodne poza własną narracją agenta. Oba uznają również, że agenci współdziałają z istniejącymi systemami za pośrednictwem narzędzi, poświadczeń i interfejsów usług.

Ich role pozostają odmienne. NIST opracowuje wytyczne w ramach federalnego procesu tworzenia standardów i może wpływać na oczekiwania w zakresie zamówień publicznych. Advanced AI Society proponuje standard zorientowany na wdrożenie za pośrednictwem otwartej społeczności i chce, aby wokół niego rozwijały się narzędzia niezależnej weryfikacji.

Propozycja Izby Reprezentantów wywiera presję na trzy grupy. Dostawcy agentów muszą wyjaśnić, jak ich systemy identyfikują każdego agenta i ograniczają jego uprawnienia. Przedsiębiorstwa wdrażające muszą prowadzić rejestry i określać, które systemy mogą podejmować działania o istotnych skutkach. Dostawcy rozwiązań bezpieczeństwa muszą tworzyć dowody, które mogą badać zewnętrzni oceniający.

Federalni wykonawcy stoją przed najwyraźniejszym potencjalnym mechanizmem wymuszającym. Dostawca może traktować otwartą weryfikację jako opcjonalną podczas sprzedaży na zwykłych rynkach komercyjnych. Takie stanowisko trudniej utrzymać, gdy znaczący nabywca wymaga odczytywalnych maszynowo rejestrów, ciągłych zapisów i niezależnie testowalnych mechanizmów kontroli.

Ubezpieczyciele i audytorzy tworzą kolejne źródło presji. Ubezpieczyciel oceniający agenta, który może inicjować płatności, potrzebuje czegoś więcej niż dokumentu polityki. Potrzebuje dowodów wskazujących, która tożsamość działała, jakie uprawnienia istniały, który mechanizm kontroli ocenił żądanie oraz czy powstały zapis pozostał nienaruszony.

Ten sam problem pojawia się w ochronie zdrowia. Agent może pobierać dokumentację medyczną, podsumowywać przypadek lub przygotowywać zlecenie. Szpital musi rozróżnić potwierdzenie integralności zapisu od potwierdzenia, że decyzja kliniczna była właściwa. Proof-of-Control odnosi się do pierwszej kwestii, podczas gdy o drugiej nadal decydują zarządzanie i profesjonalna ocena.

Deweloperzy odczują tę zmianę w punktach integracji. Bezpieczeństwo nie może już kończyć się na ochronie punktu końcowego modelu. Zespoły muszą uwzględniać poświadczenia, uprawnienia narzędzi, łańcuchy delegowania, dostęp do danych i skutki uboczne we wszystkich usługach, do których agent może dotrzeć.

Dlatego bezpieczeństwo agentów staje się kwestią zamówień, a nie porównaniem funkcji. Nabywcy potrzebują dowodów, które zachowują znaczenie u różnych dostawców. Zastrzeżone panele pomagają operatorom zarządzać własnymi systemami, ale nie tworzą automatycznie wspólnego języka zapewnienia dla audytorów, ubezpieczycieli, organów regulacyjnych i klientów.

Otwarta weryfikacja kwestionuje logi kontrolowane przez dostawców

Główna rywalizacja dotyczy przenośnych dowodów stron trzecich oraz zapisów bezpieczeństwa, które pozostają pod kontrolą ocenianego dostawcy.

Tradycyjne logi przedsiębiorstw nie są bezużyteczne. Wspierają reagowanie na incydenty, monitorowanie, debugowanie i zgodność z wymogami. Problem polega na tym, że wartość logu zależy od tego, kto go wygenerował, czy uchwycił każdą istotną ścieżkę oraz czy ktoś mógł go później zmienić.

Agenci AI utrudniają odpowiedź na te pytania. Ich działania mogą zależeć od zmieniającego się kontekstu, pobranych danych, wyników modelu, odpowiedzi narzędzi i delegowanych uprawnień. System może zarejestrować końcowe wywołanie narzędzia, nie zachowując jednak wystarczającego kontekstu, aby ustalić, dlaczego wywołanie zostało autoryzowane.

Proof-of-Control proponuje dowody generowane podczas wykonania, a nie rekonstruowane po incydencie. Dąży również do przenośnych zapisów, które różne strony mogą interpretować bez uzyskiwania uprzywilejowanego dostępu do całego środowiska operatora.

Opublikowany przez projekt przegląd standardu opisuje dowody jako binarne, współczesne zdarzeniu, odporne na manipulacje i przejrzyste w zakresie pozostałych założeń zaufania. Binarność oznacza, że kontrolowane działanie albo pozostało w zadeklarowanej granicy, albo nie. Nie oznacza, że szerszy rezultat był prawidłowy.

Rozważmy agenta zakupowego uprawnionego do składania zamówień poniżej limitu określonego przez firmę. Warstwa weryfikacyjna mogłaby zarejestrować tożsamość agenta, delegowane uprawnienia, ocenioną kwotę i wynik polityki. Mogłaby też odrzucić zamówienie przekraczające ten limit.

Dowody nie potwierdzałyby jednak, że zakup był konieczny, dostawca cieszył się dobrą reputacją ani że cena stanowiła dobrą wartość. Są to odrębne oceny biznesowe. Weryfikacja pokazuje, czy jawny mechanizm kontroli zadziałał, a nie czy organizacja zaprojektowała rozsądny mechanizm kontroli.

To rozdzielenie jest kluczowe, ponieważ język bezpieczeństwa często łączy kilka odrębnych twierdzeń. Dostawca może opisywać agenta jako bezpiecznego, ponieważ ma on uprawnienia, dzienniki audytowe i opcje zatwierdzania przez człowieka. Te funkcje nie dowodzą jednak, że nie istnieje ścieżka obejścia ani że każde działanie o istotnych skutkach przechodzi przez punkt kontroli.

Proponowana przez Proof-of-Control brama przechwytująca działania ma rozwiązać ten problem. Działa poza procesem agenta i pośredniczy w kontrolowanych wywołaniach narzędzi. Aby architektura działała, agent nie może mieć alternatywnych poświadczeń ani ścieżki sieciowej pozwalających ominąć bramę.

Warunek braku obejścia jest trudny do spełnienia. Współczesne środowiska programistyczne zawierają konta usługowe, zapisane w pamięci podręcznej poświadczenia, procesy działające w tle, wtyczki i bezpośrednie trasy sieciowe. Weryfikator musi testować otaczający system, a nie jedynie analizować dane wyjściowe bramy.

Propozycja wprowadza również kompromisy dotyczące prywatności. Dowody weryfikacyjne muszą zawierać wystarczająco dużo informacji, aby uzasadnić istotny wniosek, nie ujawniając przy tym promptów, danych osobowych, wag modelu ani zastrzeżonych danych biznesowych. Twierdzenia kryptograficzne mogą ograniczać zakres ujawnianych informacji, lecz ich użyteczność zależy od jakości bazowego pomiaru i implementacji.

Kolejnym wyzwaniem jest przenośność. Dwóch dostawców może używać różnych języków polityk, systemów tożsamości, środowisk uruchomieniowych i formatów logów. Wspólny schemat dowodów może ujednolicić część tych różnic. Nie jest jednak w stanie wyeliminować wszystkich różnic w sposobie definiowania lub egzekwowania pierwotnych mechanizmów kontroli.

Otwarte zarządzanie stanowi wiarygodną odpowiedź na tę fragmentację. Publiczne specyfikacje, wektory testowe, kod referencyjny i udokumentowane modele zagrożeń dają kupującym oraz badaczom materiały, które mogą samodzielnie sprawdzić. Program zapewnienia prowadzony przez dostawcę może ujawniać mniej informacji i zmieniać się bez zewnętrznej zgody.

Linux Foundation zapewnia instytucjonalną infrastrukturę dla tych prac. Może wspierać zarządzanie społecznościowe, zasady dotyczące własności intelektualnej, procesy wnoszenia wkładu i długoterminowe opiekowanie się projektem. Nie poświadcza jednak, że projekt rozwiązał problem ograniczania agentów ani że został wdrożony w przedsiębiorstwach.

Ta granica powinna pozostać wyraźna. Hosting przez fundację jest dowodem, że projekt ma miejsce do współpracy. Nie dowodzi, że każde wdrożenie jest zgodne ze standardem, każdy dowód jest kompletny ani że klienci zaakceptują powstające zapisy.

Projekt roboczy już pokazuje, dlaczego niezależny przegląd ma znaczenie

Wczesne niespójności Proof-of-Control ujawniają różnicę między uruchomieniem standardu a jego ustanowieniem.

Wrześniowe ogłoszenie Advanced AI Society określa wydanie jako „roboczy projekt v1.0” i informuje, że publiczne konsultacje pozostają otwarte do 30 października 2026 roku. Bardziej szczegółowa strona standardu identyfikuje dokument jako „Working Draft v0.1” i podaje termin zgłaszania uwag do 7 października.

Opis wydarzenia Linux Foundation również nazywa go Proof-of-Control v0.1. Różnice te mogą wynikać z niesynchronizowanej publikacji, zmienionego planu wydania albo odmiennych oznaczeń powiązanych artefaktów. Niezależnie od przyczyny niejednoznaczność dotycząca wersji i terminów ma znaczenie dla osób decydujących, co należy recenzować.

Standard opiera się na stabilnych identyfikatorach. Wdrożeniowcy muszą wiedzieć, które wymagania normatywne obowiązują, czy wektor testowy odpowiada aktualnemu tekstowi i kiedy nastąpiła zmiana niezgodna wstecznie. Audytorzy nie mogą oceniać zgodności względem zmieniającego się oznaczenia.

Nie podważa to celu projektu. Pokazuje natomiast, dlaczego neutralne repozytoria, tagi wydań, rejestry zmian i publiczne śledzenie zgłoszeń są ważne. Otwarty standard musi umożliwiać weryfikację własnego pochodzenia, zanim zażąda tego samego od dostawców agentów.

Planowane publiczne spotkanie informacyjne zaplanowano na 23 września. Zgromadzi ono liderów Linux Foundation, przedstawicieli Advanced AI Society, inwestorów z obszaru bezpieczeństwa, dostawców tożsamości, ubezpieczycieli oraz Agentic AI Foundation.

Wydarzenie może wyjaśnić kwestie zarządzania, lecz sama publiczna dyskusja nie rozstrzygnie technicznej niepewności. Współtwórcy potrzebują normatywnej specyfikacji, jawnego modelu zagrożeń, testów zgodności i odtwarzalnych implementacji. Potrzebują także procesu określającego, które mechanizmy spełniają poszczególne wymagania.

Projekt informuje, że jego repozytorium zawiera implementację referencyjną, definicje twierdzeń odczytywalne maszynowo, scenariusze ataków i podpisane wektory testowe. Opisuje implementację jako punkt odniesienia, a nie produkt produkcyjny. To zastrzeżenie jest istotne, ponieważ wczesny kod może demonstrować wykonalność bez spełniania wymogów bezpieczeństwa operacyjnego.

Referencyjna brama może pokazać, jak oceniać politykę i tworzyć podpisane dowody. Brama produkcyjna musi również przetrwać kradzież poświadczeń, warunki wyścigu, próby ponownego odtworzenia, niepełną telemetrię, kompromitację kluczy, awarie infrastruktury i działania wrogich operatorów.

Kompletność tworzy kolejny trudny problem. Zapisy odporne na manipulację mogą wykazać, że zarejestrowane wpisy nie zostały zmienione. Same w sobie nie mogą jednak dowieść, że każde istotne działanie trafiło do rejestru. Agent mający nieobserwowaną trasę może działać poza rejestrem, podczas gdy widoczny łańcuch dowodowy pozostaje wewnętrznie spójny.

Silniejszy poziom zaproponowany przez Advanced AI Society rozwiązuje to poprzez bramkowanie wykonania. W tym modelu objęte działanie nie może wystąpić, jeśli nie przejdzie przez mechanizm kontroli i nie wytworzy dowodu. Pozostaje pytanie, czy rzeczywiście objęte są wszystkie działania o istotnych skutkach.

Skutki zewnętrzne również komplikują obraz. Brama może zweryfikować, że agent wysłał autoryzowane żądanie płatności. Nie może automatycznie dowieść, że bank rozliczył płatność dokładnie zgodnie z oczekiwaniami. Zapewnienie musi połączyć dowody po stronie agenta z potwierdzeniami z systemów zewnętrznych.

Łańcuchy tożsamości wprowadzają podobne ryzyka. Jeden agent może delegować pracę drugiemu, który następnie wywołuje usługę zewnętrznego dostawcy. Każde przekazanie może zmienić uprawnienia, kontekst lub zakres ekspozycji danych. Wiarygodny standard musi zachować możliwość przypisania odpowiedzialności, nie zakładając, że pojedynczy token tożsamości wyjaśnia cały łańcuch.

Jakość mechanizmów kontroli pozostaje największym ograniczeniem koncepcyjnym. Proof-of-Control wyraźnie unika oceniania, czy wybrana reguła była rozsądna. Takie rozdzielenie czyni techniczną zgodność łatwiejszą do zarządzania, lecz organizacje mogą przedstawiać zgodność jako szerszy dowód bezpieczeństwa.

Kupujący powinni oprzeć się temu skrótowi myślowemu. Zweryfikowany agent może wiernie stosować niebezpieczną politykę. Może też podejmować autoryzowane działania na podstawie błędnego rozumowania modelu. Weryfikacja w czasie działania uzupełnia testowanie, nadzór człowieka, analizę ryzyka i reagowanie na incydenty. Nie zastępuje ich.

Najbardziej odpowiedzialnym twierdzeniem projektu jest zatem twierdzenie wąskie. Ma on poprawić jakość dowodów dotyczących tego, czy zadeklarowane mechanizmy kontroli regulowały objęte nimi działania. Twierdzenia o pełnym bezpieczeństwie agentów, zgodności regulacyjnej lub wyeliminowanej odpowiedzialności wykraczałyby poza to, co te dowody potwierdzają.

Standard musi udowodnić, że działa w rzeczywistych stosach agentowych

Przyjęcie standardu będzie zależeć od tego, czy Proof-of-Control może działać w modelach hostowanych, systemach lokalnych i przepływach pracy wielu dostawców bez tworzenia kolejnej odizolowanej warstwy zgodności.

Stosy agentowe w przedsiębiorstwach rzadko pochodzą od jednego dostawcy. Firma może korzystać z hostowanego modelu, wewnętrznego frameworka orkiestracji, zewnętrznego dostawcy tożsamości, baz danych w chmurze i specjalistycznych narzędzi od kilku dostawców. Każda warstwa udostępnia inne mechanizmy kontroli i telemetrię.

Proof-of-Control twierdzi, że jego model granicy działania może działać w konfiguracjach otwartych i zamkniętych. Dostawca modelu nie musi koniecznie ujawniać swoich wag ani danych treningowych. Warstwa weryfikacyjna obserwuje natomiast kontrolowane działania w miejscu, w którym system orkiestracji wywołuje zewnętrzne możliwości.

Podejście to sprzyja organizacjom, które kontrolują własną pętlę agenta. Mogą one wstawić bramę, ograniczyć poświadczenia i kierować wywołania narzędzi przez określoną granicę. Zarządzana usługa agenta jest trudniejsza, ponieważ dostawca kontroluje środowisko orkiestracji i decyduje, jakie dowody udostępnić.

Różnica ta sprawia, że architektura staje się kryterium zakupowym. Klienci oceniający zarządzanego agenta muszą pytać, czy generuje on niezależnie weryfikowalne dowody, czy dowody obejmują każde istotne wywołanie narzędzia oraz czy operator może ominąć zadeklarowaną ścieżkę.

Zespół finansowy stanowi konkretny test. Załóżmy, że agent przygotowuje faktury, aktualizuje zapisy księgowe i inicjuje przelewy bankowe. System weryfikacyjny musi rozróżniać odczyt księgi, proponowanie płatności, uzyskanie zatwierdzenia i przesłanie ostatecznej dyspozycji.

Każde działanie wymaga tożsamości, źródła uprawnień, obowiązującej polityki, odniesienia czasowego i wyniku. System musi zachować ten łańcuch między narzędziami bez ujawniania danych konta w publicznym rejestrze weryfikacyjnym. Musi też obsłużyć cofnięte zatwierdzenie lub zmianę polityki w trakcie wykonywania.

Agent wspierający inżynierię oprogramowania tworzy inny test. Może on analizować prywatny kod, modyfikować pliki, uruchamiać testy i żądać wdrożenia. Proof-of-Control mógłby zweryfikować, do którego repozytorium agent uzyskał dostęp i czy wdrożenie wymagało wskazanego zatwierdzenia.

Standard nadal musiałby uwzględniać skutki pośrednie. Kod, który przechodzi przez bramę autoryzacji, może później ujawnić dane lub zmienić zachowanie środowiska produkcyjnego. Dowody z czasu działania pokazują, jak agent przekroczył granicę, podczas gdy przegląd oprogramowania i testy bezpieczeństwa oceniają artefakt, który wytworzył.

Ochrona zdrowia testuje prywatność i uprawnienia zawodowe. Agent może pobrać kartę pacjenta w ramach delegacji lekarza i przesłać projekt zlecenia do zatwierdzenia. Dowody muszą potwierdzać, że dostęp pozostał w granicach przyznanego uprawnienia, bez ujawniania samych informacji medycznych.

Te scenariusze wymagają więcej niż ogólnego podpisanego logu. Potrzebują wspólnej semantyki dla tożsamości, uprawnień, oceny polityk, przechowywania dowodów i zachowania w razie awarii. Zapis, który jeden weryfikator interpretuje inaczej niż drugi, nie tworzy interoperacyjności.

Testowanie zgodności zdecyduje zatem o wiarygodności projektu. Niezależne zespoły powinny móc uruchomić ten sam zestaw testów wobec odrębnych implementacji i uzyskać spójne wyniki. Testy negatywne powinny pokazywać, jak systemy zawodzą, gdy zapisy zostają zmienione, działania omijają bramę lub uprawnienia wygasają.

Wydajność również będzie miała znaczenie. Agenci często wykonują kilka wywołań narzędzi w ramach jednego zadania. Ciągłe generowanie dowodów zwiększa nakład pracy związany z podpisywaniem, przechowywaniem, weryfikacją i oceną polityk. Przedsiębiorstwa będą potrzebować danych o opóźnieniach i działaniu pochodzących z reprezentatywnych wdrożeń.

Publiczne materiały Proof-of-Control podkreślają weryfikację z prędkością maszynową, ponieważ przegląd wykonywany przez ludzi nie może dorównać tempu działania agentów. To założenie jest rozsądne, lecz automatyzacja może także powielać błędną regułę z prędkością maszynową. Zmiany w mechanizmach kontroli muszą więc podlegać zarządzaniu równie starannemu jak zmiany w kodzie.

Własność operacyjna to kolejne otwarte pytanie. Zespoły bezpieczeństwa mogą definiować podstawowe polityki, zespoły aplikacyjne mogą integrować bramy, zespoły ds. tożsamości mogą zarządzać delegowaniem, a zespoły ds. zgodności mogą przechowywać dowody. Standard zakładający jednego, zintegrowanego właściciela będzie miał trudności w dużych organizacjach.

Projekt może mimo to odnieść sukces, nie stając się jedynym standardem bezpieczeństwa agentów. Jego model dowodowy może wpłynąć na wytyczne NIST, API dostawców, kwestionariusze ubezpieczeniowe lub szablony zakupowe. Wspólne koncepcje mogą oddziaływać na rynek, nawet gdy implementacje się różnią.

Większym ryzykiem jest ceremonialne przyjęcie standardu. Dostawcy mogą deklarować zgodność, obejmując nią tylko wybrane działania, albo posługiwać się językiem otwartej weryfikacji bez zapewniania niezależnych testów. Jasne poziomy zgodności i wymagania możliwe do sprawdzenia maszynowo mogą ograniczyć takie zachowania.

Trzy sygnały zdecydują, czy otwarta weryfikacja stanie się infrastrukturą

Kolejne trzy testy to spójność specyfikacji, niezależna implementacja i przyjęcie regulacyjne.

Pierwszym sygnałem będzie to, czy Advanced AI Society rozwiąże konflikty w projekcie dotyczące wersji i terminu zgłaszania uwag. Publiczny tag wydania powinien łączyć tekst normatywny, schematy, wektory testowe, implementację referencyjną oraz historię zmian.

Taki krok wzmocniłby główny argument projektu. Weryfikowalne pochodzenie powinno zaczynać się od samego standardu. Jeśli artefakty pozostaną niespójnie oznaczone, przedsiębiorstwa będą wahać się przed budowaniem wokół nich mechanizmów kontrolnych lub umów.

Drugim sygnałem będzie niezależna implementacja. Kod referencyjny organizacji założycielskiej może dowieść, że jego autorzy zbudowali to, co opisali. Oddzielny zespół musi pokazać, że specyfikacja przekazuje wystarczająco dużo szczegółów, aby uzyskać zgodne dowody i wyniki weryfikacji.

Przydatne raporty z implementacji powinny dokumentować zarówno porażki, jak i sukcesy. Powinny wskazywać opóźnienia, nakład pracy związany z integracją, nieobsługiwane frameworki agentowe, ograniczenia prywatności oraz wszelkie ścieżki obejścia wykryte podczas testów. Twierdzenia dotyczące środowiska produkcyjnego wymagają dowodów z otoczeń pozostających poza bezpośrednią kontrolą autorów.

Trzecim sygnałem będzie sposób, w jaki NIST i Kongres zdefiniują wymagania dotyczące weryfikacji agentów. Jeśli federalne wytyczne będą wymagać ciągłych inwentaryzacji, odpornych na manipulacje rejestrów, przypisywalnych tożsamości oraz niezależnie testowalnych mechanizmów kontrolnych, Proof-of-Control odpowie na rozpoznawalną potrzebę zakupową.

Projekt nabrałby dalszego rozpędu, gdyby federalni wykonawcy lub regulowani nabywcy żądali przenośnych dowodów zamiast zrzutów ekranu od dostawców. Taki wymóg premiowałby interoperacyjność i stworzyłby przestrzeń dla wielu dostawców usług weryfikacyjnych.

Przeciwny rezultat osłabiłby argument za wspólnym ekosystemem. Agencje mogłyby zaakceptować konwencjonalne logi i okresowe audyty, a Kongres mógłby nie posunąć naprzód leżących u podstaw przepisów. Przedsiębiorstwa mogłyby wówczas traktować otwartą weryfikację jako opcjonalny eksperyment w zakresie bezpieczeństwa.

Szersza debata o AI w Waszyngtonie pozostaje nierozstrzygnięta. Liderzy Kongresu rozmawiali o mechanizmach ochronnych, jednocześnie podkreślając lekkie podejście regulacyjne i konkurencję z Chinami. To napięcie sprawia, że ukierunkowane standardy techniczne są bardziej prawdopodobne niż jedna kompleksowa ustawa o AI.

Należy wyraźnie rozróżniać między ustawodawstwem a uchwaleniem prawa. Propozycja Izby Reprezentantów dotycząca bezpieczeństwa agentów nie jest ustanowioną polityką federalną. Obecna inicjatywa NIST jest aktywna, lecz jej ostateczne wytyczne i wpływ na rynek nadal się kształtują.

Advanced AI Society ma zatem wąskie okno, by wpłynąć na kształtujące się słownictwo. Jeśli zdoła zademonstrować możliwe do wdrożenia mechanizmy kontrolne, zanim zasady zamówień publicznych się utrwalą, jej definicje mogą wpłynąć na sposób, w jaki nabywcy opisują gwarancje działania w czasie rzeczywistym.

Deweloperzy powinni obserwować, czy popularne frameworki agentowe dodają natywną obsługę przenośnych dowodów. Nabywcy korporacyjni powinni prosić dostawców o wskazanie każdego kontrolowanego działania oraz każdej ścieżki omijającej egzekwowanie zasad. Zespoły bezpieczeństwa powinny porównywać integralność dowodów z ich kompletnością.

Pracownicy umysłowi również mają w tym swój interes. Agent działający na poczcie e-mail, dokumentach, kalendarzu lub kontach finansowych danej osoby może wywołać konsekwencje, zanim użytkownik je przejrzy. Użytkownicy potrzebują zrozumiałego zapisu tego, jakie uprawnienia przyznali i co agent z nimi zrobił.

Inicjatywa Advanced AI Society Proof-of-Control stanowi poważną odpowiedź na tę potrzebę, ale nadal jest wczesnym projektem. Jej wartość będzie wynikać z przetestowanej interoperacyjności, precyzyjnego zakresu i dowodów, które wytrzymają analizę stron innych niż jej twórcy.

Właściwym kolejnym krokiem nie jest założenie, że standard rozwiązuje problem bezpieczeństwa agentów. Nabywcy i twórcy powinni przeanalizować projekt, przetestować wymóg braku możliwości obejścia oraz zgłaszać konkretne niepowodzenia implementacyjne podczas publicznych konsultacji. Otwarta weryfikacja staje się infrastrukturą dopiero wtedy, gdy niezależni uczestnicy mogą odtworzyć jej twierdzenia i wskazać jej ograniczenia.