W poprzedniej części napisałem, że walidacja zmienia się z bramki w pętlę, a policy-as-code staje się nieodzowne. No dobra, deko mięcha — rozłóżmy to na części: co konkretnie w deterministycznej warstwie platformy musi się zmienić, by agenci mogli generować zmiany seriami, bezpiecznie i bez zatkania systemu.
Bezpieczeństwo agentów nie wynika z tego, że model jest mądry. Wynika z tego, że każdy artefakt — niezależnie od autora — musi przejść przez te same, maszynowo egzekwowane bramki, zanim ruszy dalej.
Walidacja przestaje być bramką, staje się pętlą
W świecie ludzkim walidacja to przystanek: deweloper składa PR, CI uruchamia testy, recenzent ogląda zmianę. Gdy agenci produkują PR-y równolegle, ten model się załamuje — pojedynczy checkpoint natychmiast staje się wąskim gardłem.
Rozwiązaniem jest pętla: gdy walidacja zawodzi, sygnał błędu wraca do agenta, który poprawia implementację i próbuje ponownie. Cykl powtarza się, aż artefakt spełni wymagania.
Aspiracja jest zaskakująca: faza weryfikacji powinna stać się nudna. Zanim zmiana dotrze do walidacji, powinna niemal zawsze przechodzić. Jeśli nie przechodzi, to sygnał, że trzeba poprawić model działania agenta (kontekst, reguły, oczekiwania testowe), a nie tylko tę jedną zmianę. Walidacja przestaje być pasywną siatką bezpieczeństwa, a staje się mechanizmem, który wypycha rozwiązywanie defektów w górę procesu.
Trzy konsekwencje pętli walidacji
1. Presja na pojemność CI. Agenci iterują znacznie agresywniej niż ludzie — powtarzają, aż przejdzie, i uruchamiają szersze zestawy weryfikacji. To oznacza więcej przebiegów pipeline’u, więcej środowisk efemerycznych i potencjalnie dramatycznie wyższe zużycie compute. Źle zaprojektowane CI potrafi rosnąć kosztowo szybciej niż przyrost produktywności. Stąd waga cache’owania, przenośnych kroków (np. Dagger) i szybkich, jednorazowych klastrów (kind) zamiast ciężkich, długowiecznych środowisk.
2. Weryfikacja musi wyjść poza testy jednostkowe. Same unit testy nie zastąpią osądu recenzenta. Organizacje poszerzają deterministyczną weryfikację o scenariusze e2e, testy wydajności, analizę zależności i licencji oraz kontrolę integralności środowiska. Na froncie często dominuje weryfikacja zachowania (deploy preview, a nawet agenci „usability” robiący zrzuty/nagrania); backend wymaga twardszych dowodów (scenariusze, regresje czasu startu, polityki bezpieczeństwa).
3. Bezpieczeństwo i polityki muszą być automatyczne. Przy wolumenie zmian generowanych maszynowo ręczny przegląd bezpieczeństwa nie skaluje się. Skany podatności, wykrywanie sekretów, kontrola zgodności — wszystko to musi być częścią pętli walidacji, nie audytem po wdrożeniu.
Policy-as-code jako deterministyczna bramka
Najważniejsza zasada: polityki na artefaktach IaC (plany Terraform/OpenTofu, manifesty Kubernetes, charty Helm) muszą działać jako bramki w CI, a nie audyty po fakcie. Narzędzia jak OPA, Kyverno czy Checkov przestają być dodatkiem, a stają się obowiązkowym krokiem.
Przykład — test konfiguracji przez Conftest (silnik OPA/Rego) jako krok pipeline:
# policy/deployment.rego
package main
deny contains msg if {
input.kind == "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot
msg := "kontener musi działać jako non-root (runAsNonRoot: true)"
}# krok w CI (Gitea Actions / dowolne) — twarda bramka
- run: conftest test k8s/ --policy policy/
- run: checkov -d infra --soft-fail-on LOW
- run: trivy config infra --exit-code 1 --severity HIGH,CRITICALDlaczego to akurat teraz „non-negotiable”? Bo skodyfikowane, maszynowo egzekwowalne reguły są warunkiem bezpiecznego przejścia z Poziomu 2 na 3: jakość warstwy polityk wprost wyznacza, ile autonomii możesz bezpiecznie przyznać agentom. W klastrze te same reguły można egzekwować w czasie wdrożenia przez OPA Gatekeeper lub Kyverno (admission control; Kyverno trzyma polityki w YAML, bez osobnego języka), a statycznie w CI przez Conftest — ta sama intencja, różne warstwy.
Dodatkowy niuans kolejności: AI-asystowany przegląd kodu działa najlepiej wcześnie w pętli — automatyczny recenzent generuje uwagi, zanim spojrzy na to człowiek, a agent od razu je wchłania. Do walidacji trafia więc artefakt, w którym usterki mechaniczne są już rozwiązane.
Środowiska efemeryczne: izolacja i dowód
Skoro wiele zmian biegnie równolegle, nie mogą sobie nawzajem deptać po środowiskach. Stąd środowiska efemeryczne — tworzone na żądanie, jednorazowe, izolowane. Na froncie służą jako deploy preview (recenzent ogląda działającą funkcję, nie kod); na backendzie jako miejsce, gdzie biegną scenariusze e2e.
# efemeryczny klaster do walidacji w CI, kasowany po teście
- run: kind create cluster --name pr-${PR_NUMBER}
- run: kubectl apply -k overlays/ci
- run: npm run test:e2e
- run: kind delete cluster --name pr-${PR_NUMBER}Klucz: środowisko jest dowodem. Walidacja ma wyprodukować dowód na tyle mocny, by zastąpić ręczne czytanie diffów — a efemeryczny, czysty klaster (kind, a dla cięższych przypadków k3s) daje powtarzalny punkt odniesienia.
Tożsamość nie-ludzka i granice działania
Gdy agent „wysyłany jest do pracy”, musi działać z własną, ograniczoną tożsamością — nie z poświadczeniami człowieka. To warunek audytu („kto/co to zrobił”) i ograniczenia promienia rażenia. Wzorce:
- Tożsamość nie-ludzka dla agenta z wąskim zakresem uprawnień (co wolno dotknąć), brokerowana przez niezależny IdP (np. Dex).
- Krótkożyciowe poświadczenia zamiast statycznych sekretów — pobierane dynamicznie z Vault/OpenBao, nigdy zaszyte w repo.
- Izolacja workspace dla równoległych przebiegów, by nie kolidowały.
- Provenance artefaktów — podpisywanie wydań/commitów (np. bezkluczowo przez gitsign), by dało się udowodnić, skąd pochodzi zmiana.
Rozwijamy te wzorce w artykule Security Plane; tu istotne jest jedno: bez tożsamości nie-ludzkiej autonomia agentów jest nieaudytowalna, a więc nie do utrzymania w organizacji pod nadzorem.
Mapowanie na pętlę OODA
Wszystko to wraca do pętli z wprowadzenia. Deterministyczny szkielet nie spowalnia pętli — on pozwala ją bezpiecznie przyspieszyć: polityki i walidacja to „orientacja” (wspólny model, co wolno), środowiska efemeryczne to tani, powtarzalny „test działania”, a obserwowalność i audyt domykają sprzężenie. Im mocniejszy szkielet, tym ciaśniejszą pętlę można powierzyć maszynie.
Podsumowanie
Deterministyczny szkielet to nie biurokracja spowalniająca agentów — to system bezpieczeństwa, który w ogóle umożliwia ich pracę na skalę. Walidacja-pętla, policy-as-code jako bramka, środowiska efemeryczne i tożsamość nie-ludzka zamieniają nieprzewidywalną moc modeli w przewidywalny, audytowalny wynik. To również dokładnie ta warstwa, której domagają się regulacje — DORA i AI Act — co rozwijam w częściach o DORA w praktyce i AI Act. Bez tej warstwy cała reszta to życzenie, nie system — i żaden model tego za Ciebie nie załata.