Zdanie w prompcie jest życzeniem. Odcięty ruch wychodzący jest faktem. Cała reszta tego artykułu wynika z tej różnicy.
Najczęstszy sposób ograniczania agenta polega na napisaniu mu, czego ma nie robić. Nie sięgaj do produkcji. Nie wysyłaj niczego na zewnątrz. Nie modyfikuj plików poza katalogiem roboczym.
To działa dokładnie tak długo, jak długo nie występuje sytuacja, w której zakazana droga jest jedyną drogą do celu. Agent poproszony o dane, których nie ma, będzie ich szukał każdą dostępną drogą — nie ze złej woli, tylko dlatego, że dostał zadanie i próbuje je wykonać.
Zakaz w prompcie konkuruje z zadaniem w prompcie. Czasem wygrywa, czasem nie, i nie wiadomo z góry kiedy.
Dlaczego graf zmienia stawkę
W pętli był jeden wykonawca z jednym zestawem uprawnień. Ograniczenie polegało na tym, co mu dałeś — a czego nie dałeś, tego nie miał.
W grafie wykonawców jest kilku i każdy potrzebuje czegoś innego. Węzeł badawczy potrzebuje internetu. Węzeł redagujący nie. Węzeł zapisujący potrzebuje dostępu do bazy, ale tylko do zapisu wyniku, nie do odczytu wszystkiego.
Jeśli nadasz wszystkim ten sam zestaw — a to jest domyślne, bo prościej — to uprawnienia całego grafu są sumą uprawnień wszystkich węzłów, i każdy z nich może zrobić wszystko, co może zrobić najbardziej uprzywilejowany.
Wtedy podział na role istnieje wyłącznie w prompcie. Czyli w warstwie, która jest życzeniem.
Heterogeniczność jako konsekwencja, nie funkcja
Tu jest własność architektoniczna, którą warto zobaczyć, bo bywa opisywana jako ograniczenie, a jest przewagą.
Jeśli każdy węzeł uruchamiany jest jako osobny proces — z własnym środowiskiem, katalogiem roboczym i konfiguracją — to różne modele, różni dostawcy i różne polityki sieciowe per węzeł nie są funkcją, którą ktoś musiał zaimplementować. Są konsekwencją tego, jak zbudowano wykonanie.
Scenariusz, który z tego wynika i którego nie złożysz w stosie jednego dostawcy:
Większość zespołu — role analityczne, redakcyjne, kontrolne — działa na modelu lokalnym, na plikach, w kontenerze bez wyjścia do sieci. Jeden węzeł ma dostęp do internetu, odpytuje publiczne źródła i zapisuje wyniki do współdzielonego katalogu. Węzeł analizujący czyta ten katalog i nie ma jak niczego wysłać, bo jego kontener nie ma ścieżki na zewnątrz.
Zwróć uwagę, gdzie mieszka granica. Nie w instrukcji dla węzła analizującego. W braku trasy.
Cztery warstwy, na których da się postawić granicę
W kolejności od najsłabszej do najmocniejszej.
Prompt. Zakaz sformułowany słowami. Konkuruje z zadaniem, więc bywa przegrywa. Użyteczny jako wskazówka, bezużyteczny jako zabezpieczenie.
Zestaw narzędzi. Węzeł nie dostaje narzędzia, którego nie ma używać. Znacznie mocniejsze, bo agent nie wywoła czegoś, czego nie ma na liście. Ograniczenie: narzędzia bywają szersze, niż potrzeba — jedno wykonaj_zapytanie obejmuje i odczyt, i DROP TABLE.
Uprawnienia po stronie zasobu. Konto z prawem odczytu, klucz z ograniczonym zakresem, katalog tylko do odczytu. Granica przestaje zależeć od tego, co agent wywoła, a zaczyna od tego, na co pozwoli druga strona.
Izolacja infrastrukturalna. Kontener bez trasy do sieci, sieć wydzielona, brak montowania katalogów spoza obszaru roboczego. Agent może chcieć, może wywołać, może dostać token — i nadal nie ma jak.
Praktyczna zasada: granicę stawiaj tak nisko, jak się da przy zachowaniu funkcjonalności. Prompt niech tłumaczy, dlaczego czegoś nie robimy. Infrastruktura niech pilnuje, żeby się nie dało.
Budżet jako warunek uruchomienia
Ten sam mechanizm w wymiarze kosztowym, i ta sama różnica.
Sprawdzenie limitu przed uruchomieniem węzła jest granicą. Raport o przekroczeniu po fakcie jest sprawozdaniem.
W pętli koszt widziałeś na końcu i mogłeś ją zabić w każdej chwili. W grafie węzły mogą budzić się cyklicznie z kolejki, więc nie ma jednego momentu, w którym ktoś patrzy. Bez limitu sprawdzanego przed startem dowiesz się o problemie z faktury — a to jest ten syndrom, który u ciebie w Patologii nazywa się „rachunek eksplodował, a nic się nie zmieniło”.
Trzy poziomy, na których warto to mieć, bo każdy łapie co innego:
Na zadanie — sufit dla całej sprawy. Chroni przed jednym zadaniem, które wymknęło się spod kontroli.
Na węzeł — sufit dla pojedynczego wykonawcy w pojedynczym uruchomieniu. Chroni przed węzłem, który kręci się w kółko.
Na okno czasu — sufit dla całego grafu w ciągu godziny albo doby. Chroni przed sytuacją, w której każde pojedyncze zadanie mieści się w limicie, a jest ich nagle tysiąc.
Trzeci bywa pomijany i jest tym, który ratuje przy pętli sprzężenia zwrotnego — gdy wynik jednego zadania tworzy kolejne.
Zastrzeżenie, którego nie wolno pominąć
Wszystko powyżej opiera się na założeniu, że warstwa egzekwująca granice jest sama zabezpieczona.
Hamulec zewnętrzny jest wart tyle, ile zabezpieczenie panelu, który nim steruje. Opisywaliśmy na cyberflux.pl łańcuch wywołań dający nieuwierzytelnionemu atakującemu kontrolę nad instancją orkiestratora — a więc również nad wszystkimi budżetami, limitami i przypisaniami uprawnień, które w niej ustawiono.
To nie jest argument przeciwko orkiestratorom. To jest argument za tym, żeby traktować panel orkiestracji jak system o uprawnieniach administracyjnych, bo nim jest — niezależnie od tego, że w interfejsie wygląda jak narzędzie do zarządzania zadaniami.
Jak to sprawdzić u siebie
Test, który nie wymaga narzędzi: przy każdym węźle dopisz, czego mu nie wolno — i na której warstwie to jest egzekwowane.
| Węzeł | Czego nie wolno | Gdzie stoi granica |
|---|---|---|
| prompt / narzędzia / uprawnienia / izolacja |
Trzy sygnały do wychwycenia:
Jeśli przy którymś węźle w trzeciej kolumnie wpisujesz wyłącznie „prompt” — to węzeł bez granicy, tylko z prośbą.
Jeśli przy którymś nie umiesz nic wpisać w drugiej kolumnie — to znaczy, że wolno mu wszystko, i to jest świadoma decyzja albo przeoczenie. Warto wiedzieć która.
Jeśli wszystkie węzły mają identyczną drugą kolumnę — nie masz ról, masz jeden zestaw uprawnień rozdany kilku procesom.
I jeden test wykonawczy, który zajmuje kwadrans: weź węzeł, który nie powinien mieć dostępu do sieci, i każ mu pobrać stronę. Jeśli mu się uda, granica była w prompcie.
Co dalej
Granice omówione dotyczą tego, co węzeł może zrobić sam. Zostaje typ węzła, którego uprawnienia działają odwrotnie: nie ogranicza go infrastruktura, tylko czyjaś uwaga — a uwaga ma tę własność, że wyczerpuje się z użyciem.
O tym jest artykuł ósmy: Człowiek jako węzeł.
Stan na sierpień 2026. Podział na cztery warstwy egzekwowania jest uogólnieniem — poszczególne narzędzia orkiestrujące udostępniają je w różnym zakresie, a część wyłącznie na dwóch najwyższych poziomach.
