Nie usunąłem stanowiska analityka bezpieczeństwa. Zautomatyzowałem 15 godzin tygodniowo, które traci na triage podatności. Oto jak zbudowany jest agent — i cztery miejsca, w których próbuje zrobić coś głupiego.
Nagłówek ma odwróconą ramę
„SI zabierze ci pracę" to zła jednostka miary. Etat to nie monolit, który agent połyka w całości. Etat to wiązka procesów, a większość z nich to mozół.
W pracy konsultingowej widziałem, jak zespoły bezpieczeństwa tracą ponad 15 godzin tygodniowo na triage podatności — czytanie wyników skanerów, analizowanie szczegółów CVE i decydowanie, co naprawdę ma znaczenie — zanim powstanie choć jedna poprawka. Nikt nie wybrał tej pracy dlatego, że kocha triage. Wybrali ją dla trudnych części: oceny, architektury i nietypowego incydentu o drugiej w nocy.
Nie zbudowałem więc agenta, który ma być inżynierem bezpieczeństwa. Zbudowałem agenta przejmującego triage. Działa według harmonogramu na mojej infrastrukturze: skanuje, ustala priorytety, proponuje poprawki, wdraża te bezpieczne, a resztę przekazuje mi. Poniżej opisuję jego budowę oraz cztery miejsca, w których próbuje zrobić coś głupiego, i sposób, w jaki go powstrzymuję.
Wybierz proces, nie etat
Prawdziwa umiejętność w używaniu agentów to nie prompting. To zakresowanie — wycięcie dobrze uformowanego procesu z rozmytego etatu. Pomyl się tutaj, a żaden model cię nie uratuje.
Proces jest dobrym celem dla agenta, gdy wygląda tak:
| Dobry cel dla agenta | Zły cel |
|---|---|
| Duży wolumen, powtarzalny | Jednorazowy, szyty na miarę |
| Ma sprawdzalną „poprawną odpowiedź" | Niejednoznaczny, oparty na guście |
| Wynik, który człowiek szybko zweryfikuje | Wynik, którego nikt nie sprawdzi |
| Mierzalny | Oceniany „na czuja" |
| Mała skala szkód, albo da się go zabezpieczyć bramką | Domyślnie nieodwracalny |
Triage podatności wypada dobrze w każdym wierszu. „Bądź naszym architektem bezpieczeństwa" wypada źle we wszystkich. Skieruj agenta na to drugie, a dostaniesz pewny siebie, wiarygodnie wyglądający, nieodpowiedzialny bałagan. Skieruj go na pierwsze, a odzyskasz swój tydzień.
Kształt agenta, który wykonuje realną pracę
Błędem jest jeden gigantyczny prompt, który „ogarnia bezpieczeństwo". Realna praca potrzebuje małego potoku wąskich ról, gdzie każda robi jedno zadanie i przekazuje dalej ustrukturyzowany wynik — dokładnie ten podział triage → analiza → remediacja, o którym pisałem wcześniej.
W praktyce: skaner (Trivy, Grype) produkuje wyniki; lokalny model (Devstral przez LM Studio) ustala ich priorytet i odsiewa szum; Claude CLI pisze samą poprawkę; harmonogram (systemd) uruchamia pętlę; a każdy krok zapisuje się do logu, który możesz później przeczytać. Tanie rozumowanie zostaje lokalnie, drogie idzie do modelu frontier, i nic nie jest czarną skrzynką.
Ale architektura nie jest sednem. Sednem jest przepływ sterowania:
# The shape that matters: propose -> gate -> act. Never act -> explain.
findings = scan() # what's vulnerable
plan = triage(findings) # rank, drop false positives
for fix in plan.high_confidence: # the boring 80%
if low_risk(fix) and tests_pass(sandbox(fix)):
apply(fix); log(fix) # automatic, fully audited
else:
queue_for_human(fix) # the risky 20%
notify(summary) # what I did, what I left for you
Agent, który działa, a potem wyjaśnia, to ryzyko. Agent, który proponuje, przechodzi przez bramkę, a potem działa, to współpracownik. Cały projekt tkwi w tej kolejności.
Cztery miejsca, w których próbuje zrobić coś głupiego
Tu właśnie jest prawdziwa inżynieria. Każde z nich to realny tryb awarii, nie hipoteza.
1. Halucynuje poprawkę — albo zwraca śmieci. Zwłaszcza modele lokalne podadzą ci pewny siebie, źle sformatowany output. Dlatego output modelu to niezaufane wejście. Mój agent parsuje JSON modelu defensywnie i odrzuca wszystko, co się nie waliduje, zamiast działać na niedokończonym planie. Jeśli struktura jest błędna, poprawka się nie wykonuje.
2. Chce zadziałać na fałszywym alarmie. Skanery nadmiernie raportują. Gorliwy agent chętnie „naprawi" rzeczy, które nigdy nie były zepsute, mieląc twoje systemy na jałowym biegu. Bramką jest poziom krytyczności plus weryfikacja: potwierdź, że podatność jest realna i osiągalna, zanim cokolwiek zostanie ruszone.
3. „Poprawka" psuje trzy inne rzeczy. „Po prostu zaktualizuj bibliotekę" brzmi prosto, dopóki opiekun nie zmienił API i dwie usługi nie padną. Nic nie jest wdrażane automatycznie bez wcześniejszego przejścia testów w piaskownicy, a każda zmiana ma rollback. Poprawki niskiego ryzyka idą automatycznie; wszystko ze skalą szkód czeka na człowieka.
4. Ma więcej dostępu, niż potrzebuje. Autonomiczny agent z szerokimi uprawnieniami to najniebezpieczniejsza rzecz w twoim stacku — działa z twoimi uprawnieniami, a jedna zła instrukcja (albo prompt injection w czymś, co czyta) staje się realnym działaniem. Najmniejszy przywilej, izolacja i log każdej komendy nie są opcjonalne. Lokalizacja danych i modele lokalne cię tu nie uratują; ratuje kontrola dostępu.
Wzorzec pod wszystkimi czterema: agent proponuje, bramka decyduje, a człowiek odpowiada za wszystko, co ryzykowne. Zautomatyzuj nudne 80%. Miej oko na 20%.
Co zostaje przy człowieku
Augmentacja to nie łagodniejsze słowo na zastąpienie. To podział pracy.
Agent przejmuje mozół: czytanie, ustalanie priorytetów, szablonową poprawkę, papierologię. Człowiek przejmuje to, czemu agenta nie można zaufać — osąd w przypadkach brzegowych, zatwierdzenia o dużej skali szkód, projekt systemu i odpowiedzialność, gdy coś się zepsuje. Ktoś wciąż odpowiada. To nie przechodzi na model.
Analityk, którego triage zautomatyzowałem, nie stracił pracy. Stracił tę część pracy, przez którą chciał odejść. Ta sama osoba przegląda wyniki zamiast wykonywać powtarzalne czynności.
Do czego to się uogólnia
Zarządzanie podatnościami to tylko najczystszy przykład — duży wolumen, mierzalny, da się zabezpieczyć bramką. Ten sam przepis przenosi się na każdy proces o podobnym kształcie:
- triage reagowania na incydenty
- pierwszy przegląd kodu
- provisioning infrastruktury
- pilnowanie potoków danych
- eskalacja zgłoszeń supportu
Znajdź proces, który kosztuje kogoś 15 godzin tygodniowo. Potraktuj go schematem proponuj-bramkuj-działaj. Zostaw człowieka przy ryzykownych 20%. Powtórz.
Konkluzja
Pytanie nigdy nie brzmiało „czy agent cię zastąpi". Brzmi „które ze swoich tygodni przestaniesz marnować" — i „czy to ty projektujesz agenta, czy ktoś projektuje system wokół ciebie".
Agent nie zastąpił analityka. Oddał mu jego czwartek.
Najważniejsze wnioski
- Agenci nie zastępują etatów; zastępują procesy. Umiejętnością jest wybór właściwego.
- Dobre cele są powtarzalne, weryfikowalne, mierzalne i da się je zabezpieczyć bramką. Złe są oparte na guście i nieodwracalne.
- Buduj potok wąskich ról, nie jeden megaprompt. Tanie rozumowanie lokalnie, drogie na froncie (frontier).
- Bezpieczeństwo tkwi w kolejności: proponuj → bramkuj → działaj, nigdy działaj → wyjaśniaj.
- Traktuj output modelu jako niezaufany, testuj przed wdrożeniem, miej rollbacki i egzekwuj najmniejszy przywilej.
- Automatyzuj nudne 80%; zostaw człowieka — i odpowiedzialność — przy 20%.
Jestem architektem systemów specjalizującym się w AI/ML, bezpiecznej infrastrukturze i automatyzacji agentowej. Poprzez AI-Flow pomagam organizacjom stosować agentów AI w rzeczywistych procesach — bez oddawania im pełnej kontroli.
#AgenciSI #Automatyzacja #DevSecOps #SI #HumanInTheLoop #AgentEngineering