Jak zaprojektować ograniczonego asystenta AI: narzędzia, uprawnienia i kontekst

Granicy asystenta AI nie wyznacza zdanie „nie wysyłaj wiadomości” zapisane w prompcie, jeżeli usługa nadal udostępnia modelowi narzędzie i poświadczenie pozwalające tę wiadomość wysłać. Rzeczywistą granicą jest wykonywalny kontrakt usługi: dozwolone dane, konkretne operacje, używana tożsamość, uprawnienia systemu docelowego, limit działania, sposób akceptacji oraz warunek zatrzymania. Gdy cały produkt otrzymuje jeden szeroki zestaw praw, zwykła rozmowa może niepotrzebnie odziedziczyć dostęp przeznaczony dla zupełnie innego zadania.

Co wolno robić asystentowi AI?

Zespół powinien najpierw zapisać jednozdaniową kartę usługi, a dopiero potem rozłożyć ją na funkcje widoczne dla użytkownika. Użyteczny wzór brzmi: „Dla [uprawnionych użytkowników] asystent może [rodzina dozwolonych zadań], korzystając z [zatwierdzonego zakresu informacji], aby wytworzyć [dozwolony wynik], lecz nie może [jawne cele negatywne lub decyzje o istotnych skutkach]”. Takie zdanie wymusza wskazanie odbiorcy, środowiska, nadzoru, właściciela ryzyka i rezultatów, których usługa świadomie nie zapewnia.

Następnie trzeba zastąpić szerokie czasowniki, takie jak „pomagać” czy „zarządzać”, osobnymi operacjami: wyszukać, podsumować, zaproponować, utworzyć szkic, zaktualizować, wysłać, usunąć albo zatwierdzić. Każda może mieć inną kopertę danych i inny limit działania. NIST AI RMF wskazuje na dokumentowanie przeznaczenia, zadań, granic wiedzy, nadzoru i tolerancji ryzyka, natomiast OWASP zaleca minimalizowanie funkcji narzędzi. Traktowanie funkcji jako jednostki kontroli jest praktyczną syntezą tych zasad, a nie formalnym wymogiem którejkolwiek organizacji.

• Zapisz uprawnionych użytkowników i sposób potwierdzania ich tożsamości.
• Nazwij obsługiwane zadania, dozwolone wyniki oraz jawne cele negatywne.
• Przypisz właściciela usługi, ryzyka, dostępu i przekazania sprawy człowiekowi.
• Nie podłączaj narzędzia, dopóki funkcja korzystająca z niego nie ma własnej granicy.

Z jakich informacji może korzystać każda funkcja?

Limit kontekstu powinien być kopertą informacyjną, a nie wyłącznie liczbą tokenów dostępną w modelu. Dla każdej funkcji należy wskazać dozwolone systemy, typy rekordów, klasy informacji, filtry obiektów, przedział czasu, oczekiwaną aktualność, uprawnienia użytkownika oraz dane wykluczone. Jeżeli pracownik może zobaczyć tylko sprawy własnego zespołu, wyszukiwanie asystenta musi zachować tę samą granicę. Większe okno kontekstowe nie tworzy prawa dostępu i nie zmienia niepopartej odpowiedzi w prawdziwą.

Osobnej decyzji wymagają historia bieżącej sesji i pamięć trwała. Trzeba określić, co może zostać zapisane, jak oddziela się użytkowników i sesje, kiedy dane wygasają, jak są usuwane oraz czego nie wolno utrwalać. OWASP zaleca także traktowanie wiadomości, załączników, odpowiedzi API i dokumentów wyszukanych przez system jako niezaufanej treści, która nie może po cichu stać się instrukcją dla usługi. Gdy wymagane źródło jest niedostępne, brakujące albo nieaktualne, asystent powinien odpowiedź zawęzić lub odmówić.

• Źródła i rekordy: które dokładnie obiekty mogą wejść do kontekstu?
• Aktualność: kiedy źródło jest zbyt stare, aby wesprzeć odpowiedź?
• Zaufanie: które treści są danymi, a które instrukcjami usługi?
• Pamięć: co może przetrwać sesję, na jakich zasadach i z jaką izolacją?
• Zakazy: jakie sekrety, dane wrażliwe lub notatki administracyjne pozostają poza funkcją?

Jak tożsamość, narzędzia i uprawnienia egzekwują granicę?

Uwierzytelnienie, autoryzacja i akceptacja muszą pozostać trzema odrębnymi decyzjami. Pierwsza ustala, kim jest użytkownik, klient lub obciążenie systemowe. Druga określa, czy ta tożsamość może wykonać daną operację na chronionym zasobie. Trzecia potwierdza jedną, widoczną propozycję działania. Specyfikacja MCP dobrze ilustruje rozdział ról i minimalnych zakresów w chronionych integracjach MCP, lecz nie jest uniwersalnym projektem każdego narzędzia. Zespół musi też jawnie wybrać między delegowanym dostępem użytkownika a kontrolowaną tożsamością usługi.

Model nie powinien sam przyznawać sobie operacji ani oceniać, czy prompt zezwala na dostęp. Brama narzędziowa i system docelowy muszą sprawdzać używaną tożsamość, dozwolony czasownik, zasób, obiekt, pola, miejsce docelowe, okres ważności poświadczenia i odbiorcę tokenu. Zamiast szerokiego dostępu do skrzynki, bazy, przeglądarki czy powłoki należy wystawić wąską operację z walidowanymi parametrami. Limity szybkości, ponowień, długości łańcucha, partii, kosztu i czasu trzeba dobrać do usługi, bez udawania, że istnieje jeden bezpieczny próg.

• Nie dziedzicz po cichu uprzywilejowanego konta operatora.
• Nie przechowuj tokenów ani sekretów w promptach, historii rozmowy lub pamięci.
• Sprawdzaj każde żądanie w systemie, który faktycznie wykonuje operację.
• Stosuj idempotencję, wycofanie lub bezpiecznik zależnie od charakteru działania.

Rozmowa może być ciągła, ale jej uprawnienia powinny być podzielone na małe, niezależnie egzekwowane funkcje.

Jak duży zakres działania powinna mieć funkcja?

Każda funkcja potrzebuje jawnego pułapu działania, a im bliżej zmiany stanu zewnętrznego, tym silniejsze powinny być niezależne kontrole. Praktyczna drabina redakcyjna prowadzi od odpowiedzi lub podsumowania, przez rekomendację, propozycję i szkic, do ograniczonego odwracalnego zapisu, działania wywołującego istotny skutek oraz decyzji zabronionej. Utworzenie szkicu nie powinno automatycznie oznaczać prawa do wysłania. Podobnie propozycja aktualizacji nie jest zgodą na zmianę rekordu, a odwracalny zapis nie uprawnia do usunięcia danych.

Przed działaniem o istotnym skutku człowiek powinien zobaczyć sprawdzalny podgląd, a system wykonawczy powinien zweryfikować aktora, narzędzie, zasób, znormalizowane parametry, czas i wygaśnięcie akceptacji. Zmiana odbiorcy lub treści po zatwierdzeniu wymaga ponownej walidacji. Akceptacja nie nadaje brakującego uprawnienia, nie poszerza stałego dostępu i nie zmienia decyzji zabronionej w dozwoloną. Płatności, nadawanie dostępu, operacje destrukcyjne, wdrożenia produkcyjne, istotne zobowiązania oraz profesjonalne decyzje wysokiej stawki wymagają właściwej kontroli człowieka i polityki deterministycznej.

1. Odpowiedź lub podsumowanie bez zmiany stanu.
2. Rekomendacja albo widoczna propozycja działania.
3. Edytowalny szkic w miejscu niebędącym kanałem końcowym.
4. Ograniczony, odwracalny zapis w zatwierdzonych polach.
5. Działanie zewnętrzne wymagające autoryzacji i akceptacji konkretnej propozycji.
6. Decyzja zabroniona, której funkcja w ogóle nie udostępnia.

Co powinno się wydarzyć po osiągnięciu granicy?

Odmowa, bezpieczna pomoc częściowa, przekazanie człowiekowi i eskalacja bezpieczeństwa powinny być zaprojektowanymi wynikami usługi z prawdziwym warunkiem zatrzymania. Powód może oznaczać zadanie poza zakresem, niedozwolone informacje, brak autoryzacji, wymaganą akceptację, brakujące lub nieaktualne dowody, potrzebę specjalistycznego osądu, niedostępność zależności, osiągnięcie limitu operacyjnego albo sygnał bezpieczeństwa. Komunikat powinien jasno nazywać granicę, ale nie ujawniać wrażliwych reguł. Asystent nie może twierdzić, że sprawdził źródło, wywołał narzędzie lub zapisał zmianę, jeśli operacja się nie powiodła.

Bezpieczna część pomocy może przyjąć postać szkicu, listy kontrolnej albo prośby o brakujące informacje. Przekazanie powinno zawierać pierwotny cel, istotny niewrażliwy kontekst, podjętą funkcję, powód zatrzymania, dostępne lub brakujące dowody, proponowany następny krok i identyfikator śladu. Zwykła obsługa użytkownika, akceptacja biznesowa i incydent bezpieczeństwa mogą korzystać z podobnego zapisu, lecz mają innych właścicieli i inną pilność. Wykonanie pozostaje zatrzymane do decyzji właściwej osoby, a zmieniona propozycja wraca do walidacji.

• Przekazanie użytkownika trafia do właściciela procesu lub obsługi.
• Akceptacja biznesowa trafia do osoby odpowiedzialnej za skutek działania.
• Sygnał obejścia uprawnień, wyprowadzania danych lub zatrucia pamięci uruchamia osobną ścieżkę bezpieczeństwa.
• Odmowa nie może automatycznie wznowić zmienionej operacji po ogólnym potwierdzeniu człowieka.

Jak przełożyć granice na projekt operacyjny?

Zespół powinien wypełnić jeden wiersz kanwy projektowej dla każdej operacji widocznej dla użytkownika i połączyć go z egzekwowalną kontrolą, zapisem dowodowym, testami, miernikami oraz właścicielem. Wiersz powinien obejmować uprawnionego aktora, sposób uwierzytelnienia, kopertę informacyjną, reguły sesji i pamięci, wąską operację narzędzia, tożsamość wykonawczą, zakres zasobu, pułap działania, akceptację, limity, odmowę, scenariusze ewaluacyjne i adresata eskalacji. Sama dokumentacja nie wystarcza, jeżeli żadna brama ani usługa docelowa nie egzekwuje zapisanej granicy.

Wewnętrzny asystent wsparcia dobrze pokazuje, dlaczego wspólny interfejs rozmowy nie powinien oznaczać wspólnego dostępu. Podsumowanie sprawy, utworzenie odpowiedzi roboczej i wysłanie zatwierdzonej wiadomości korzystają z innych operacji i kończą się innym skutkiem. Każda funkcja potrzebuje osobnych przypadków testowych oraz sygnałów produkcyjnych. NIST AI RMF wspiera jasny podział odpowiedzialności i monitorowanie, a OWASP zaleca zapisywanie decyzji, narzędzi, wyników autoryzacji, identyfikatorów akceptacji i wersji polityk z ograniczaniem danych wrażliwych.

Jakich dowodów wymaga wdrożenie i dalsza eksploatacja?

Dopuszczenie wymaga dowodu, że dozwolona usługa działa w warunkach zbliżonych do produkcji, a oczekiwane odmowy rzeczywiście zatrzymują wykonanie. Zestaw powinien łączyć poprawne zadania z próbami dostępu do cudzego konta, niedozwolonego narzędzia lub zabronionych danych, a także z nieaktualnym źródłem, zatrutą treścią pobraną, obejściem akceptacji, zmianą parametrów, podwójnym ponowieniem, awarią zależności, próbą wyprowadzenia danych i niekontrolowanym łańcuchem narzędzi. Wynik pozytywny nie jest trwałą gwarancją bezpieczeństwa, dlatego testy muszą odpowiadać konkretnemu wdrożeniu.

Zapis operacyjny powinien pozwolić odtworzyć, kto czego zażądał, która funkcja i wersja polityki obowiązywała, jakie klasy źródeł oraz narzędzi wykorzystano, jakie decyzje autoryzacyjne i akceptacyjne zapadły oraz jaki był wynik. Nie oznacza to utrwalania sekretów, pełnych promptów ani nieograniczonego kontekstu wrażliwego. Monitorowanie powinno obejmować nieoczekiwane narzędzia, powtarzające się odmowy, błędy autoryzacji, zmiany akceptacji, nietypowe sekwencje działań, opóźnienia, zużycie zasobów i awarie, z uwzględnieniem prywatności oraz zasad zarządzania dokumentacją.

Właściciel zachowania usługi, administrator dostępów, właściciel przekazań biznesowych i zespół bezpieczeństwa potrzebują odrębnej odpowiedzialności oraz prawa do wstrzymania, zmiany lub wycofania funkcji. Istotna zmiana modelu, promptu, wyszukiwania, pamięci, narzędzia, uprawnienia, polityki, danych, dostawcy albo warunków operacyjnych powinna ponownie otworzyć odpowiednie testy i dowody dopuszczenia. Najbezpieczniejszy kierunek rozwoju to uruchomienie najmniejszej użytecznej funkcji i rozszerzanie jej uprawnień wyłącznie poprzez kontrolowaną zmianę, a nie samą edycję promptu.

• Przed wydaniem potwierdź działanie scenariuszy dozwolonych, odmów, eskalacji i bezpieczników.
• Po wydaniu obserwuj wyniki na poziomie pojedynczej funkcji, a nie tylko całego asystenta.
• Przeglądaj uprawnienia, logi, wyjątki i właścicieli po zmianach wpływających na granicę.
• Włącz właścicieli bezpieczeństwa, tożsamości, prywatności, dokumentacji i ryzyka, gdy funkcja dotyka danych wrażliwych, pamięci trwałej, uprzywilejowanego dostępu lub incydentów.