Nie mierzę jakości agenta liczbą plików, które zmienił. Liczy się to, czy przygotował poprawną zmianę, pokazał dowody i zatrzymał się tam, gdzie powinien zdecydować człowiek.
Prosty przepływ pomaga uniknąć dwóch skrajności: ręcznego wykonywania każdej powtarzalnej czynności i pełnego dostępu agenta do systemu bez kontroli. NIST SSDF zaleca wbudowanie praktyk bezpieczeństwa w cały cykl pracy nad oprogramowaniem. W małym zespole można zacząć od kilku jasnych bramek.
Pięć bramek dla zmiany przygotowanej przez agenta
- Zakres: zadanie opisuje cel, ograniczenia, pliki lub moduły, których dotyczy, oraz warunek akceptacji.
- Oddzielne środowisko: agent pracuje na gałęzi lub kopii, a nie bezpośrednio na działającej produkcji.
- Weryfikacja: uruchamia kompilację i właściwe kontrole. Wynik jest zapisywany, a nie oparty na stwierdzeniu „wygląda dobrze”.
- Przegląd: człowiek sprawdza zmianę, skutki uboczne, uprawnienia i treść błędów.
- Wdrożenie: integracja i publikacja przechodzą przez ustalony proces. Cofnięcie zmiany jest możliwe i wiadomo, kto odpowiada.
flowchart LR B[Brief
zakres + kryteria] --> W[Gałąź robocza
bez dostępu do produkcji] W --> A[Agent przygotowuje zmianę] A --> V{Kompilacja i kontrole
przeszły?} V -->|nie| R[Poprawka lub stop] R --> A V -->|tak| H{Przegląd człowieka
i akceptacja?} H -->|nie| R H -->|tak| P[Kontrolowane wdrożenie] P --> O[Monitoring + możliwość cofnięcia] classDef focus fill:#103844,stroke:#18d5e7,color:#f4fbfc,stroke-width:2px classDef decision fill:#172733,stroke:#91dfe2,color:#f4fbfc classDef work fill:#0b1d27,stroke:#7396a1,color:#edf5f6 class H,P focus class V decision class B,W,A,R,O work
W skrócie: zadanie → oddzielna gałąź → zmiana agenta → automatyczne kontrole → przegląd człowieka → kontrolowane wdrożenie i monitoring.
Agent dostaje tylko potrzebne uprawnienia
Jeśli zadaniem jest poprawienie opisu na stronie, agent nie potrzebuje klucza do produkcyjnej bazy klientów. Jeśli ma naprawić test, nie musi mieć prawa wdrażania. To samo dotyczy dostępu do plików, narzędzi, sekretów i środowisk.
Przyznaj konkretne uprawnienia do konkretnego zadania, ustaw limit działania i zapisuj, z jakich narzędzi agent korzysta. Zewnętrzny tekst, zgłoszenie lub dokument traktuj jak dane wejściowe, a nie jak polecenie nadrzędne. OWASP zwraca uwagę na ryzyko prompt injection i nadmiernej autonomii systemów korzystających z narzędzi.
Test ma odpowiadać zmianie
Nie każda poprawka wymaga tego samego zestawu testów. Zmiana logiki płatności powinna przejść inne kontrole niż korekta nagłówka. Dla ważnych ścieżek warto zachować prosty scenariusz: wejście, oczekiwany wynik, przypadki brzegowe i sygnał błędu.
Jeśli projekt nie ma testów automatycznych, pierwsza bramka może być skromna: poprawna kompilacja, sprawdzenie konkretnej ścieżki w przeglądarce i lista kontrolna dla człowieka. Z czasem te kroki można automatyzować.
Co mierzyć po wdrożeniu
- ile zmian agenta przechodzi kontrolę za pierwszym razem;
- ile poprawek wraca z przeglądu i dlaczego;
- czy czas od zadania do bezpiecznej publikacji się skraca;
- czy pojawiły się błędy po wdrożeniu i jak szybko je cofnięto;
- czy uprawnienia agenta pozostały ograniczone do jego roli.
To są dane do usprawniania procesu, a nie ranking zespołu. Gdy agent popełnia ten sam błąd, poprawiamy test, opis zadania albo granicę uprawnień.
Od czego zacząć w firmie?
Wybierz małe zadanie o niskim ryzyku, na przykład aktualizację treści albo poprawę testu w odizolowanej gałęzi. Zapisz, co agent może czytać i zmieniać, uruchom kontrolę oraz poproś człowieka o przegląd. Nie podłączaj produkcyjnych sekretów tylko po to, by szybciej zobaczyć demo.
Źródła i dalsza lektura
- NIST SP 800-218: Secure Software Development Framework
- NIST SP 800-218A: praktyki bezpieczeństwa dla systemów generatywnej AI
- OWASP: Excessive Agency
- OWASP: Top 10 for LLM Applications
To wzorzec organizacji pracy, nie gwarancja bezpieczeństwa ani rekomendacja wdrożenia konkretnego narzędzia.