Dlaczego to powinno interesować ludzi od bezpieczeństwa, nie tylko od produktywności? Bo te same agenci, którzy nie potrafią spójnie utrzymać logiki biznesowej w jednym issue, już dziś mają dostęp do CI/CD, secretów, zależności zewnętrznych i produkcyjnych danych. Jak ktoś wpuści takiego „pomocnika” w SDLC bez sensownych guardrailów, to nie kupił sobie boostera efektywności – kupił sobie automatyczny generator podatności i compliance nightmare.
Dlaczego ci agenci oblewają „proste” zadania
Nowe prace o agentach do rozwiązywania realnych GitHub Issues są brutalne: agenci niby ogarniają narzędzia, czytają kod, uruchamiają testy, iterują – a i tak często kończą z patchem, który konceptualnie nie rozwiązuje problemu albo psuje coś obok. Diagnoza badaczy jest dość prosta: modele są całkiem niezłe w generowaniu pojedynczych zmian, ale bardzo słabe w długotrwałym, sekwencyjnym rozumowaniu w kontekście dużego repo i brudnego, żywego kodu.
W jednym z nowszych eksperymentów z agentami na prawdziwych zadaniach z GitHuba wszystkie próby agentów zawierały co najmniej trzy klasy problemów: błędy funkcjonalne, brakujące lub kiepskie testy, problemy z dokumentacją, a często także naruszenia linterów i słabą utrzymywalność. Brzmi znajomo dla każdego, kto widział juniora wrzuconego na monolita bez onboardingu – z tą różnicą, że tutaj „junior” może działać w trybie 24/7 i nikt nie ma instynktu, żeby mu zrobić code review tak dokładne, jak człowiekowi.
„Przeszedł testy” nie znaczy „jest bezpieczny”
Świetny przykład: analiza agentów, które rozwiązywały realne zadania na bazie istniejących testów – kiedy agent przechodził wszystkie testy, nadal trzeba było średnio dodatkowych 20–30 minut pracy seniora, żeby doprowadzić kod do stanu nadającego się do merge’a. To oznacza, że testy – w tym security testy – nie obejmują ani logiki biznesowej, ani edge case’ów, ani jakościowego długu technicznego generowanego przez agenta.
Badania nad AI-asystentami do kodu pokazują, że 62% rozwiązań wygenerowanych przez modele zawiera znane podatności albo błędy projektowe, nawet gdy używane są „topowe” modele. Dla CISO to brutalny przekaz: check „all tests green” w CI/CD w erze AI nie ma już żadnej wartości jako sygnał bezpieczeństwa – jest tylko sanity-checkiem syntaktyki i minimum funkcjonalności.
Gdzie to się wywala technicznie (MITRE-style)
Jeśli popatrzeć na tę sytuację oczami red teamu i MITRE ATT&CK, AI coding agent to świetny wektor do:
TA0005 Defense Evasion / TA0003 Persistence / TA0008 Lateral Movement – agent ma uprawnienia do repo, CI/CD, czasem do runtime’ów i zewnętrznych API, więc jego błędy (lub przejęcie) mogą być użyte do wstrzyknięcia backdoorów, eskalacji uprawnień i pivotu po infrastrukturze.
T1190 Exploit Public-Facing Application / T1552 Unsecured Credentials – jeżeli agent ściąga biblioteki, przykłady z sieci, „naprawia” autoryzację czy szyfrowanie na podstawie halucynacji, to może spokojnie wprowadzić twardo zakodowane sekrety, słabe algorytmy crypto albo otwarte endpointy.
Raporty branżowe ostrzegają wprost: agenci potrafią zaciągać przestarzałe lub podatne zależności, proponować nieaktualne mechanizmy kryptograficzne czy brak podstawowych kontroli (rate limiting, expiracja sesji, CSRF). Z perspektywy ofensywnej to wypisz–wymaluj gotowy przepis na supply chain attack z pomocą „autonomicznego pomocnika”, który nikt nie audytuje jak prawdziwego developera.
Gdzie badania zgniatają marketing
Gdy słucha się vendorów, AI agenci są „samodzielnymi programistami”, którzy „rozumieją kod bazowy” i „zamykają taski end-to-end”. Rzeczywistość jest dużo brzydsza: badania na prawdziwych repo pokazują, że agenci radzą sobie głównie z prostymi, dobrze odizolowanymi zadaniami, a im bardziej rośnie złożoność kodu i zależności, tym bardziej wszystko się sypie.
OpenAI i inni gracze przyznają, że narzędzia AI dla developerów w obecnym kształcie generują falę błędów, podatności i dodatkowej ręcznej roboty, która ląduje na barkach ludzkich inżynierów. Do tego dochodzi efekt uboczny: spadek realnych umiejętności programistycznych wśród młodszych devów, którzy uczą się głównie od agenta, a nie z własnego zrozumienia kodu – co prosto przekłada się na słaby kod, słabe code review i słabą czujność na wzorce ataku.
Co to robi z Twoim SDLC i ryzykiem
Z punktu widzenia bezpieczeństwa aplikacyjnego sytuacja robi się ciekawa – i kosztowna – dokładnie tam, gdzie biznes wyciera sobie usta „produktywnością”:
Koszty ukryte: każda „prawie dobra” łatka od agenta to nie tylko czas seniora na poprawki, ale też dodatkowe rundy testów, rewizje architektury i incydenty, które wyjdą dopiero na produkcji.
Ryzyko regulacyjne i prawne: kod z podatnościami i nieudokumentowanymi zmianami w obszarach typu dane osobowe, systemy finansowe, medyczne – to grube kary od regulatorów, spory z klientami i klasyczne „gdzie był CISO / CTO, kiedy to było wdrażane?”.
Cloud Security Alliance mówi wprost: AI-generated code i agenci wprowadzają systemowe ryzyko, bo nie rozumieją Twojego modelu zagrożeń, standardów wewnętrznych, ani kontekstu biznesowego – co prowadzi do logicznych błędów, brakujących kontroli i totalnej niespójności bezpieczeństwa w obrębie jednej aplikacji. Jak security kupuje narrację o „magicznych agentach”, to samo podstawia głowę pod nóż.
Agenci jako nowa powierzchnia ataku
Kolejny problem: sam agent jest teraz dodatkowym elementem łańcucha dostaw oprogramowania. Badania nad LLM agentami pokazują, że ich „autonomiczne” zachowanie – uruchamianie poleceń, pobieranie bibliotek, modyfikacja własnego kodu – dramatycznie zwiększa ryzyko nadużyć. Do tego dochodzi dobrze już opisana klasa ataków typu indirect prompt injection: w jednym z realnych eksperymentów Auto-GPT zostało sprowadzone do wykonywania złośliwych komend tylko przez odwiedzenie spreparowanej strony w trakcie „podsumowywania treści”.
Z punktu widzenia ATT&CK mamy tu elegancki wektor na initial access oraz execution bez dotykania bezpośrednio deva: atakujemy agenta, który ma narzędzia do wywoływania API, wykonywania kodu i zapisu w repo, a potem patrzymy, jak „asystent” firmowo podpisuje się pod zmianami, które wprowadzają backdoory lub exfiltrację. W logach to będzie wyglądało jak kolejny, niewinny run pipeline’u wywołany przez bota.
Jak powinien na to patrzeć CISO
CISO, który dziś kupuje AI coding agenta jako „boost produktywności”, a nie jako nowy, uprzywilejowany podmiot w łańcuchu dostaw, prosi się o kłopoty. Realne dane pokazują: znaczna część AI-generowanego kodu ma podatności, agenci oblewają złożone zadania i wymagają ciężkiego nadzoru, a przy tym działają z uprawnieniami, jakich nie dałbyś żadnemu juniorowi bez nadzoru.
Jeśli do piątku nie podniesiecie w politykach SDLC, że „AI agent == deweloper wysokiego ryzyka” – z obowiązkowym code review, ograniczonymi uprawnieniami, rejestrowaniem wszystkich działań i dedykowanymi kontrolami – to ktoś w końcu zrobi post-mortem po incydencie i będzie bardzo szczegółowo pytał, dlaczego dopuściliście nienadzorowanego bota do produkcji.
Źródła
“Unveiling Pitfalls: Understanding Why AI-driven Code Agents Fail at GitHub Issue Resolution” (arXiv, 2025)
“Evaluating Software Development Agents: Patch Patterns, Code Quality, and Issue Complexity in Real-World GitHub Scenarios” (arXiv, 2024)
“Frontier models are still unable to solve the majority of tasks” – analiza narzędzi AI do kodu vs. ludzie
Cloud Security Alliance – „Understanding Security Risks in AI-Generated Code”
Legit Security – „The Risks of AI-Generated Software Development”
Artykuły o bezpieczeństwie AI agentów i ich zachowaniach autonomicznych
