# Deterministyczny szkielet platformy agentowej > Nieprzewidywalną moc modeli zamienia w audytowalny wynik deterministyczny szkielet: walidacja-pętla, policy-as-code jako bramka, środowiska efemeryczne i tożsamość nie-ludzka. URL: https://eiac.dev/blog/deterministyczny-szkielet-adp Filar: SDLC / Policy-as-Code Data: 2026-03-23 Tagi: platform-engineering, policy-as-code, ci, security, agents --- W [poprzedniej części](/blog/cztery-poziomy-agentowego-wytwarzania) 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.

Teza

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.

Pętla walidacji — niepowodzenie wraca do agenta (ponów), a powtarzalne błędy poprawiają jego model działania, by ta sama klasa błędu nie wracała.

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](/katalog/dagger)) i szybkich, jednorazowych klastrów ([kind](/katalog/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](/katalog/terraform)/[OpenTofu](/katalog/opentofu), manifesty [Kubernetes](/katalog/kubernetes), charty [Helm](/katalog/helm)) muszą działać jako **bramki w CI**, a nie audyty po fakcie. Narzędzia jak [OPA](/katalog/open-policy-agent), [Kyverno](/katalog/kyverno) czy [Checkov](/katalog/checkov) przestają być dodatkiem, a stają się obowiązkowym krokiem. Przykład — test konfiguracji przez [Conftest](/katalog/conftest) (silnik OPA/Rego) jako krok pipeline: ```rego # 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)" } ``` ```yaml # 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,CRITICAL ``` Dlaczego 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](/katalog/gatekeeper) lub [Kyverno](/katalog/kyverno) (admission control; Kyverno trzyma polityki w YAML, bez osobnego języka), a statycznie w CI przez [Conftest](/katalog/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. ```yaml # 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](/katalog/kind), a dla cięższych przypadków [k3s](/katalog/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](/katalog/dex)). - **Krótkożyciowe poświadczenia** zamiast statycznych sekretów — pobierane dynamicznie z [Vault](/katalog/vault)/[OpenBao](/katalog/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](/katalog/gitsign)), by dało się udowodnić, skąd pochodzi zmiana. Rozwijamy te wzorce w artykule [Security Plane](/blog/security-plane-sekrety-tozsamosc-policy); 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](/blog/platform-engineering-normalizacja-pracy). 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](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) i [AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) — co rozwijam w częściach o [DORA w praktyce](/blog/dora-w-praktyce-platformy) i AI Act. Bez tej warstwy cała reszta to życzenie, nie system — i żaden model tego za Ciebie nie załata.