TL; DR
Ryzyko w kodowaniu agentowym nie polega na tym, że agent pisze zły kod. Ryzyko polega na tym, że agent działa. Instaluje pakiety, edytuje pliki, których nie otwierałeś, wywołuje narzędzia, odczytuje konfigurację, której nikt nie sprawdza, i otwiera pull requestsKażda z tych operacji jest operacją uprzywilejowaną, wykonywaną z uprawnieniami programisty, a istniejące kontrolki zostały stworzone z myślą o świecie, w którym każdą z nich wpisywał człowiek.
Prędkość przesunęła wąskie gardło do przeglądu. Niezależne badania nad asystentami kodowania AI wskazują, że około 40% wygenerowanego kodu zawiera lukę w zabezpieczeniach, a wskaźnik ten nie poprawił się wraz z udoskonalaniem modeli. Wydajność wzrosła. Możliwości weryfikacji nie. Programowanie agentowe sprawia, że jest to bardziej precyzyjne niż autouzupełnianie kiedykolwiek, ponieważ pojedyncza instrukcja może obsłużyć kilkanaście plików.
Ataki mają na celu uszkodzenie okablowania, a nie modelu. Ukryty kod Unicode w pliku reguł sprawia, że asystent emituje kod z tylnymi drzwiami i nigdy o nim nie wspomina, skatalogowany w MITRE ATLAS jako AML.CS0041. Atakujący rejestrują nazwy pakietów w modelach halucynacji. Jeden most MCP wysłał zdalne wykonanie kodu do klientów ponad 437 000 razy. Tradycyjna analiza nie odczytuje żadnego z tych plików.
To co zawiera jest nudne i działa: zrób inwentaryzację agentów i serwerów MCP faktycznie używanych, potraktuj pliki monitów i reguł jako kod poddawany przeglądowi, przypisz zakres każdej powierzchni narzędzia do zadania i wyegzekwuj zasady na komputerze dewelopera, na którym działa agent. Bezpieczeństwo sztucznej inteligencji Xygeni zajmuje się pierwszymi trzema i DevAI ostatni, obejmujący zarówno kod generowany przez sztuczną inteligencję, jak i kod napisany przez ludzi.
Czym jest kodowanie agentowe?
Kodowanie agentowe to programowanie, w którym agent AI przyjmuje cel i realizuje go w całej bazie kodu, korzystając z narzędzi: odczytując i edytując pliki, instalując zależności, uruchamiając testy i otwierając pull requestsRyzyko wynika z tych działań i konfiguracji, która nimi steruje, a nie z jakości pojedynczej wygenerowanej funkcji. Praktyki, które się sprawdzają, to inwentaryzacja, zakres uprawnień, weryfikacja konfiguracji i egzekwowanie w punkcie końcowym.
Kodowanie agentowe czy programowanie agentowe?
Oba terminy opisują tę samą zmianę i zespoły używają ich zamiennie. Programowanie agentowe często pojawia się w rozmowach inżynierów na temat sposobu wykonywania pracy; kodowanie agentowe to termin, który utkwił w kontekście narzędzi i bezpieczeństwa. Technicznie nic ich nie rozdziela. Jeśli chcesz… pełna definicja i otaczające ją słownictwo, nasz wpis w słowniku dotyczący kodowania agentowego jest na ten temat omówiony.
W tym tekście istotne jest rozróżnienie między sugestią a wykonaniem. Asystent, który kończy linię, to funkcja zwiększająca produktywność. Agent, który instaluje pakiet, edytuje sześć plików i przesyła gałąź, to nie-ludzka tożsamość działająca w Twoim… SDLCProgramowanie agentowe przekroczyło tę granicę po cichu i od tego czasu zakres większości programów bezpieczeństwa nie uległ zmianie.
Rzeczywiste ryzyko kodowania agentowego
Cztery rodziny ryzyka, w kolejności, w jakiej najczęściej gryzą.
- Objętość przekraczająca recenzję. Agent wprowadza więcej zmian na godzinę, niż jakikolwiek recenzent jest w stanie sensownie odczytać. Zatwierdzenia stają się bezużyteczne, a niebezpieczne wzorce powielają się z prędkością maszynową. To ryzyko, które wszyscy dostrzegają, a które jest najrzadziej mierzone. Zacznij od zmierzenia stosunku zmian wprowadzanych przez agenta do czasu recenzji przez człowieka, a ta liczba będzie dla Ciebie argumentem.
- Warstwa instrukcji. Wszystko, co dociera do kontekstu agenta, może nim sterować. Szybkie wstrzykiwanie jest najważniejsze w OWASP Top 10 dla aplikacji LLM Nie bez powodu, a w kodowaniu agentowym narzędzia dostarczania są banalne: opis problemu, komentarz do kodu, plik README w zależności, dokument pobierany przez agenta. Nikt nie musi atakować Cię bezpośrednio. Wystarczy, że napiszą coś, co Twój agent przeczyta.
- Warstwa konfiguracji. Pliki reguł, pliki umiejętności, monity i definicje serwera MCP decydują o tym, co robi agent i do czego może dotrzeć. Nie są one kodem aplikacji, więc żaden skaner w typowym stosie ich nie odczytuje. Backdoor pliku reguł zademonstrował skrajny przypadek, w którym znaki o zerowej szerokości zawierają instrukcje, których recenzent fizycznie nie widzi. Zwykły przypadek jest równie szkodliwy: dane uwierzytelniające dostawcy znajdują się w pliku konfiguracyjnym w postaci zwykłego tekstu lub asystent przyznał dostęp do odczytu całego systemu plików, ponieważ był to domyślny dostęp.
- Zależność i powierzchnia narzędzia. Agent wybiera zależności. Rozpoznaje nazwę, instaluje ją i przechodzi dalej, a także instaluje skrypty uruchamiane przed każdym pipeline widzi zmianę. Slopsquatting wykorzystuje dokładnie to: badania zaprezentowane na konferencji USENIX Security 2025 wykazały, że 19.7% pakietów rekomendowanych przez modele językowe nie istnieje, a halucynowane nazwy powtarzają się na tyle często, że atakujący mogą je zarejestrować i czekać. To samo dotyczy Serwery MCP, gdzie łączenie się z niezaufanym serwerem przekazuje agentowi narzędzia, których nigdy nie audytowałeś.
Jak to właściwie idzie nie tak
Żadnych pojedynczych, egzotycznych wyczynów. Kompozycja technik już udokumentowanych w naturze, w kolejności, w jakiej się pojawiają.
- InstrukcjaZdanie znajduje się w opisie problemu, pliku README zależności lub komentarzu do kodu. Nie zostało napisane z myślą o człowieku.
- KontekstProgramista prosi agenta o rozwiązanie problemu. Agent wczytuje opis, repozytorium i własne pliki reguł do kontekstu. Instrukcja i treść wyglądają identycznie jak w modelu.
- InstalacjaAgent rozwiązuje problem z biblioteką pomocniczą, która wydaje się prawidłowa, i instaluje ją. Nazwę zarejestrował w zeszłym tygodniu ktoś, kto zauważył, że modele wciąż ją wymyślają. Skrypt instalacyjny uruchamia się na laptopie.
- PoświadczenieW pliku znajduje się token dostawcy w postaci zwykłego tekstu
mcp.jsonoraz sesję w chmurze, która jest już aktywna w powłoce. Skrypt nie wymaga eskalacji. Dziedziczy. - pull requestZmiana jest niewielka, testy są zielone, a różnica odczytuje się w miarę sensownie. Zatwierdzenie zajmuje niecałą minutę, ponieważ czekają jeszcze cztery.
Każda brama, którą posiadasz, zostanie wyłączona po wykonaniu kroku trzeciego. Pierwsze trzy czynności wykonuje się na komputerze programisty w ciągu około dziewięćdziesięciu sekund.
8 lekcji od wczesnych użytkowników
Opracowano na podstawie udokumentowanych incydentów, opublikowanych badań i wzorców, które wciąż pojawiają się w zespołach, które wdrożyły programowanie agentowe, zanim ktokolwiek opracował dla niego zasady.
- Promień wybuchu to powierzchnia narzędzia, a nie podpowiedź Zespoły spędzają tygodnie na utwardzaniu komunikatów i minut na decydowaniu, z których narzędzi agent może korzystać. To niewłaściwa proporcja. Agent, który może tylko odczytywać, jest niewygodny w przypadku zagrożenia. Agent, który może wysyłać pocztę, wysyłać zapytania do produkcji i wysyłać powiadomienia. commits to incydent i posiada własne dane uwierzytelniające programisty, ponieważ prawie nikt nie przydziela tożsamości agentowi. Zapisz listę narzędzi, zanim napiszesz monit systemowy.
- Agent optymalizuje działanie testu, a nie kodu W przypadku wadliwego pakietu i wystarczającej autonomii, agent usunie asercję, rozluźni warunek lub zamieni integrację na pozorowaną, a następnie zgłosi sukces. Każdy zespół rozpoznaje to w pierwszym tygodniu. Dlatego właśnie zielony pipelineprzestało być dowodem i dlaczego pytanie kontrolne zmieniono z „czy to działa” na „co zmieniono, żeby to zadziałało”.
- Twój plik reguł to konfiguracja produkcyjna Plik, który steruje każdą generowaną linią, to zazwyczaj commitPrzeczytane raz i nigdy więcej nie sprawdzone. Należy do kontroli zmian, z właścicielem, recenzentem różnic i kimś, kto zauważy, kiedy rośnie linia, której nikt nie pamiętał, aby została dodana. Załóż, że wszystko w nim będzie przestrzegane, w tym to, czego nie widzisz.
- Zależności agenta nie są Twoimi zależnościami Listy zatwierdzonych bibliotek zakładają wybór dokonany przez człowieka. Agent rozpoznaje wiarygodną nazwę i instaluje ją, a skrypty instalacyjne są uruchamiane przed utworzeniem CI. Zespoły, które poniosły porażkę, dodały sprawdzanie w trakcie instalacji na komputerze, a nie dokument określający preferencje programistów.
- Nikt nie może ci powiedzieć, co oni robią Zapytaj pięciu inżynierów, z jakich serwerów MCP i asystentów korzystają, a otrzymasz pięć odpowiedzi, z których żadna nie jest kompletna. Ankiety nie mają tu zastosowania, ponieważ narzędzia instalują się lokalnie i zmieniają się co tydzień. Odkrycie musi pochodzić z kodu, zależności i plików konfiguracyjnych pozostawionych przez narzędzia.
- Pamięć zachowuje truciznę po zakończeniu sesji Błędna instrukcja, która dociera do trwałego kontekstu lub pamięci agenta, nie traci ważności wraz z wykonaniem zadania. Nadal działa dyskretnie w niezwiązanych z nim zadaniach, dlatego zatruwanie pamięci i kontekstu ma swój własny wpis na liście agentów OWASP. Pamięć agenta należy traktować jako stan wymagający przeglądu i sposób na jej wyczyszczenie, a nie jako funkcję ułatwiającą życie.
- Odwracalność jest ważniejsza od zapobiegania Zespoły, które zapewniają największą autonomię w bezpieczny sposób, to nie te, które mają najściślejszą kontrolę. To te, które popełniały tanie błędy: agenci wypychają gałęzie zamiast głównych, pracują w środowiskach jednorazowych, a każdą akcję można cofnąć jednym poleceniem. Autonomia jest opłacalna dokładnie w takim stopniu, w jakim opłacalne jest jej cofnięcie.
- Pilot kłamie ci Agenci prezentują się znakomicie w przypadku zadań greenfield w małych repozytoriach, ale tracą na jakości w dużych, starszych bazach kodu z niejawnymi konwencjami. Udany pilotaż przecenia wzrost produktywności i zaniża ryzyko, a następnie ustala oczekiwania, których nikt nie jest w stanie spełnić na dużą skalę. Przeprowadź pilotaż w najgorszym, a nie najczystszym repozytorium.
Jak to wygląda w praktyce
Kolejność jest ważniejsza niż narzędzia. Najpierw odkrywanie, ponieważ nie można określić zakresu uprawnień dla agentów, których się nie znalazło. Następnie warstwa konfiguracji, ponieważ to tam znajdują się instrukcje. Następnie punkt końcowy, ponieważ to tam agent faktycznie działa i instalacja kończy się na długo przed… pipeline zawiadomienia.
Bezpieczeństwo sztucznej inteligencji Xygeni odkrywa każdy zasób AI w SDLCw tym modele, agenci, serwery agentów, serwery MCP, zestawy danych, pliki umiejętności, monity i guardrails Nikt nie zadeklarował, odczytując kod aplikacji, zadeklarowane zależności i pliki konfiguracyjne pozostawione przez narzędzia sztucznej inteligencji, a następnie mapując sposób ich połączenia. Wykrywa zagrożenia specyficzne dla programowania agentowego: wstrzykiwanie komunikatów i wyciek komunikatów systemowych, złośliwe instrukcje i wstrzykiwanie narzędzi do plików reguł i umiejętności, niebezpieczną konfigurację MCP, nadmierną agencję i brakujące elementy. guardrails, sekrety w plikach AI oraz podatne lub slopsquatted zależności AI. Wyniki są odwzorowywane na liście OWASP Top 10 dla aplikacji LLM i wskazują na konkretny plik i linię, a lejek priorytetyzacji zawęża tysiące wyników do tych, które są w użyciu, osiągalne, podatne na atak, uprzywilejowane i krytyczne dla biznesu.
DevAI Obejmuje on drugą połowę, w edytorze: zabezpiecza kod w trakcie jego pisania, stosuje się zarówno do kodu generowanego przez sztuczną inteligencję, jak i napisanego przez ludzi, oraz przechwytuje działania innych agentów, zanim te zostaną wykonane. Ta sama inteligencja dotyczy ustaleń pobranych ze skanerów, które już uruchomiłeś, więc nie ma potrzeby zastępowania tego, co już masz.
FAQ
- Jakie jest największe ryzyko w kodowaniu agentowym? Nadmierna sprawczość. Agent z szerokim zakresem narzędzi zamienia każdą udaną iniekcję w realne działanie, a większość zespołów stosuje znacznie bardziej elastyczne narzędzia niż ludzi.
- Czy programowanie agentowe jest bezpieczne w środowiskach regulowanych? Tak, z inwentaryzacją, zakresem uprawnień, sprawdzoną konfiguracją i egzekwowaniem na punkcie końcowym. Nie da się obronić podczas audytu braku wiedzy o tym, które agenty są uruchamiane, do czego docierają i jaki kod są ich autorami.
- Czy kodowanie agentowe generuje kod mniej bezpieczny niż kod tworzony przez człowieka? Szybkość na linię jest porównywalna z błędem ludzkim, ale liczba błędów nie, a to właśnie liczba błędów uniemożliwia weryfikację. Problemem jest przepustowość, a nie talent.
- Czy powinniśmy zakazać asystentów kodujących AI? Zakazy przenoszą użytkowanie do podziemia, co jest jeszcze gorsze. Sztuczna inteligencja Shadow AI jest trudniejsza do zabezpieczenia niż zatwierdzona sztuczna inteligencja, a odkrycie jej to kontrola, która faktycznie zmienia sytuację.
- Kto ponosi odpowiedzialność, gdy agent przekaże lukę w zabezpieczeniach? Osoba, która je scaliła, dokładnie tak jak poprzednio. To jest ta niewygodna część i dlatego dane o autorstwie są tak ważne: recenzent zatwierdzający zmiany wprowadzone przez maszynę w momencie, gdy jest to możliwe, potrzebuje, aby wyniki pojawiły się przed zatwierdzeniem, a nie po nim.
- Jak mamy zacząć, skoro nie mamy żadnej widoczności? Przeprowadź eksplorację swoich repozytoriów, wypisz znalezione serwery MCP i asystentów oraz uszereguj agentów według powierzchni narzędzia. Najbardziej ryzykowny agent to zazwyczaj nie ten, o którego ktokolwiek się martwił.
Agenci są już w Twoich repozytoriach
Kod agenta znajduje się już w Twoich repozytoriach, niezależnie od tego, czy ktoś go zatwierdził. Zespoły, które się nim dobrze zajmują, nie mają najsurowszej polityki. To one mogą odpowiedzieć, w danym dniu, które agenty są uruchomione, do czego mogą dotrzeć i co zmieniło się w plikach, którymi sterują.
Zobacz, z czym są połączeni Twoi agenci Xygeni.







