Instrukcje nie są kontrolą dostępu.

Prompt może kierować zachowaniem. Nie może odebrać uprawnienia.

„Nigdy nie usuwaj danych produkcyjnych.” „Nie wysyłaj e-maila bez zatwierdzenia.” „Odczytuj tylko ten folder.” To rozsądne instrukcje. Mogą ograniczyć przypadkowe zachowanie, gdy model właściwie interpretuje sytuację.

Jeżeli jednak agent nadal posiada poświadczenie pozwalające usunąć bazę danych, wysłać e-mail albo odczytać każdy folder, instrukcja nie zmieniła tego, do czego system jest uprawniony. Poprosiła probabilistyczny komponent, aby sam siebie kontrolował.

Prawdziwa kontrola dostępu istnieje tam, gdzie wykonywane jest działanie: w roli bazy danych, zakresie OAuth, polityce API, granicy systemu plików, usłudze zatwierdzeń albo kontroli autoryzacji w systemie docelowym. Model nie powinien móc przekroczyć tej granicy nawet wtedy, gdy halucynuje, źle rozumie prośbę, podąża za złośliwą treścią lub zostaje bezpośrednio zmanipulowany.

Dlaczego dobre instrukcje nadal zawodzą

Modele językowe tworzą odpowiedzi na podstawie kontekstu. Kontekst może zawierać niejednoznaczność, brakujące fakty, instrukcje adversarialne, zatrute dokumenty, wyniki narzędzi albo wcześniejsze błędy modelu. Nawet dobrze napisany prompt systemowy konkuruje z długim i zmieniającym się łańcuchem informacji.

Awaria nie musi wyglądać spektakularnie. Asystent może źle odczytać, który rekord klienta jest aktywny. Podsumowujący dokumenty może napotkać pośredni prompt injection ukryty w pliku. Agent operacyjny może prawidłowo rozpoznać zadanie, ale wybrać niewłaściwe konto lub środowisko. Model może działać w dobrej wierze i mimo to się mylić.

Kontrole bezpieczeństwa muszą więc zakładać, że model w końcu wygeneruje niepożądaną instrukcję. Zadaniem otaczającego go systemu jest powstrzymanie tej instrukcji przed przekształceniem się w niedopuszczalne działanie.

OWASP nazywa to nadmierną sprawczością

OWASP LLM06:2025 definiuje nadmierną sprawczość jako zdolność systemu opartego na LLM do wykonania szkodliwych działań po nieoczekiwanej, niejednoznacznej lub zmanipulowanej odpowiedzi modelu. Wskazuje trzy główne przyczyny:

Zbuduj granicę poza modelem

Najbezpieczniejszym wzorcem nie jest sprytniejsze ostrzeżenie, lecz mniejsza powierzchnia możliwości. Daj agentowi minimalny zestaw narzędzi, funkcji, danych i uprawnień niezbędnych do aktualnego zadania.

Pięć kontroli, które realnie ograniczają zasięg błędu

1. Usuń możliwości, których proces nie potrzebuje.

   Podsumowujący dokumenty potrzebuje odczytu, nie wysyłania i usuwania. Generator oferty potrzebuje tworzenia szkicu, nie uprawnienia do realizacji zakupu.

2. Używaj wąskich poświadczeń przypisanych do zadania.

   Utwórz osobną tożsamość dla agenta. Ogranicz ją do konkretnych tabel, skrzynek, repozytoriów, działań i środowiska potrzebnych do zadania.

3. Wymagaj zatwierdzenia na granicy działania.

   Działania o dużym wpływie powinny stawać się oczekującymi żądaniami. Zatwierdzenie należy do rozszerzenia lub systemu docelowego, gdzie model nie może go pominąć.

4. Wykonuj działania w kontekście użytkownika.

   Gdy agent działa w imieniu osoby, zachowaj zakres jej autoryzacji zamiast kierować każde żądanie przez jedno uprzywilejowane konto usługowe.

5. Loguj, ograniczaj tempo i zapewnij prawdziwe odzyskiwanie.

   Te kontrole nie zapobiegają nadmiernej sprawczości, ale skracają czas wykrycia i ograniczają szkody. Kopie zapasowe muszą być odizolowane od tego samego poświadczenia i ścieżki awarii.

Bramki zatwierdzeń powinny odpowiadać konsekwencji

Zatwierdzenie przez człowieka nie jest potrzebne dla każdego działania. Potwierdzanie odczytu publicznego FAQ uczyniłoby system bezużytecznym. Bramka powinna pojawić się tam, gdzie konsekwencję trudno odwrócić albo dotyczy innej osoby.

O co zapytać przed podłączeniem agenta

• Jakie dokładnie działania może wykonać agent—nie tylko, jakich działań ma nie wykonywać według instrukcji?
• Jakiej tożsamości i jakich zakresów używa każde narzędzie?
• Czy agent może bezpośrednio dotrzeć do produkcji?
• Które działania wymagają zatwierdzenia i czy model może ominąć tę ścieżkę?
• Czy system docelowy wymusza kontrolę autoryzacji przy każdym żądaniu?
• Czy z sesji jednego klienta można dotrzeć do kontekstu lub danych innego klienta?
• Czy kopie zapasowe są odizolowane od poświadczeń zdolnych do zmiany produkcji?
• Czy operatorzy potrafią odtworzyć, co model zobaczył, zdecydował i próbował wykonać?

Standardy przesuwają się w stronę tożsamości i autoryzacji

Wskazówki OWASP dotyczące ograniczania ryzyka koncentrują się na minimalizowaniu rozszerzeń, funkcjonalności, uprawnień i autonomii; wykonywaniu narzędzi w kontekście użytkownika; wymaganiu zatwierdzeń; oraz wymuszaniu autoryzacji po stronie systemu docelowego zamiast proszenia LLM o ocenę, czy działanie jest dozwolone.

Inicjatywa NIST AI Agent Standards Initiative podobnie wskazuje uwierzytelnianie agentów, infrastrukturę tożsamości, protokoły autoryzacji i ewaluację bezpieczeństwa jako fundamenty bezpiecznego wdrażania agentów. Kierunek jest jasny: godna zaufania sprawczość zależy od egzekwowalnej tożsamości i polityki wokół modelu.