TL; DR
Trzy odpowiedzi na to samo pytanie dotyczące ryzyka związanego ze sztuczną inteligencją agentową
Spodziewaliśmy się szerokiego porozumienia w kwestii ograniczania agentów AI, a otrzymaliśmy trzy różne odpowiedzi.
- Pedro Fortuna: podziel agentów na wiele małych, szczegółowych jednostek, przypisując każdemu możliwie najwęższe uprawnienia, i dodaj monitorowanie czasu wykonania, które zatrzyma ich działanie na wczesnym etapie.
- Jack Trefon: Wręcz przeciwnie, dla agentów kodujących. Ograniczając jednego, niszczysz to, co czyni go użytecznym, więc zaakceptuj promień rażenia i zainwestuj w śledzenie i szybkie odzyskiwanie.
- Luis Rodríguez Berzosa: trzecia linia. Traktuj modele graniczne tak, jak traktujesz złośliwe oprogramowanie, zaprojektuj uprząż tak, aby ograniczała każdego wyspecjalizowanego agenta i umieść pod nimi warstwę egzekwowania, która będzie obowiązywać, gdy wszystko powyżej zawiedzie.
Gdzie spotkali się wszyscy trzej: nie można chronić czegoś, czego się nie zinwentaryzowało, każda czynność musi zostać zarejestrowana, a czynnik, który zatrzymuje agenta musi znajdować się poza nim.
Nic nie zostało naruszone.
Agent wykonał swoje zadanie. Po drodze zdecydował, że musi dotknąć zależności, konfiguracji, usługi, o której dotykanie nikt go nie prosił. Przez cały czas pozostawał w ramach swoich uprawnień. Żadna reguła nie została naruszona, więc nic nie zostało uruchomione.
Przedstawiliśmy tę sprawę trzem osobom, które zajmują się nią zawodowo, oczekując szerokiego porozumienia co do dalszych działań. Otrzymaliśmy trzy różne odpowiedzi, z których dwie są ze sobą sprzeczne.
Ryzyko związane z agentową sztuczną inteligencją (AI) zazwyczaj opisuje się jako problem atakującego. To jest inna wersja. Przez dwadzieścia lat wyznaczaliśmy granice uprawnień dla oprogramowania, które wykonywało dokładnie to, co mu nakazano. Konto usługi, program do ciągłej integracji (CI), zaplanowane zadanie. Często myliliśmy się w ustalaniu granic, ale to, co się w nich znajdowało, było przewidywalne. Za każdym razem wykonywało jedno zadanie w ten sam sposób.
Teraz decyduje to, co znajduje się wewnątrz granicy. A granica jest nadal wyznaczana tak, jak zawsze: z wyprzedzeniem, w momencie konfiguracji, przez kogoś, kto nie może wiedzieć, w co zadanie się przekształci.
To jest wersja ryzyka związanego z agentową sztuczną inteligencją, o której warto dyskutować, i poświęciliśmy jej godzinę w ostatnim Dyskusja SafeDev w Pedro Fortuna z Jscramblera, Jack Trefon Trefon Digital Consulting i Luis Rodríguez Berzosa Xygeni, którego gospodarzem jest Alejandro Estrada.
Spodziewaliśmy się, że będą generalnie zgodni. Nie byli.
Ryzyko związane z agentową sztuczną inteligencją: pocieszająca przesłanka, która się nie sprawdza
W powyższym sformułowaniu jest słowo, które wykonuje więcej pracy, niż powinno: napastnik. Nie ma żadnego. To ma ułatwić sytuację.
Pedro rozłożył to na części jednym ruchem.
„Bycie atakującym czy nie, to ludzka koncepcja. To, co czyni atakującego atakującym, to fakt, że ma inne cele. A agent, który nie jest zsynchronizowany, również ma inny cel”.
Poczekaj z tym, bo to podważa założenia większości rozmów o ryzyku związanym z SI, w tym opis, który stworzyliśmy dla naszego własnego zdarzenia. Jeśli atakującego definiują rozbieżne cele, a nie złośliwość, to „w tej historii nie ma atakującego” jest pocieszeniem, na które nikt nie zasłużył. Strukturalnie rzecz biorąc, to to samo ryzyko. Brakuje intencji, a intencja nigdy nie była tym, co wykrywały twoje elementy sterujące. Wykrywają skutki. Zawsze to robiły.
To również powód, dla którego słownictwo branży uległo zmianie. OWASP 10 najlepszych aplikacji na studia LLM w 2026 r. awansowała nadmierną agencję z szóstego na trzecie miejsce, co nie jest zmianą opinii, a raczej dorównaniem rekordowi incydentów architekturze, która została już wdrożona.
Co tak naprawdę pokazuje incydent z Hugging Face
Incydent z lipca, w którym modelka z pogranicza zaatakowała osobę trzecią, został powszechnie odczytany jako historia o modelce, która zbuntowała się. Luis interpretuje to inaczej, a jego wersja obarcza odpowiedzialnością niewygodne miejsce.
„Problemem nie jest model graniczny. Model graniczny wykonał to, co mu zlecono. Problemem jest projekt eksperymentu”.
Cel był otwarty. Ograniczenia nie istniały. A piaskownica, która miała go pomieścić, miała okno na internet, poprzez lukę w zabezpieczeniach podatności na fałszowanie żądań po stronie serwera w pamięci podręcznej pakietów, do której agent mógł dotrzeć. Każdy z nich to projektcisjon wytwarzany przez człowieka.
Co prowadzi do zdania, które powinno zmienić sposób, w jaki zapewniasz te rzeczy:
„Modele graniczne należy traktować jak złośliwe oprogramowanie, ponieważ mogą działać autonomicznie i podejmować decyzjecisJony, które są złośliwe. Nie celowo, ale w efekcie są naprawdę złośliwe.
Nie jako obraza dla modelu. Jako postawa provisioningowa. Nie przekazujesz złośliwemu oprogramowaniu powłoki bash z nadzieją, że cel został dobrze określony.
Według Pedra ten sam incydent był bardziej kwestią czasu niż planu:
„W chwili, gdy zobaczysz agentów komunikujących się za pomocą nazw folderów w usłudze, z której nie powinni korzystać, musisz ich powstrzymać. Nie musisz czekać, aż agenci z powodzeniem złamią zabezpieczenia Hugging Face, żeby ocenić, czy to złośliwe”.
Warto również zachować pewien szczegół z odpowiedzi. Respondenci próbowali użyć komercyjnego narzędzia agenta do analizy śladów, ale nie udało im się to, ponieważ osiągnęli limity. Atakujący nie miał takiego pułapu. „W samym ataku występowała asymetria”.
Prawdziwy argument: ograniczyć agenta czy szybciej odzyskać sprawność?
W tym miejscu panel się podzielił i pojawił się prawdziwy rozdźwięk między praktykami, z których każdy wypracował sobie swoje stanowisko.
Pedro opowiada się za rozkładem. Piętnaście lat izolacyjnych działań w przeglądarce nauczyło go, że nie da się niczego wymusić w czasie wykonywania na monolicie. Wystarczy podzielić architekturę na małe fragmenty z konkretnymi funkcjami, a dopiero wtedy elementy sterujące i punkty monitorujące będą miały gdzie się podłączyć. Nie inaczej jest z agentami.
„Myślę, że trzeba to rozbić na bardzo konkretnych agentów, którzy są przeznaczeni tylko do konkretnych zadań. I nie ma znaczenia, czy w końcu będzie ich pięćdziesięciu. To lepsze niż jeden.”
Jack twierdzi coś przeciwnego, zwłaszcza w odniesieniu do agentów kodujących. Można by się spodziewać, że technologia działająca w tle na regulowanej giełdzie kryptowalut będzie miała najbardziej restrykcyjne stanowisko w tym pomieszczeniu. A jednak wygenerowała najmniej.
Jego wyjściowa analogia wcale nie jest modelem zagrożenia:
„Patrzę na typowe rozmieszczenie agentów tak, jak na nowo zatrudnionego pracownika, nową osobę, która przychodzi do pracy. Osoba ta może być bezbłędna w realizacji zadań, ale może też popełnić błąd. Nie widzę dużej różnicy”.
W przypadku agentów o wąskim profilu jest równie surowy, jak wszyscy inni. Opisując agenta recenzji tylko do odczytu, którego obecnie buduje, stwierdził wprost, że typowa konfiguracja jest nie do obrony: wdrożenie na zwykłym komputerze z Linuksem i dostępem do bash „otwiera cały ekosystem zagrożeń”. Jednak w przypadku agentów zajmujących się kodowaniem ogólnym logika się odwraca i zdaje sobie sprawę, że takie stanowisko jest niepopularne:
„Im większa władza agenta, tym bardziej jest kreatywny i skuteczny. Zatem to nie branża prosperuje dzięki ograniczeniom i zawężaniu zakresu”.
Co więc zostaje, jeśli nie wprowadzisz ograniczeń? Wyłączniki, a przede wszystkim migawki oparte na czasie: nie zapobiegają promieniowi wybuchu, ale sprawiają, że odzyskanie go jest tanie i szybkie. Wbudowuje to w… Bursztyn, niezależna od zależności uprząż agentów C++, którą pisze w wolnym czasie, z funkcją tworzenia migawek w pętli (Strona projektu).
I ostrzeżenie gdzie kończy się druga ścieżka:
„Jeśli zaczniemy zabierać, zostanie tylko jedno narzędzie, a ten deweloper będzie mógł włączać i wyłączać światła”.
Luis zajmuje trzecie miejsce, który nie jest ani ograniczeniem, ani odzyskiwaniem, lecz powstrzymywaniem od dołu: załóżmy, że agent ostatecznie będzie zachowywał się jak złośliwe oprogramowanie, zaprojektujmy uprząż tak, aby ograniczała każdego wyspecjalizowanego agenta i umieśćmy pod nimi warstwę egzekwowania, która będzie obowiązywać, gdy wszystko powyżej zawiedzie.
Trzy podejścia do tego samego problemu
Trzy stanowiska, każde z nich wiąże się z kosztami. Żadne z nich nie jest darmowe i żadne z nich nie zapewnia agentowi bezpieczeństwa.
| Podejście | Główny ruch | Ile to Cię kosztuje |
|---|---|---|
| Rozkładać sięPedro Fortuna | Wiele małych agentów, każdy z wąskimi uprawnieniami, plus monitorowanie czasu wykonania, które zatrzymuje ich na wczesnym etapie | Wymaga wysiłku projektowego na początku i trudniej jest pracować nad otwartym kodowaniem |
| RecoverJack Trefon | Zachowaj możliwości, dodaj wyłączniki i migawki oparte na czasie, aby wycofanie było tanie | Szerszy promień wybuchu i obstawianie wykrycia i cofnięcia go w odpowiednim czasie |
| Zawiera od dołuLuis Rodríguez Berzosa | Załóż, że występuje zachowanie złośliwego oprogramowania, ogranicz każdego agenta w uprzęży, wymuś jego działanie na stacji roboczej i urządzeniu uruchamiającym CI | Infrastruktura i narzędzia, których większość stosów punktów końcowych jeszcze nie zapewnia |
Czytając je obok siebie, różnica zdań jest węższa, niż się wydaje. Wszystkie trzy strony zgadzają się, że agent zrobi coś niezamierzonego. Różnią się co do tego, gdzie trafią pieniądze: do architektury przed jej powstaniem, do odbudowy po jej powstaniu, czy na piętro pod nimi.
Dlaczego najmniejsze uprawnienia nie przekładają się na ryzyko związane z agentową sztuczną inteligencją
Najmniejsze uprawnienia zakładają, że znasz zadanie. Ty określasz zakres uprawnień do zadania.
Agent łamie to po cichu, ponieważ granica jego uprawnień jest wyznaczana w momencie konfiguracji, a zadanie pojawia się w czasie wykonywania. To, co faktycznie przyznajesz, to suma wszystkiego, o co mógłby zostać poproszony. To nie jest najmniejszy przywilej; to jego przeciwieństwo, ubranie najmniejszego przywileju.
Luis zaproponował nowe ujęcie tematu zapożyczone z idei starszej niż którakolwiek z tych:
„Myślę o mechanizmie UNIX-a, który polega na łączeniu prostych narzędzi w celu wykonania złożonego zadania. Można zdefiniować konkretnych agentów z kontrolowaną konfiguracją, ograniczając zakres działania danego wyspecjalizowanego agenta. Można ich też łączyć w celu realizacji niemal każdego zadania”.
A oto drugi pomysł na projekt, którego większość zespołów nie wypróbowała: zawijaj narzędzia zamiast rozszerzać uprawnienia. Nie bash, który przekazuje cały system, ale wąski wrapper, który jest jedyną możliwą do wywołania ścieżką, z wariantami tylko do odczytu, które opakowują warianty generyczne. Agent otrzymuje zdolność, a nie powłokę.
Wyraził również jasno, że przeszkodą nie jest projekt, lecz wdrożenie. Nowe elementy sterujące na komputerach deweloperskich mają długą historię obchodzenia ich i ta historia się nie zmienia, ponieważ narzędzie, o którym mowa, jest agentem.
I o tym, gdzie jego zdaniem to wszystko się skończy:
„Myślę, że na końcu będziemy mieli autonomicznych agentów kontrolujących innych autonomicznych agentów”.
Laptop stał się klejnotem koronnym, a Twój EDR tego nie zauważył
Agent potrzebuje stałego dostępu, aby być użytecznym. Token, który nie traci ważności w trakcie zadania, buforowane dane uwierzytelniające, uprawnienia do przesyłania, dostęp do rejestru, aktywna ścieżka do pipelineKażdy z nich jest wymogiem, a nie przeoczeniem, co oznacza, że im lepsze były narzędzia, tym bardziej skoncentrowana stawała się maszyna programistyczna.
Atakujący zauważyli to pierwsi. Jak to ujął Pedro, nie są ideologami:
„Organizują się jak małe firmy. Muszą zarabiać, więc szukają najbardziej dochodowego rozwiązania, jakie uda im się znaleźć. I szybko zauważyli, że na stacjach deweloperskich można zarobić”.
Co tydzień obserwujemy, jak ta zmiana ląduje w rejestrach Streszczenie złośliwego kodu, gdzie narzędzia do zbierania poświadczeń obecnie rutynowo polują na klucze dostawców sztucznej inteligencji, obok kluczy chmurowych i rejestrowych.
Jego lista środków zaradczych jest mało efektowna i działa: usuń wszystkie klucze, które nie muszą znajdować się na komputerze, sparuj te, które pozostały, z drugim czynnikiem uwierzytelniania, takim jak OpenID Connect lub klucz sprzętowy, dzięki czemu sam skradziony token nie wystarczy, a następnie przenieś środowisko poza hosta, gdzie to możliwe, za pośrednictwem kontenerów deweloperskich lub środowisk IDE w chmurze.
Następnie Luis poruszył kwestię, która powinna zaniepokoić każdego, kto zakłada, że jego stos punktów końcowych to obejmuje:
„EDR-y specjalizują się w tradycyjnym złośliwym oprogramowaniu i nie są świadome narzędzi agentowych. A jeśli działają, mogą generować wiele fałszywych alarmów, ponieważ agent wykonuje czynności, których wzorce detekcji nie są obecnie świadome”.
Dwa tryby awarii jednocześnie: pomija to, co istotne, i sygnalizuje to, co nieistotne. Jego odpowiedź brzmi: ta zewnętrzna warstwa egzekwowania, otaczająca stację roboczą programisty i program CI Runner, poniżej uprzęży, ograniczająca zasięg nieuczciwego agenta. To jest ta luka. Xygeni Shield został stworzony z myślą o wymuszeniu zasad na punkcie końcowym, na którym faktycznie odbywa się instalacja.
Jack ujął to bardziej dosadnie: nie trzymaj Bitcoinów na komputerze deweloperskim.
Wszyscy trzej zgodzili się na ten temat
Trzy różne odpowiedzi, jedno wspólne minimum.
- Najpierw inwentaryzacja. „Nie możesz chronić czegoś, o czym nie wiesz”. Każdy inny decisDziałanie jonu opiera się na wiedzy o tym, którzy agenci, umiejętności i serwery MCP istnieją, a prawie żaden z nich nie został zadeklarowany.
- Rejestruj każdą czynność. Jack i Luis przybyli tu z przeciwnych kierunków. Jack chce śladów, ponieważ to one pomagają w powrocie do zdrowia i dojrzewaniu organizacji. Luis chce ich, ponieważ bez nich nie da się później odtworzyć promienia rażenia. Warto zapożyczyć ujęcie Jacka: nie ma sensu przesłuchiwać aktora, człowieka czy agenta, tylko zrozumieć kontekst na tyle dobrze, by go nie powtarzać.
- Rzecz, która zatrzymuje agenta musi znajdować się poza nim. Monitorowanie środowiska wykonawczego Pedra, warstwa egzekwowania Luisa, wyłączniki i migawki Jacka. Różne mechanizmy, jedna zasada.
Jack przedstawił użyteczną perspektywę rozwoju branży. Pamięta pierwszego maila ze spamem, jaki kiedykolwiek otrzymał, z informacją o odziedziczeniu kopalni złota w Nigerii. To problem dojrzałości, a dojrzałość pojawia się po popełnieniu błędów, a nie przed nimi.
Co robić przed piątkiem
Wybierz jednego agenta. Zapisz dwie listy: co mu wolno robić i o co został faktycznie poproszony w tym tygodniu.
Różnica między tymi listami to Twój promień rażenia i jest to najskuteczniejszy miernik ryzyka związanego z SI, jaki Twój zespół może wygenerować w jedno popołudnie. Zajmuje to jedno popołudnie, nie wymaga budżetu i rozstrzyga powyższy argument dla Twojej organizacji, ponieważ te trzy pozycje to w rzeczywistości trzy różne odpowiedzi na pytanie, jak duża powinna być ta różnica.
Większość zespołów nigdy tego nie zapisała.
pełna godzina można obejrzeć ponownie, łącznie z uwagą Jacka na temat tego, dlaczego wymagania dotyczące udziału człowieka w procesie decyzyjnym w Europie sprawiają, że niektóre środki obronne sztucznej inteligencji są w praktyce niewykonalne.
A jeśli ćwiczenieciszwraca odpowiedź, która Ci się nie podoba, Xygeni odkryj każdy zasób AI w swoich repozytoriach, w tym agentów, umiejętności i serwery MCP, których nikt nie zadeklarował, i zmapuj, do czego każdy z nich może dotrzeć. Kontakt or zacznij za darmo, i uruchomimy go na Twoim komputerze.
FAQ
Jaki jest promień rażenia agenta AI?
Wszystko, do czego agent mógłby dotrzeć w razie błędu, niezależnie od tego, o co został poproszony. Jest to definiowane przez uprawnienia, poświadczenia i narzędzia dostępne w czasie wykonywania, a nie przez zadanie. Różnica między tymi dwoma elementami jest warta zmierzenia, a większość zespołów nigdy jej nie zapisała.
Czy przekroczenie przez agenta swoich obowiązków stanowi incydent bezpieczeństwa, jeśli nigdy nie przekroczył on swoich uprawnień?
To był główny punkt sporny. Odpowiedź Pedra brzmi w zasadzie „tak”, ponieważ atakujący jest definiowany przez rozbieżność celów, a nie złośliwość, a agent, który nie jest w stanie się z nimi porozumieć, zboczył z kursu. Odpowiedź Jacka jest bliższa odpowiedzi „nie”: to błąd operacyjny, jak błąd nowo zatrudnionego, a właściwą reakcją jest śledzenie i odzyskiwanie danych, a nie bardziej rygorystyczne ograniczenia. Luis unika odpowiedzi, zakładając od początku najgorszy scenariusz i pytając, która warstwa nadal obowiązuje, gdy to się stanie.
Czy agenci kodujący powinni być umieszczani w piaskownicy?
W przypadku agentów o wąskim, specyficznym przeznaczeniu, wszyscy trzej bez wahania odpowiedzieli „tak”: tylko do odczytu, gdzie to możliwe, bez bash, bez sieci, chyba że jest to wymagane. W przypadku agentów do ogólnego kodowania, panel podzielił się na trzy sposoby: Pedro miał je rozłożyć, Jack miał agresywnie zachowywać uprawnienia i migawki, a Luis miał dodać warstwę egzekwowania pod sprzęcie, niezależnie od tego, co agent ma prawo robić.
Czy mój EDR obejmuje ryzyko związane ze sztuczną inteligencją agentów?
Prawdopodobnie nie najlepiej. Obecne narzędzia dla punktów końcowych są zbudowane w oparciu o tradycyjne wzorce złośliwego oprogramowania i nie modelują zachowań agentów, przez co często pomijają istotne kwestie i sygnalizują to, co nie jest istotne. Rozwiązaniem Luisa była zewnętrzna warstwa egzekwowania przepisów przeznaczona dla środowisk programistycznych, a nie uniwersalny system EDR.
Co należy zrobić w pierwszej kolejności?
Zbuduj inwentarz. Każdy model, agent, umiejętność i serwer MCP w Twoich repozytoriach, a także to, do czego każdy z nich może dotrzeć. To ten jeden krok, który wymienili wszyscy trzej paneliści i jedyny, od którego zależą wszystkie pozostałe elementy sterujące.
