Bezpieczeństwo agentów AI do programowania

Co agent kodujący może zrobić w twoich systemach

Rozmowy o bezpieczeństwie AI w programowaniu często zaczynają się od modelu. Bardziej użyteczne jest pytanie, co agent może zrobić w twoich systemach. Na komputerze programisty agent CLI zwykle działa na koncie użytkownika tego inżyniera, z dostępem do wszystkiego, co to konto może czytać, oraz do danych uwierzytelniających w zmiennych środowiskowych, plikach konfiguracyjnych i w git credential helperze. W zależności od konfiguracji może:

• Czytać kod źródłowy, konfigurację i pliki lokalne, takie jak .env czy poświadczenia do chmury
• Uruchamiać buildy, testy, instalację pakietów i dowolne inne polecenia powłoki
• Pobierać strony internetowe i wywoływać API, w tym rejestry pakietów
• Korzystać z serwerów MCP, które mają własne dane uwierzytelniające do trackerów, baz danych czy kont w chmurze
• Commitować, pushować branche i otwierać pull requesty, a w CI działać z tokenem pipeline'u

To sprawia, że agent jest nowym rodzajem tożsamości w twoich systemach. Działa na pożyczonych uprawnieniach i często nie zostawia własnego śladu. Do tego przyjmuje instrukcje z każdego tekstu, który czyta, także z plików, zgłoszeń, stron internetowych i wyników narzędzi napisanych przez kogoś innego. Traktujemy go jak nowe konto serwisowe z nietypowym kanałem wejścia: własne dane uwierzytelniające o wąskim zakresie, log jego działań i wskazany właściciel jego konfiguracji.

Prompt injection w repozytorium, zgłoszeniach i narzędziach

OWASP umieszcza prompt injection na pierwszym miejscu listy Top 10 for LLM Applications 2025. Rozróżnia odmianę bezpośrednią, w której prompt samego użytkownika zmienia zachowanie modelu, i pośrednią, w której model przyjmuje treści z zewnętrznych źródeł, takich jak strony internetowe czy pliki. Przyjmowanie treści z zewnątrz to większość pracy agenta kodującego.

Do niezaufanych danych wejściowych należą pliki w repozytorium napisane przez kontrybutorów, kod źródłowy zależności, zgłoszenia i komentarze w pull requestach, dokumentacja i strony czytane podczas researchu oraz wyniki narzędzi i serwerów MCP. Każde z tych źródeł może zawierać tekst, który dla agenta brzmi jak polecenie, a osoba robiąca review wcale nie musi go widzieć.

Typowym przykładem jest komentarz w Markdownie, którego wyrenderowana strona nie pokazuje. Mówi agentom AI, że testy potrzebują danych dostępowych do wdrożenia, i każe im skopiować plik środowiskowy do opisu pull requesta. Osoba czytająca wyrenderowany README nie widzi nic niezwykłego.

OWASP stwierdza, że nie wiadomo, czy istnieją niezawodne metody zapobiegania prompt injection, i z takiego założenia wychodzimy. Filtry, prompty systemowe i lepsze modele sprawiają, że ataki udają się rzadziej, więc pytanie projektowe brzmi: do czego dotrze udany atak. Agent, który czyta niezaufane treści, ma dostęp do sekretów i może wysłać dane na zewnątrz (wywołaniem sieciowym, commitem albo opisem pull requesta), daje atakującemu wszystko, czego ten potrzebuje. Usuń jeden z tych warunków, a udany atak będzie miał znacznie mniejsze pole działania.

Sekrety, destrukcyjne polecenia i zależności

Trzy kolejne ryzyka dotyczą każdego narzędzia. Żadne nie wymaga atakującego, choć atakujący mogą wykorzystać każde z nich.

Sekrety w kontekście

Sekrety trafiają do kontekstu agenta w zwyczajny sposób: agent otwiera plik .env, żeby zrozumieć konfigurację, wypisuje zmienne środowiskowe podczas debugowania albo czyta log, w którym jest token. Sekret trafia potem z kolejnym zapytaniem do dostawcy modelu i może skończyć w commicie, w opisie pull requesta, w zapisie sesji albo w zapytaniu do zewnętrznego hosta. Reguły deny dla plików z sekretami pomagają. Bardziej pomaga trzymanie produkcyjnych sekretów poza środowiskiem agenta.

Destrukcyjne polecenia

Agent, który może uruchamiać polecenia powłoki, może też uruchomić niewłaściwe: usunąć pliki spoza zadania, nadpisać force pushem wspólny branch, puścić migrację na niewłaściwej bazie albo wywołać CLI chmury zalogowane z uprawnieniami administratora. Zwykle to pomyłki, których nic w środowisku nie zatrzymało. Część z nich wyłapią prośby o akceptację. Reszta wymaga środowiska bez produkcyjnych danych dostępowych, z chronionymi branchami i z kopiami zapasowymi, których odtworzenie ktoś naprawdę sprawdził.

Zależności i wymyślone nazwy pakietów

Agenci dodają zależności, gdy zadanie wydaje się tego wymagać, a modele czasem podsuwają pakiety, które nie istnieją. Badanie zaprezentowane na USENIX Security 2025 wykazało, że takie halucynacje pakietów są trwałe i systemowe w badanych modelach, zarówno komercyjnych, jak i open source. Kto zarejestruje wymyśloną nazwę, ten dostanie swój kod zainstalowany u każdego, kto pójdzie za podpowiedzią, a skrypty instalacyjne działają z uprawnieniami tego użytkownika lub pipeline'u. Nowa zależność zasługuje na takie samo review jak nowy kod, a proxy rejestru z allowlistą zamienia to review w regułę.

Serwery MCP, pluginy i to, dokąd trafiają twoje dane

Serwery MCP poszerzają zasięg agenta. Serwer do twojego trackera zgłoszeń, bazy danych czy konta w chmurze zwykle ma własne dane uwierzytelniające, a agent może zrobić wszystko, na co one pozwalają. Specyfikacja MCP wymaga, by klienci traktowali adnotacje narzędzi jako niezaufane, chyba że pochodzą od zaufanych serwerów, i zaleca, by w pętli zawsze był człowiek, który może odrzucić wywołanie narzędzia. Wyniki narzędzi to również tekst w kontekście modelu, więc serwer zwracający zgłoszenia czy strony internetowe jest także kanałem prompt injection. Zanim serwer trafi na twoją allowlistę, ktoś powinien wiedzieć:

• Kto go utrzymuje i którą wersję przypinasz
• Jakie dane uwierzytelniające przechowuje i na co one pozwalają
• Czy zwraca do modelu treści osób trzecich
• Kto za niego odpowiada i przegląda jego aktualizacje

Pliki instrukcji, skille i pluginy od osób trzecich wymagają tej samej uwagi. To tekst, którym agent kieruje się z twoimi uprawnieniami, a niektóre zawierają też skrypty. Pluginy z workflowami, takie jak pstack, plugin do Cursora autorstwa Lauren Tan, łączą skille i playbooki do powtarzalnej pracy inżynierskiej, w tym nocne uruchomienia, które prowadzą pull requesty aż do merge'a. Playbooki instruują agenta i niczego nie wymuszają: o tym, czy merge może się wydarzyć, decydują uprawnienia i dane uwierzytelniające agenta, ochrona branchy, wymagane review i CI. Dokumentacja Claude Code mówi to samo o własnych plikach instrukcji: kształtują to, co agent próbuje zrobić, ale nie zmieniają tego, na co pozwala Claude Code.

Workflowy pstack w praktyceWdrożenie pstack w ramach konsultingu Cursor

Każdy agent z założenia wysyła też dane na zewnątrz: prompty, zawartość plików, wyniki poleceń i narzędzi trafiają do dostawcy modelu, czasem przez gateway, a niektóre narzędzia dodają telemetrię lub udostępnianie sesji. Retencja, wykorzystanie do trenowania i region przetwarzania zależą od dostawcy, planu i twojej umowy i mogą się różnić między CLI, rozszerzeniem IDE a agentem chmurowym tego samego narzędzia. Prywatność kodu zaczyna się od spisania tego przepływu dla każdego wariantu, a osoby odpowiedzialne u ciebie za dane i umowy powinny sprawdzić go względem waszych umów. Dokumentujemy go, ale nie możemy składać zobowiązań w imieniu dostawcy.

Kontrole bezpieczeństwa agentów AI

Żadna pojedyncza kontrola nie czyni agenta bezpiecznym i żadna z poniższych tego nie obiecuje. Działają jak warstwy, przez które pomyłka albo udany atak musi przejść, zanim wyrządzi szkodę.

• Uprawnienia agentów AI dla każdego repozytorium, w miarę możliwości narzucane centralnie, z dozwolonymi rutynowymi poleceniami, żeby pozostałe prośby o akceptację ktoś czytał
• Sandboxing albo osobny kontener lub VM dla uruchomień bez nadzoru, ze świeżym checkoutem i bez danych uwierzytelniających hosta
• Allowlista ruchu wychodzącego obejmująca hosta git, proxy rejestru pakietów i endpoint modelu
• Krótkotrwałe dane uwierzytelniające na zadanie, ograniczone do jednego repozytorium i działań, których zadanie wymaga
• Skanowanie sekretów w hookach pre-commit i w CI, do tego reguły deny dla plików z sekretami
• Polityka zależności: proxy rejestru, lockfile'y i review nowych pakietów przez człowieka
• Ochrona branchy, wymagane checki i review przez człowieka, których nie da się zmienić danymi uwierzytelniającymi agenta

Całość uzupełniają dwa rejestry. Pierwszy to log audytowy poleceń, wywołań narzędzi i pushy, który po incydencie da się faktycznie znaleźć, drugi to opisana wyżej allowlista MCP.

Review pull requestów pisanych przez agentów

Kontrole dostawców i ich granice

Główne narzędzia mają takie kontrole i otwarcie dokumentują ich ograniczenia. Claude Code ma tryby uprawnień oraz reguły allow, ask i deny, które administratorzy mogą narzucić przez managed settings. Według dokumentacji tryb pomijający prośby o zgodę nadaje się wyłącznie do izolowanych środowisk, takich jak kontenery czy maszyny wirtualne, a reguła deny dla polecenia powłoki nie jest granicą bezpieczeństwa wokół programu. OpenAI Codex łączy tryb sandboxa z polityką akceptacji, a w domyślnym trybie workspace-write dostęp do sieci jest wyłączony, dopóki go nie włączysz.

GitHub dokumentuje firewall, który domyślnie ogranicza dostęp do internetu dla agenta chmurowego GitHub Copilot. Obejmuje procesy uruchamiane przez agenta jego narzędziem Bash, ale nie serwery MCP ani skonfigurowane kroki setupu, a GitHub zaznacza, że wyrafinowane ataki mogą go obejść. Zanim oprzesz się na jakiejkolwiek granicy, przeczytaj sekcję o ograniczeniach w dokumentacji swojego narzędzia i sprawdź, które kontrole obejmuje twój plan.

Uruchomienia bez nadzoru w CI i w środowiskach chmurowych

Uruchomienia bez nadzoru zmieniają ryzyko. Nikt nie patrzy na polecenia, dane wejściowe często pochodzą ze zgłoszenia albo pull requesta, który mógł napisać ktokolwiek, a uruchomienie ma token pipeline'u. Dwa incydenty z 2025 roku pokazują, jak wiele zależy od danych uwierzytelniających wokół automatyzacji.

W lipcu 2025 roku AWS poinformował, że zbyt szeroko ustawiony token GitHub w konfiguracji buildu rozszerzenia Amazon Q Developer dla VS Code pozwolił atakującemu zacommitować złośliwy kod do repozytorium open source tego rozszerzenia. Kod trafił do wersji 1.84.0 i nie wykonał się z powodu błędu składni. W sierpniu 2025 roku atakujący przejęli token npm systemu budowania Nx przez workflow GitHub Actions, który przy pull requestach działał z uprawnieniami docelowego repozytorium i przekazywał tytuły pull requestów do powłoki bez sanityzacji. Według postmortemu zespołu Nx złośliwe wersje opublikowane 26 sierpnia próbowały użyć lokalnych narzędzi AI, takich jak Claude i Gemini, podczas przeszukiwania maszyn pod kątem wrażliwych danych.

Żaden z tych przypadków nie wymagał wyrafinowanego ataku na model. Oba sprowadzały się do danych uwierzytelniających o większym zasięgu, niż wymagało zadanie, a drugi pokazuje, że atakujący będą próbowali wykorzystać CLI agentów na komputerach programistów. Uruchomienia bez nadzoru projektujemy według tych zasad:

• Świeże, izolowane środowisko na każde uruchomienie, usuwane po zakończeniu
• Ruch wychodzący tylko przez allowlistę z endpointem modelu i proxy pakietów
• Dane uwierzytelniające na jedno uruchomienie, ograniczone do jednego repozytorium i wygasające razem z zadaniem
• Agent pushuje tylko na własne branche, a o otwarciu albo merge'u pull requesta decyduje kod pipeline'u
• Wymagane checki i review przez człowieka, których token agenta nie może zmienić ani obejść
• Żadnych uruchomień z sekretami przy zdarzeniach, które mogą wywołać zewnętrzni kontrybutorzy

Runmill, projekt open source naszego założyciela w wersji developer preview, działa według tego wzorca. Agent pracuje w izolowanej przestrzeni roboczej, dokładnie ten kandydujący commit musi przejść wymagane checki i review w świeżym kontekście, a o pushach, pull requestach i merge'ach decyduje deterministyczny kod, nigdy agent.

Autonomiczna fabryka oprogramowaniaHarness engineering dla delegowanych środowisk chmurowych

Governance, odpowiedzialność i reagowanie na incydenty

Bez właścicieli kontrole się rozjeżdżają. Konfiguracja agentów, od plików instrukcji i ustawień uprawnień po hooki, konfigurację MCP i wersje pluginów, powinna być w kontroli wersji, ze wskazanym właścicielem i procesem zmian. Zmiany w niej wymagają review tego właściciela, także te, które proponuje sam agent. Ktoś decyduje też, które narzędzia, serwery MCP i pluginy są zatwierdzone i kto może przyznawać wyjątki.

Gdy coś pójdzie nie tak

1. 1

   Zatrzymaj i odbierz dostęp

   Zatrzymaj trwające sesje i unieważnij dane uwierzytelniające agenta, w tym tokeny serwerów MCP i wszystkie tokeny CI w jego zasięgu.

2. 2

   Odtwórz przebieg zdarzeń

   Na podstawie logów audytowych, zapisów sesji i historii gita ustal, co agent przeczytał, uruchomił, wysłał i wypchnął.

3. 3

   Zrotuj i posprzątaj

   Zrotuj każdy sekret, który mógł trafić do kontekstu, i cofnij albo odizoluj dotknięte branche, pakiety i artefakty buildów.

4. 4

   Popraw kontrolę

   Zmień uprawnienie, zakres danych uwierzytelniających albo regułę review, która na to pozwoliła, i sprawdź poprawkę na tym, co faktycznie się wydarzyło.

Rada zakładowa w Niemczech i RODO

Ta część to praktyczne wskazówki, a nie porada prawna. Zgodnie z § 87 ust. 1 pkt 6 niemieckiej ustawy o ustroju zakładów pracy (BetrVG) rada zakładowa (Betriebsrat), o ile kwestii nie reguluje już ustawa lub układ zbiorowy, ma prawo współdecydowania przy wprowadzaniu i stosowaniu urządzeń technicznych przeznaczonych do monitorowania zachowania lub wydajności pracowników. Dashboardy użycia agentów, logi sesji i metryki dla poszczególnych osób mogą rodzić to pytanie, więc jeśli masz zespoły w Niemczech, zaangażuj radę zakładową przed wdrożeniem i uzgodnij, co jest logowane, kto to widzi i jak długo jest przechowywane. Wyniki pilotażu raportujemy według zespołu, zadania i modelu, nigdy według pojedynczego inżyniera.

Ochrona danych to równoległy wątek. Kod, historia commitów, zgłoszenia i logi często zawierają dane osobowe, od nazwisk autorów po dane klientów w fixture'ach testowych, a do wszystkiego, co z nich trafia do dostawcy modelu, stosuje się RODO. Twój inspektor ochrony danych będzie chciał zobaczyć spisany przepływ danych, warunki przetwarzania u dostawcy, retencję i region oraz decyzję, co może trafić do kontekstu agenta.

Agent surface:      <agent> CLI on developer laptops
Model endpoint:     <provider, account, region>
Gateway:            <none, or name and owner>
Sent:               prompts, file contents, command output, tool results
Kept out:           .env, secrets/, customer-data/
Retention:          <per contract, checked on YYYY-MM-DD>
Training use:       <per contract and plan settings>
Telemetry:          <setting and destination>
Credentials held:   <token, scope, lifetime, owner>
MCP servers:        <name, pinned version, owner, credential scope>
Config owner:       <team>
Next review:        <date>

Jak pomaga Cloudsail

Tę pracę wykonujemy razem z twoimi inżynierami i zespołem bezpieczeństwa, w twoich własnych repozytoriach: harness i uprawnienia dla każdego narzędzia, którego używasz, spisane przepływy danych oraz izolowane środowiska z danymi uwierzytelniającymi o wąskim zakresie dla uruchomień bez nadzoru. Każdą zmianę sprawdzamy na reprezentatywnych zadaniach, zanim trafi do innych zespołów.

Warsztaty prowadzimy zdalnie albo na miejscu w Polsce i w Niemczech, po polsku, angielsku lub niemiecku, jako sesje z jednym zespołem na jego własnych repozytoriach. Nie prowadzimy otwartych kursów i nie wydajemy certyfikatów. Twój zespół platformowy zostaje z konfiguracją, runbookami i uzasadnieniem każdego ustawienia.

Harness engineering dla agentów kodującychWdrożenie agentów kodującychClaude Code: uprawnienia i wdrożenie