Wyobraź sobie, że w instrukcji dla agenta AI piszesz wielkimi literami: „NIE WYSYŁAJ e-maili do klientów”. Brzmi jak zabezpieczenie. Nie jest. To prośba — a agent traktuje prośby tak samo jak każdą inną linijkę tekstu, czyli z dobrą wolą i bez gwarancji. Jeśli ma dostęp do skrzynki, pewnego dnia z niej skorzysta. Pokażę ci, dlaczego prawdziwą granicą nie są słowa, tylko klucze, które agent fizycznie trzyma w ręku — i jak nadawać te klucze tak, żeby spać spokojnie.
Prompt to nie jest zabezpieczenie
Zacznę od pojęć, żeby nikt się nie zgubił. Agent AI to program, który nie tylko odpowiada na pytania, ale wykonuje zadania za ciebie — czyta dokumenty, wysyła wiadomości, zmienia wpisy w systemach. Prompt to instrukcja, którą mu dajesz słowami: „zrób to, nie rób tamtego”. A klucz (po angielsku często „credential” albo „API key”) to coś znacznie konkretniejszego — to dostęp, który pozwala agentowi naprawdę wejść do danego narzędzia i coś w nim zrobić. Klucz albo agent ma, albo nie ma.
I tu jest sedno, które wielu osobom umyka: prompt nigdy nie jest warstwą uprawnień. Kiedy piszesz w instrukcji „nie kasuj rekordów”, opierasz całe bezpieczeństwo na tym, że model za każdym razem dobrze cię zrozumie i posłucha. To nie jest blokada — to nadzieja. A nadzieja nie jest strategią, kiedy po drugiej stronie jest system, który działa szybko, na dużą skalę i bez przerwy.
Moim zdaniem to najczęstszy błąd, jaki widzę u osób zaczynających z automatyzacją: mylą opis intencji z realnym ograniczeniem. Opis intencji mówi agentowi, czego chcesz. Realne ograniczenie decyduje, co agent może. Tylko to drugie cię chroni.
„Jeśli może, to zrobi”
Jest jedno założenie, które warto przyjąć raz na zawsze i już nigdy z niego nie schodzić: jeśli agent coś może, to prędzej czy później to zrobi. Nie dlatego, że jest złośliwy — agenci nie mają złych intencji. Po prostu każda zdolność, którą mu dasz, zostanie kiedyś użyta: czasem celowo, częściej przez nieporozumienie.
Jeśli agent może wysłać e-mail, pewnego dnia wyśle taki, którego nie planowałeś. Jeśli może skasować rekord w bazie — załóż, że go skasuje. To nie pesymizm, tylko trzeźwa kalkulacja. Projektujesz wtedy nie pod scenariusz, w którym wszystko idzie dobrze, ale pod ten, w którym coś zostaje źle odczytane.
A to się naprawdę zdarza. Klasyczny scenariusz wygląda tak: agent pracuje przez listę zadań, sam je po kolei podejmuje i wykonuje. Przy jednym z nich źle interpretuje polecenie — myśli, że ma rozesłać kod rabatowy, choć wcale nie o to chodziło. I robi to. Na skalę, na jaką został podłączony: do setek tysięcy odbiorców z listy mailingowej, zanim ktokolwiek zdąży zareagować. Jeden źle zrozumiany wiersz na liście, jedno działanie wykonane natychmiast i masowo.
Zwróć uwagę, gdzie tu leży problem. Agent nie „zhakował” niczego. Zrobił dokładnie to, co potrafił zrobić, bo miał do tego klucz. Gdyby nie miał dostępu do wysyłki — żadne błędne zrozumienie zadania nie skończyłoby się katastrofą. Najwyżej zatrzymałby się i zapytał.
Klucze, nie prompty
Stąd zasada, którą uważam za fundament całego bezpieczeństwa agentów: dajesz agentowi tylko klucze do tych pokoi, do których naprawdę musi wejść.
Wyobraź sobie budynek z wieloma pokojami. W jednym jest wysyłka e-maili, w drugim baza klientów, w trzecim ustawienia zespołu. Agent dostaje pęk kluczy — i może otworzyć dokładnie tyle drzwi, ile kluczy mu wręczyłeś. Jeśli nie ma klucza do pokoju „wyślij e-mail”, to bez znaczenia, jak źle odczyta zadanie: do tego pokoju po prostu nie wejdzie. Granica nie zależy już od tego, czy model dobrze zrozumiał polecenie. Zależy od tego, co fizycznie potrafi otworzyć.
W świecie technologii ta zasada ma swoją nazwę: least privilege, czyli zasada minimalnych uprawnień. W zwykłych słowach brzmi tak: każdemu narzędziu — i każdemu agentowi — dajesz najwęższy możliwy zakres dostępu, jaki wystarcza do jego zadania. Ani jednego klucza więcej. Nie dlatego, że nie ufasz agentowi, tylko dlatego, że nie chcesz polegać na zaufaniu tam, gdzie wystarczy zwykła blokada.
To samo dotyczy ludzi w zespole, więc analogia jest intuicyjna. Nowemu współpracownikowi nie dajesz od pierwszego dnia dostępu do wszystkiego „na wszelki wypadek”. Dajesz mu dokładnie to, czego potrzebuje do swojej roli. Z agentem postępujesz tak samo — z tą różnicą, że agent działa szybciej i na większą skalę, więc nadmiarowy klucz boli bardziej.
Klucze o wąskim zakresie
Klucze nie są zero-jedynkowe. Nie musisz wybierać między „pełny dostęp” a „żaden dostęp” — możesz nadać klucz, który otwiera tylko jedną szufladę w pokoju, a reszty nawet nie dotyka. To klucze o wąskim zakresie (po angielsku „scoped credentials”).
Weź konkretny przykład. Powiedzmy, że agent ma korzystać z zapisów twoich spotkań — transkryptów. Zamiast dawać mu pełny dostęp do narzędzia, w którym te transkrypty żyją, nadajesz klucz, który potrafi tylko jedno: odczytać transkrypty. Nie może ich edytować. Nie może ich skasować. Nie ma wglądu w ustawienia zespołu ani w nic poza tym, co mu wyznaczyłeś. Jeden klucz, jedna zdolność: czytaj transkrypty i tyle.
Tak właśnie buduje się prawdziwą warstwę uprawnień — nie zdaniem w instrukcji, tylko zakresem klucza. Zasada jest prosta i warto ją powtarzać przy każdym nowym połączeniu: dobierz zakres każdego klucza do najwęższej zdolności, która jest faktycznie potrzebna. Zanim podłączysz agenta do kolejnego narzędzia, zadaj sobie jedno pytanie: czego naprawdę musi tu móc, a co tylko byłoby „wygodne”? Wygoda zwykle oznacza nadmiar uprawnień — a nadmiar uprawnień to dokładnie te klucze, których nie chcesz mu dawać.
Autonomię się zarabia, nie nadaje z automatu
Jest jeszcze jedna pokusa, której warto się oprzeć: chęć, by od razu puścić agenta luzem, żeby działał sam, najlepiej także wtedy, gdy śpisz. To kuszące — i właśnie dlatego niebezpieczne. Autonomię agenta się zarabia, a nie nadaje domyślnie.
Im więcej automatyzujesz i im więcej swobody oddajesz agentowi, tym wyżej rosną trzy rzeczy naraz: koszt, ryzyko i utrzymanie. Dlatego nie dawaj agentowi „żywych” kluczy — tych, które naprawdę coś robią w prawdziwych systemach — dopóki jego rutyna nie jest sprawdzona w boju. Najpierw obserwujesz, jak działa pod twoim okiem, na bezpiecznych danych. Dopiero gdy raz za razem robi to, co trzeba, oddajesz mu kawałek autonomii.
I rzecz, o której łatwo zapomnieć: automatyzacja nie kończy twojej odpowiedzialności. Większa autonomia agenta nie znaczy „odhaczone, mogę zapomnieć”. Za każdą automatyzację ktoś odpowiada — ktoś ma nad nią właścicielstwo, zagląda do niej i wie, czy nadal robi to, co miała robić. Oddajesz agentowi działanie, ale nie oddajesz mu widoczności nad tym, co się dzieje. To zostaje po twojej stronie.
Na koniec — najważniejsza zmiana w sposobie myślenia. Kiedy agent się pomyli (a pomyli się), nie zaklejaj objawu i nie udawaj, że nic się nie stało. Potknięcia to dane. Każdy błąd mówi ci dokładnie, który klucz był za szeroki albo która instrukcja zbyt nieostra. Zawężasz wtedy zdolność lub doprecyzowujesz polecenie tak, żeby ten sam błąd nie mógł się powtórzyć — i traktujesz to jako lekcję, nie jako porażkę. System staje się dzięki temu coraz mocniejszy, a nie coraz bardziej kruchy.
Bo zaufanie do agenta nie bierze się z tego, jak ładnie go poprosiłeś. Bierze się z tego, czego ten agent fizycznie nie może zrobić. Następnym razem, gdy będziesz podłączać agenta do kolejnego narzędzia, nie zaczynaj od instrukcji. Zacznij od pytania o klucz: jaki najwęższy dostęp tu wystarczy — i czy potrafisz mu dać dokładnie tyle, ani jednego klucza więcej.