Bezpieczne odkrywanie narzędzi dla agentów AI w przedsiębiorstwach: Rejestr, bramkarz i polityka.

Pytanie stojące za narzędziami dla agentów

Jeśli dać agentowi kilka interfejsów API i pozwolić modelowi wybrać, który z nich użyć, dostęp do narzędzi wydaje się problemem rozwiązanym. Sytuacja zmienia się w przedsiębiorstwach – tam katalog zawiera setki lub tysiące narzędzi. Niektóre to nieszkodliwe operacje tylko odczytu, inne mogą zmieniać dane klientów lub informacje o charakterze osobistym, a jeszcze mniejsza grupa może inicjować transakcje finansowe, konfigurować konta lub wykonywać operacje administracyjne. „Jak agent znajduje odpowiednie narzędzie?” to proste pytanie. Trudniejsze jest to, jak zagwarantować, że agent będzie mógł widzieć i używać tylko tych narzędzi, do których ma uprawnienia w ramach konkretnej prośby użytkownika.

To właśnie jest przedmiotem analizy w ramach tego studium projektowego. Jest to uzasadniona architektura przeznaczona do środowisk usług finansowych i nie powinna być traktowana jako opis wdrożonego systemu płatniczego.

Zachowanie modelu poza granicami bezpieczeństwa

Produkcyjne ML przekazuje ważną lekcję: kluczowy dla biznesu proces nie znajduje się wewnątrz modelu. Model może przewidywać, rekomendować lub klasyfikować, natomiast bezpieczeństwo, walidacja, zasady biznesowe, uprawnienia oraz przetwarzanie transakcji należą do deterministycznego oprogramowania znajdującego się poza nim. Agenci sprawiają, że te zasady stają się bardziej ścisłe, a nie luźniejsze, ponieważ mogą podejmować działania. LLM może być doskonałym analitykiem, ale nadal może być słabym wyborem jako element zabezpieczeń systemu przedsiębiorstwa.

Prosty scenariusz finansowy pokazuje dlaczego. Klient prosi agenta o sprawdzenie najnowszej transakcji i podanie informacji, czy została przeprowadzona zwrotka. Agent musi zrozumieć prośbę i skorzystać z narzędzi do wyszukiwania klientów oraz transakcji, co jest czynnością rutynową.

Teraz zmieńmy żądanie: jeśli zwrot pieniędzy jeszcze nie został przeprowadzony, należy go wydać. Agent nie tylko pobiera już informacje, ponieważ może to mieć konsekwencje finansowe. Ta niewielka zmiana motywuje zasadę, na której opiera się wszystko inne:

Agent może rozważyć jakieś działanie i je zaproponować. To, czy to działanie faktycznie zostanie wykonane, decyduje platforma deterministyczna.

Rozdzielenie procesu rozumowania od jego wykonania pozwala systemowi korzystać z mocnych stron modeli językowych bez polegania na nich przy zadańach, których nie mogą wykonać w sposób niezawodny.

Rejestr narzędzi zamiast ogromnej listy

W jaki sposób agent powinien dowiedzieć się, jakie narzędzia istnieją? Jedną z opcji jest przekazanie modelowi bardzo długiej listy definicji narzędzi i pozwolenie mu na określenie ich istotności. Może to wystarczyć dla prototypu, ale nie sprawdzi się w skali przedsiębiorstwa. Tysiące opisów powoduje problemy z kontekstem oraz wzrost opóźnień, a nieograniczone odkrywanie narzędzi zwiększa ryzyko bez żadnych korzyści.

Lepszym rozwiązaniem jest Rejestr narzędzi – katalog możliwości dostępny w przedsiębiorstwach. Zawiera on coś więcej niż tylko nazwy i schematy API. Każda pozycja posiada metadane, które platforma może wykorzystać do odkrywania narzędzi, zarządzania nimi oraz podejmowania decyzji politycznych:

• domena biznesowa, właściciel i wersja
• to, czy narzędzie jest tylko do odczytu, czy może też pisać
• klasa ryzyka i wymagane funkcje
• klasyfikacja danych
• schematy danych wejściowych i wyjściowych
• cechy idempotencji
• wymagania audytowe

Metadane są najważniejsze przy rozróżnianiu rodzajów operacji. Wyszukiwanie transakcji to operacja o dość niskim ryzyku, zwrot pieniędzy to operacja zapisu o dużym wpływie finansowym, natomiast operacja administracyjna może wiązać się z jeszcze większym ryzykiem. Te różnice nie mogą pozostać jedynie w dokumentacji – muszą istnieć w samej platformie, aby deterministyczna infrastruktura mogła na nich działać.

Odkrywanie to nie autoryzacja

To może być najprzydatniejsze rozróżnienie w całym projekcie: odkrycie narzędzia oraz posiadanie uprawnień do jego użycia to dwie różne rzeczy.

Odkrywanie odpowiada na pytanie, jakie narzędzia powinny być udostępnione temu agentowi do wykonywania danej zadania. Autoryzacja odpowiada na pytanie, czy dany wywołanie jest obecnie dozwolone.

Metadane rejestru napędzają krok filtrowania, który odbywa się przed tym, jak model językowy rozważy swoje opcje. Najpierw platforma określa, kim jest użytkownik, który agent działa, jaki jest tenant, jaki jest otaczający kontekst oraz co próbuje osiągnąć żądanie. Następnie tworzy listę narzędzi pasujących do tego zamiaru, a potem ją redukuje, biorąc pod uwagę możliwości agenta, uprawnienia użytkownika, ograniczenia tenanta, region oraz polityki ryzyka. Model widzi tylko to, co pozostało.

Ten filtr nadal nie może być ostateczną linią obrony. Model może wysłać żądanie, którego nikt się nie spodziewał, błędnie zinterpretować intencję użytkownika lub zostać wpłynięty przez iniekcję promptu. Dlatego każde wezwanie przechodzi przez kontrolowany Tool Gateway w drodze do podstawowej API przedsiębiorstwa.

W zasadzie brama ocenia razem zestaw faktów (kto jest użytkownikiem, który agent wykonywa telefon, o co jest prośba, na jakim zasobie, z jakimi parametrami, w jakim kontekście) i stosuje odpowiednią politykę.

Uzyskaj autoryzację dla intencji, a nie tylko narzędzia

Przykład zwrotu pieniędzy pokazuje kolejny aspekt. Autoryzacja nie może polegać wyłącznie na tym, jakie narzędzie jest używane. Musi uwzględniać intencję oraz wynikającą z niej akcję.

Sprawdzanie stanu zwrotu pieniędzy i rozpoczynanie zwrotu to nie to samo – jedno polega na odczytaniu informacji, a drugie ma charakter finansowego skutku ubocznego. Platforma powinna je wyraźnie rozróżniać. Prośba sklasyfikowana jako zapytanie o stan zwrotu może trafić do narzędzi służących do wyszukiwania klientów i transakcji, ale ta klasyfikacja sama w sobie nie daje uprawnień do wykonania operacji zwrotu. Nawet jeśli model błędnie zdecyduje, że należy wydać zwrot, warstwa autoryzacji może porównać faktycznie złożoną prośbę z dozwolonym zamiarem i ją odrzucić.

Tutaj podejście bezpieczeństwa zmienia się z pytania, czy dany agent ma dostęp do API zwrotów, na pytanie, czy ten konkretny użytkownik, agent, zamiar, zasób i działanie są dozwolone w danym kontekście.

Gdy połowa procesu przestaje działać

Gdy akcja zostanie zatwierdzona, pojawia się kolejny problem: co wtedy, gdy jedna część procesu pracy się powiedzie, a druga nie? Załóżmy, że zwrot pieniędzy przejdzie pomyślnie, ale e-mail z potwierdzeniem nie. Ponowne uruchomienie całego procesu może doprowadzić do dwukrotnego przeprowadzenia zwrotu.

Bardziej bezpieczne rozwiązanie polega na przekształceniu tego efektu ubocznego w krok w trwałym procesie pracy. Autoryzacja zatwierdza zwrot pieniędzy, API odpowiedzialne za zwrot go realizuje, a wynik jest zapisywany. Ten zapisany rezultat wywołuje zdarzenie RefundCompleted, które uruchamia powiadomienia. W przypadku nieudanego wysłania e-maila uruchamia się ponowna próba wysłania samego powiadomienia, bez powtarzania operacji finansowej.

Obecność modelu językowego w systemie nie oznacza wycofania klasycznych narzędzi korporacyjnych. Powtórne próby i usuwanie duplikatów, mechanizmy ochronne i działania korygujące, operacje idempotentne, trwały stan oraz przetwarzanie oparte na zdarzeniach nadal mają zastosowanie. Agenty mogą przyczynić się do decydowania o tym, co powinno się wydarzyć, podczas gdy deterministyczna infrastruktura kontroluje kluczowe zmiany stanu.

Aprobacje należą do polityki

LLM również nie powinno decydować, kiedy człowiek musi coś zatwierdzić. To kwestia polityki. Organizacja może pozwolić na automatyczne zwroty poniżej określonego progu i wymagać zatwierdzenia w przypadku kwot wyższych, zawsze wymagać zatwierdzenia dla operacji administracyjnych oraz dodawać kontrole dla transakcji o nietypowych destynacjach lub podwyższonym ryzyku. Model może zaznaczyć, że może być potrzebna jakakolwiek akcja. System polityk decyduje, czy zatwierdzenie jest wymagane, a Tool Gateway egzekwuje tę decyzję. Korzyści przynosi również zarządzanie, ponieważ zasady są jasne, podlegają przeglądowi, mają wersje i mogą być audytowane, a nie są ukryte w promptach.

Płaszczyzna kontroli i płaszczyzna wykonywania

Po przeanalizowaniu tych scenariuszy projekt wygląda o wiele mniej jak prosty przepływ od użytkownika przez LLM do narzędzi, a bardziej jak platforma zarządzania przedsiębiorstwem. Naturalnie dzieli się on na dwie obszary.

Plan sterowania to miejsce, w którym organizacja definiuje swoje zasady. Obejmuje on katalog agentów, rejestr narzędzi, definicje możliwości, klasy ryzyka, polityki autoryzacji i zatwierdzania oraz ogólne ustawienia zarządzania.

Plan wykonywania to to, co działa w czasie rzeczywistym. Zawiera on bramy do API i agentów, same agenty, już przefiltrowane dane o odkryciu, egzekwowanie zasad, wymianę danych uwierzytelniających, uruchamiane narzędzia, stan procesów roboczych oraz strumień zdarzeń audytowych. Zasady można zarządzać centralnie, natomiast egzekwowanie zasad odbywa się bliżej miejsca, gdzie działają obciążenia robocze.

To rozdzielenie ma znaczenie w dużych skali. Przy setkach lub tysiącach agentów oraz ogromnej liczbie narzędzi nikt nie chce, aby każda weryfikacja uprawnień czekała na pojedynczą centralną usługę. Zasady są zarządzane w jednym miejscu, natomiast punkty egzekwowania są rozproszone, a dane dotyczące zasad są przechowywane w pamięci podręcznej lub replikowane tam, gdzie to konieczne.

Ocena działań, a nie tylko odpowiedzi

Taki projekt łączy się dobrze z rozwiązaniami ML w przedsiębiorstwach, dodając jednocześnie nową klasę problemów. Tradycyjne metody ML skupiają się na dokładności, jakości danych, odchyleniach, opóźnieniach, bezpieczeństwie, monitorowaniu oraz niezawodności operacyjnej. Agenty zachowują wszystkie te aspekty i dodają ocenę działań.

Prawidłowa odpowiedź końcowa nie rozstrzyga sprawy. Recenzenci muszą również wiedzieć, czy agent wybrał odpowiedni narzędzie i podał właściwe parametry, czy pozostał w granicach uprawnień, czy unikał działań, których nie miał prawa wykonać, czy postępował zgodnie z zamierzonym procesem pracy, czy poprosił człowieka o zatwierdzenie w razie potrzeby, oraz czy wywołał oczekiwane skutki uboczne. Ocena przechodzi od oceny odpowiedzi do oceny działań.

Zasada, która obowiązuje

Jedna zasada jest ciągle podkreślana: traktuj LLM jako niepewny element podejmowania decyzji, a nigdy jako granicę bezpieczeństwa. Agent może rozumować, odkrywać istotne możliwości i proponować działania. Deterministyczna infrastruktura przedsiębiorstwa decyduje o tym, co agent może robić, jakie zasoby może używać, jakie parametry są dozwolone, czy potrzebne jest zatwierdzenie człowieka, jak bezpiecznie realizować skutki uboczne oraz jak audytować cały proces.

To jest prawdziwe wyzwanie architektoniczne w zakresie sztucznej inteligencji agentowej. Sprawienie, by agent był na tyle inteligentny, by korzystać z narzędzi, to łatwa część. Trudna jest natomiast platforma, na której tysiące agentów działają dla milionów użytkowników, przy jednoczesnym utrzymaniu kontroli nad tożsamością, uprawnieniami, regułami biznesowymi oraz niezawodnością działania.