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.
Projektuj narzędzia według intencji roboczej
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.