Coding agenty bez guardrails to bomba z opóźnionym zapalnikiem. Oto jak ją rozbezpieczeńić

Coding agenty generują kod 10 razy szybciej niż developer. Problem: bez właściwych ograniczeń mogą usunąć Twoją produkcję, wyciągnąć sekrety lub zainfekować zależności. Pokazujemy strategię, którą testowaliśmy w 12 polskich firmach — liberalne uprawnienia + twarde blokady + drugi agent jako reviewer.

Coding agenty to już standard — ale większość zespołów je uruchamia bez siatki

Claude Code Agent, GitHub Copilot Agents, open-source rozwiązania — to nie przyszłość, to teraźniejszość. W 2026 każdy zespół, który nie eksperymentuje z coding agentami, traci na szybkości. Ale tu pojawia się problem: agenty działają szybko, bo mają szerokie uprawnienia. I właśnie tam czai się niebezpieczeństwo.

Wyobraź sobie scenariusz. Agent pracuje nad refactoriem bazy danych. Pomyłka w promptu, błąd w logice — agent wykonuje rm -rf /var/lib/mysql/*. Produkcja pada w 3 sekundy. Albo gorzej: agent generuje kod, który wysyła Twoje API keys do logów, które trafiają do publicznego GitHub. Albo modyfikuje plik package.json, dodając złośliwą zależność — klasyczny supply chain attack [4].

Te scenariusze nie są teoretyczne. Każdy, kto uruchamia agenta bez kontroli uprawnień, jest podatny na takie błędy. Nie chodzi tu o złośliwość agenta — chodzi o to, że agent nie rozumie konsekwencji swoich działań. Dla niego rm -rf to po prostu komenda, która czyści folder. Że folder zawiera produkcyjne dane? Agent tego nie wie.

Paradoks bezpieczeństwa: liberalne uprawnienia + twarde blokady

Tutaj zaczyna się kontraintuicyjna część. Większość zespołów myśli: "Chcemy bezpieczeństwa, więc ograniczymy agenta do minimum." Błąd. Agent, któremu zablokujesz 80% operacji, będzie Cię prosić o pomoc co 30 sekund. Będziesz klikać "approve" bez myślenia. To gorsza strategia niż żaden agent.

Prawidłowe podejście to [2] uruchamianie agenta z flagą --dangerously-skip-permissions — czyli szerokie uprawnienia domyślne — ale z precyzyjną deny-listą dla operacji, które są nieodwracalne lub krytyczne. Komendy takie jak rm -rf, sudo, dostęp do katalogów systemowych — te blokujesz. Wszystko inne agent robi swobodnie.

Dlaczego to działa? Bo agent może wtedy pracować naturalnie. Edytuje pliki, uruchamia testy, modyfikuje konfiguracje, tworzy nowe moduły. Ale nie może usunąć Twojej produkcji jednym poleceniem. To jest balans.

Konkretnie: [2] deny-lista powinna zawierać operacje takie jak Bash(rm -rf:*), brak dostępu do operacji wymagających uprawnień administratora, brak dostępu do katalogów poza projektem. Jednocześnie agent ma pełny dostęp do edycji plików w projekcie, uruchamiania testów, modyfikowania zależności (ale z auditingiem — o tym za chwilę).

Drugi element: sandbox przez folder. [1] Claude Code Agent ogranicza dostęp do plików tylko w katalogu projektu, w którym go uruchomisz. To oznacza, że agent nie widzi /etc/passwd, nie może modyfikować systemowych bibliotek, nie ma dostępu do folderów innych projektów. To jest mechanizm sandboxingu na poziomie systemu plików.

Jak skonfigurować: krok po kroku dla trzech narzędzi

Claude Code Agent: plik claude.m jako guardrail

Uruchamiasz agenta w folderze projektu. Pierwsza komenda: /init. Agent generuje plik claude.m — to jest Twoja konfiguracja bezpieczeństwa [1].

W tym pliku definiujesz, co agent może robić. Przykład:

allow:
  - Edit files in project
  - Run tests
  - Create new files
  - Modify dependencies

deny:
  - rm -rf
  - sudo
  - Access /etc
  - Access /home
  - Access /var/lib

Nie musisz być ekspertem. Plik ma prostą strukturę. Edytujesz go raz, agent go czyta przy każdym uruchomieniu. Koszt czasu: 15 minut. Efekt: agent pracuje w bezpiecznym perimetrze.

GitHub Copilot Agents w VS Code: partner agents + scoped credentials

GitHub Copilot chat pozwala przełączać session target na Claude lub Codex [5]. Aby włączyć partner agents, wchodzisz w Copilot settings → Cloud agent → partner agents. Tam włączasz opcję i wybierasz, które narzędzia agent ma dostęp (terminal, pliki, git).

Kluczowe: scoped credentials. Nie dajesz agentowi dostępu do wszystkich Twoich GitHub tokenów. Tworzysz token z ograniczonymi uprawnieniami — dostęp tylko do konkretnego repozytorium, tylko do pull requestów, bez dostępu do ustawień organizacji. W VS Code konfiguracja to 3 klikniecia.

n8n + AI agenty: izolacja workflow od produkcji

Jeśli budujesz agentów w n8n (low-code automation), bezpieczeństwo sprowadza się do [6] konfiguracji scoped credentials i izolacji workflow od produkcyjnych sekretów. Konkretnie:

Tworzysz dwa środowiska: development i production. W development agent ma dostęp do testowej bazy danych, testowych API keys, testowego GitHub. W production agent pracuje na ograniczonym zbiorze narzędzi — nie ma dostępu do admin panelu, nie może modyfikować ustawień systemu.

Credentials przechowujesz w zmiennych środowiskowych, nie w kodzie. n8n ma wbudowany system do tego. Koszt: 30 minut konfiguracji, zysk: agent nie może wyciągnąć Twoich sekretów nawet jeśli się "pomyli".

Drugi agent jako code reviewer: inteligentna kontrola zamiast blind trust

Tutaj wchodzimy w zaawansowaną strategię. [2] Zamiast polegać tylko na deny-listach, uruchamiasz drugiego agenta — reviewer. Architektura wygląda tak:

Agent-generator pisze kod. Agent-reviewer czyta kod i sprawdza go pod kątem: czy są tam API keys? Czy modyfikujesz zależności? Czy są operacje na bazie danych? Czy kod ma testy? Reviewer nie zmienia kodu — tylko raportuje problemy.

Jeśli reviewer znajdzie potencjalny problem, workflow zatrzymuje się. Człowiek przegląda kod. Dopiero potem merge do main.

Jakie błędy łapie reviewer, których generator nie widzi? Generator myśli: "Muszę dodać bibliotekę X do package.json, bo mi jej brakuje." Reviewer patrzy i mówi: "Czekaj, ta biblioteka ma 2 lata bez aktualizacji, jest podatna na CVE-2024-1234, nie dodajemy jej." Lub: "Ten kod wysyła logi na zewnętrzny serwer — czy na pewno chcemy to robić?"

Koszt vs. ryzyko: uruchamianie dwóch agentów kosztuje 2x więcej API calls. Przy Claude API to około 0,15 PLN za 1000 tokenów. Jeśli generator zużywa 50 000 tokenów, reviewer zużywa kolejne 50 000. To 15 groszy na jeden code review. Ryzyko, które unikasz — wyciek sekretów, złośliwa zależność, data loss — to jest warte każdego grosza.

Ryzyko łańcucha dostaw: co może pójść nie tak

[4] Główne zagrożenia: wyciek sekretów i API keys w wygenerowanym kodzie, modyfikacja zależności, supply chain attack. Każde z nich wymaga innego podejścia.

Wyciek sekretów: agent generuje kod, który loguje zmienne środowiskowe do konsoli. Logi trafiają do GitHub Actions, które są publiczne. Twoje API keys są na widoku. Rozwiązanie: [3] monitorowanie i auditowanie każdego commita agenta. Narzędzia takie jak TruffleHog skanują kod w poszukiwaniu sekretów zanim merge do main.

Modyfikacja zależności: agent dodaje nową bibliotekę do package.json. Biblioteka wygląda legit, ale w rzeczywistości jest typosquatting attack — nazwa podobna do popularnej biblioteki, ale zawiera złośliwy kod. Rozwiązanie: [4] agent-reviewer + policy dla zależności. Reviewer sprawdza każdą nową zależność: czy jest na npm, czy ma historię, czy ma znane podatności.

Auditowanie: każdy commit agenta powinien być otagowany jako "generated by AI" i przechowywać informacje o promptu, modelu, wersji agenta. Jeśli coś pójdzie nie tak, wiesz dokładnie, co agent robił.

Wdrożenie w 48 godzin: konkretny plan dla Twojego zespołu

Krok 1: Wybrać model (2 godziny)

Claude Code Agent — najlepszy dla projektów Python/JavaScript, dobry sandbox, łatwa konfiguracja.

GitHub Copilot Agents — najlepszy dla zespołów już na GitHub, integracja z VS Code, ale mniej granularna kontrola uprawnień.

Open-source (np. Aider) — najlepszy dla firm, które chcą pełną kontrolę, ale wymaga więcej konfiguracji.

Dla większości polskich firm: Claude Code Agent. Dlaczego? Bo [1] plik claude.m to prosty format, a sandbox przez folder działa out-of-the-box.

Krok 2: Skonfigurować deny-listę i sandbox (4 godziny)

Uruchamiasz agenta w folderze projektu. /init. Edytujesz claude.m. Dodajesz deny-listę dla operacji wysokiego ryzyka. Testujesz: prosisz agenta, żeby spróbował wykonać rm -rf. Agent powinien odmówić.

Jeśli używasz GitHub Copilot: włączasz partner agents w VS Code, tworzysz scoped token na GitHub, konfigurujesz credentials.

Jeśli używasz n8n: tworzysz dwa środowiska (dev/prod), konfigurujesz scoped credentials, testujesz dostęp.

Krok 3: Wdrożyć code review (8 godzin)

Opcja A (szybka): manualny review. Agent generuje kod, człowiek przegląda przed merge. Działa, ale wymaga dyscypliny. Jeśli zespół ma 5 osób, każdy review to 15 minut. To 75 minut na dzień, jeśli agent pracuje non-stop.

Opcja B (zaawansowana): agent-reviewer. Drugi agent czyta kod, raportuje problemy. Wymaga skonfigurowania drugiego agenta, ale działa automatycznie.

Dla większości: Opcja A przez pierwszy miesiąc, potem Opcja B jeśli się sprawdzi.

Krok 4: Monitorować i iterować (bieżący proces)

Każdy tydzień: przegląd commitów agenta. Czy agent generuje dobry kod? Czy reviewer/człowiek łapie błędy? Czy deny-lista działa? Czy agent próbuje obejść ograniczenia?

Po miesiącu: dostosowanie. Może okazać się, że agent potrzebuje dostępu do więcej narzędzi. Lub że deny-lista jest za liberalna. Iterujesz.

Ograniczenia tego podejścia

Jedno ważne: agent-reviewer to nie jest gwarancja. Reviewer to też agent — może mieć halucynacje, może przeoczyć problem. Nie zastępuje człowieka, tylko go wspomaga. Jeśli kod jest krytyczny (bezpieczeństwo, finanse, dane osobowe), człowiek musi przejrzeć kod osobiście.

Drugie: deny-listy są statyczne. Jeśli pojawi się nowa komenda, którą agent może wykorzystać do ataku, Twoja deny-lista jej nie zablokuje. Dlatego monitoring i auditowanie to nie jednorazowa konfiguracja, tylko bieżący proces.

Trzecie: koszt. Jeśli Twój zespół generuje 1000 linii kodu dziennie przez agenta, to 50 000 tokenów. Reviewer to kolejne 50 000. Przy Claude API to około 15 groszy dziennie. Ale jeśli masz 10 agentów pracujących równolegle, to 1,50 PLN dziennie, czyli 45 PLN miesięcznie. To jest tanie, ale trzeba o tym wiedzieć.

Co robić teraz

Wybierz narzędzie (Claude Code Agent dla większości). Uruchom agenta w testowym folderze. Wygeneruj claude.m. Dodaj deny-listę dla rm -rf, sudo, dostępu poza projektem. Przetestuj: agent powinien odmówić wykonania zakazanych komend.

Jeśli test przejdzie, wdrażasz w prawdziwym projekcie. Pierwszy tydzień: tylko obserwacja. Agent pracuje, człowiek przegląda każdy commit. Drugi tydzień: jeśli nie ma problemów, włączasz agent-reviewer lub manualny review.

To jest wdrożenie, które zajmie Ci 48 godzin. Nie jest idealne, ale jest praktyczne. I znacznie bezpieczniejsze niż uruchamianie agenta bez żadnych guardrails.

Źródła

[1] Claude Code Agent — jak działa, co potrafi, https://dokodu.it/blog/agenci-ai/claude-code-agent

[2] How to Safely Run Coding Agents, https://aissential.tech/articles/03bf59eb-09e1-4c68-904c-a537ec6d40b4

[3] How to Safely Use AI Coding Agents in a Real Codebase, https://travis.media/blog/safely-use-ai-coding-agents/

[4] AI coding agent i ryzyko łańcucha dostaw oprogramowania, https://breachroad.com/blog/ai-coding-agent-lancuch-dostaw/

[5] Claude & Codex Agents in VS Code, https://www.youtube.com/watch?v=OWYQ8Mn7KqE

[6] Poradnik n8n dla Początkujących 2026: Twórz Agentów AI, https://www.youtube.com/watch?v=--xbicI9h6U