Tool calling w AI: bezpieczny projekt narzędzi, argumentów i uprawnień

Zaprojektuj tool calling dla AI w oparciu o wąskie narzędzia, walidowane argumenty, uprawnienia po stronie serwera, potwierdzanie wrażliwych akcji i audyt wyników.

Tool calling w AI: bezpieczny projekt narzędzi, argumentów i uprawnień
Krótka odpowiedź

Zdefiniujcie małe narzędzia domenowe z precyzyjnym schematem wejścia i wyjścia. Argumenty weryfikujcie na serwerze, uprawnienia oceniajcie na podstawie tożsamości i obiektu, akcje zapisu lub nieodwracalne wyświetlajcie do potwierdzenia i wykonujcie idempotentnie. Logujcie decyzję i wynik bez sekretów oraz testujcie szkodliwe kombinacje wywołań.

Tool calling pozwala modelowi poprosić aplikację o wyszukanie danych lub wykonanie akcji za pomocą zdefiniowanej funkcji. Model nie posiada jednak narzędzia bezpośrednio, a jego argumentów nie można uznawać za wiarygodne. Warstwa aplikacji musi każde wywołanie walidować, autoryzować i zdecydować, czy je wykona, odrzuci, czy poprosi człowieka o potwierdzenie.

Najbezpieczniejsze narzędzie ma wąskie przeznaczenie, mały schemat i przewidywalny wynik. Ogólne narzędzia typu „wykonaj żądanie” czy „uruchom SQL” przenoszą zbyt dużą odpowiedzialność na model językowy. Odczyt i zapis są rozdzielone, wartości wrażliwe nie pojawiają się w kontekście, a każda wykonana akcja pozostaje powiązana z użytkownikiem, sprawą i śladem audytowym.

Narzędzie powinno nazywać konkretną zdolność, na przykład odnalezienie zamówienia według uprawnionego identyfikatora lub przygotowanie propozycji zmiany terminu. Model wybiera wtedy spośród jasno określonych możliwości. Uniwersalny dostęp do bazy danych, plików czy dowolnego URL zwiększa pole do nadużyć i utrudnia audyt. Tego, czego model nie potrzebuje do danego celu, w ogóle nie należy udostępniać.

Oddziel odczyt, propozycję i wykonanie. Narzędzie może najpierw zwrócić podgląd skutków oraz stabilny token propozycji; osobny krok po potwierdzeniu wprowadza zmianę. Jeśli system obsługuje operacje zbiorcze, ogranicz liczbę obiektów i pokaż je użytkownikowi. Nazwy i opisy narzędzi powinny być jednoznaczne również przy podobnych procesach.

Walidacja schematu i biznesowego znaczenia argumentów

Schemat wejściowy ogranicza typy, pola obowiązkowe, długość, format i dozwolone wartości. Serwer odrzuca nieznane pola i nieoczekiwany zakres. Sam schemat jednak nie wystarcza: data może być formalnie poprawna, ale wykraczać poza dozwolony okres, a identyfikator może należeć do innego klienta. Reguły domenowe są wykonywane poza modelem przy każdym wywołaniu.

Model nie może dostarczać tożsamości użytkownika, tenanta ani roli jako miarodajnego argumentu. Aplikacja wyprowadza je z uwierzytelnionej sesji. Przy pracy z tekstem należy odróżniać treść przeznaczoną do zapisania od instrukcji wewnętrznych. Adresy URL warto dopuszczać wyłącznie na podstawie listy dozwolonych adresów i reguł sieciowych, aby narzędzie nie odczytywało usług wewnętrznych ani niezaufanych adresów na podstawie wstrzykniętego polecenia.

  • dokładny schemat bez nieoczekiwanych pól
  • tożsamość, rola i tenant ustalane przez serwer
  • limity domenowe wykraczające poza kontrolę formatu
  • bezpieczna lista dozwolonych celów i operacji

Egzekwuj uprawnienia przy każdym obiekcie

Autoryzację sprawdza się tuż przed odczytem lub zmianą, a nie tylko przy otwarciu czatu. Użytkownik może mieć dostęp do jednego projektu, a do innego nie, mimo że korzysta z tego samego narzędzia. Wyniki należy filtrować na warstwie danych. Model nie otrzymuje nawet nazwy niedozwolonego obiektu, ponieważ sam fakt jego istnienia może być wrażliwy.

Tożsamość serwisowa ma najmniejsze niezbędne uprawnienia i w miarę możliwości działa w delegowanym kontekście użytkownika. Długoterminowy, szeroki klucz dla wszystkich narzędzi utrudnia unieważnienie i dochodzenie. Przy zmianie roli lub zakończeniu sesji zmiana uprawnień obowiązuje natychmiast, także w cache. Odmowa zwraca bezpieczną informację bez szczegółów, które ułatwiłyby testowanie cudzych identyfikatorów.

Potwierdzaj wrażliwe akcje i obsługuj ponowienia

Przed wysłaniem wiadomości, usunięciem, operacją finansową lub zmianą ważnego stanu pokażcie człowiekowi cel, wartości i oczekiwany skutek. Potwierdzenie dotyczy konkretnej, niezmiennej propozycji i po jej edycji jest wymagane ponownie. Ogólne „zezwól na wszystkie kolejne działania” nie odpowiada świadomej decyzji. Niektóre operacje mogą pozostać całkowicie poza zasięgiem modelu.

Narzędzie używa klucza idempotentności i zwraca jednoznaczny status, ponieważ przekroczenie limitu czasu może prowadzić do ponowienia. Model nie może przy niejasnym wyniku automatycznie próbować innej drogi o tym samym skutku. Najpierw weryfikuje się stan pierwotnej operacji. Krok kompensacyjny należy zaprojektować dla przypadków, które można bezpiecznie cofnąć, a przy częściowym powodzeniu eskalować z dokładnym kontekstem.

Testuj kombinacje i audytuj rzeczywisty efekt

Testy obejmują nieprawidłowe argumenty, cudzy obiekt, odebrane uprawnienie, zduplikowane wywołanie, timeout, szkodliwą treść z dokumentu oraz próbę łączenia narzędzi w łańcuch wbrew zamierzonemu celowi. Środowisko symulowane pozwala testować bez skutków produkcyjnych. Proszę oceniać nie tylko to, o co poprosił model, lecz także decyzję serwera i końcowy stan systemu docelowego.

Ścieżka audytu łączy intencję użytkownika, żądanie modelu, zwalidowany argument, wynik autoryzacji, potwierdzenie i identyfikator wykonanej akcji. Sekrety i pełne wrażliwe treści należy redagować. Monitoring ostrzega o wzroście liczby odmów, nietypowym narzędziu, pętli i nieoczekiwanym wolumenie. Pojedyncze narzędzie musi dać się szybko wyłączyć bez wyłączania całego asystenta.

Najczęstsze pytania

Czy model może bezpośrednio wykonać funkcję?

Model jedynie proponuje nazwę narzędzia i argumenty. Warstwa aplikacji musi je zwalidować, autoryzować i w zależności od ryzyka zażądać potwierdzenia, a dopiero potem wykonać właściwą funkcję.

Dlaczego wejściowy schemat JSON nie wystarczy?

Schemat weryfikuje format, a nie własność obiektu, regułę biznesową ani uprawnienia użytkownika. Te kontrole serwer musi przeprowadzać przy każdym wywołaniu.

Które narzędzia AI wymagają potwierdzenia?

Przede wszystkim te, które wysyłają, zmieniają, publikują, płacą lub usuwają i mają istotne albo trudne do odwrócenia skutki. Dokładna granica wynika z ryzyka organizacji.

Źródła i dalsza lektura

Adam Antoni, programista rozwiązań cyfrowych
Adam Antoni · Webiant

Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.

Potrzebujesz rozwiązać ten temat w swoim projekcie?

Proszę napisać, co chcą Państwo poprawić, z czym obecnie się zmagają i jakiego rezultatu oczekują. Podczas wstępnej konsultacji omówimy odpowiedni zakres i dalsze kroki.

Proszę wybrać, na które pliki cookie Państwo zezwalają. Wybór można w każdej chwili zmienić za pomocą linku w stopce lub przycisku cookies.

Ochrona prywatności i szczegóły dotyczące plików cookie