Akceptacja produkcji jako granica systemu
Bramkę produkcji egzekwują tożsamość, credentials, branch protection i platforma wdrożeniowa — nie zdanie w prompcie ani zmienna środowiskowa, którą agent może ustawić. Agent przygotowuje kod, testy, dowody review, plan release i rollback. Nazwany człowiek zatwierdza chroniony job produkcyjny, a audyt łączy decyzję z niezmienną rewizją.
Pytanie scorecardu: Jakie kontrole zatrzymują agenta przed wdrożeniem niezweryfikowanej zmiany?
Maksymalna odpowiedź: Środowisko agenta nie ma stałych credentials produkcji; protected branches i chronione środowisko CI wymagają nazwanej akceptacji człowieka i zachowują audyt.
Cztery niezależne kontrole
Dział zatytułowany „Cztery niezależne kontrole”- Tożsamość: commity agenta i joby CI używają osobnych service identities.
- Credentials: lokalne sesje i zwykłe runnery nie dostają sekretów produkcji. Chroniony job otrzymuje krótkotrwałe dane dopiero po approval.
- Repozytorium: direct push i bypass są blokowane; required checks i code owners zależą od ścieżki i ryzyka.
- Deployment: środowisko produkcyjne wymaga uprawnionego approvera i zapisuje rewizję, dowody, aktora, czas oraz wynik.
Hook może blokować oczywiste lokalne polecenia jako defense in depth. Nie jest granicą autoryzacji: alias, wrapper, inny klient lub przejęty skrypt może ominąć prefix matching.
Lokalne ograniczenia per narzędzie
Dział zatytułowany „Lokalne ograniczenia per narzędzie”Użyj najsilniejszego trybu dostępnego na bieżącej powierzchni, a następnie polegaj na kontrolach zewnętrznych:
- Claude Code: skonfiguruj permissions i hooki według bieżącego oficjalnego schematu; nie udostępniaj credentials produkcji.
- Cursor CLI: użyj
--sandbox enabled, gdy pasuje, i nie stosuj--forcedo omijania approvals w pracy regulowanej. - Codex CLI: preferuj
--sandbox workspace-writeprzy implementacji; approval policy ustaw osobno i nie traktuj przestarzałego--full-autojako polityki produkcyjnej. - Wszystkie: pracuj w izolowanym worktree z lokalnymi lub efemerycznymi usługami, nigdy w checkout z dostępem do żywej produkcji.
Kontrakt dowodów release
Dział zatytułowany „Kontrakt dowodów release”Przed pokazaniem człowiekowi przycisku approval job ujawnia:
- podlinkowane
intent.md,spec.md,plan.mdi dokładną rewizję; - wyniki testów, lint, types, security i migracji;
- findings z osobnego review agenta wraz z dyspozycjami;
- scope wdrożenia, blast radius, query obserwowalności i rollback;
- pominięte checki, wyjątki i ich ownerów;
- podpisy lub provenance artefaktów, jeśli wspiera je platforma.
Approver musi móc odrzucić release bez ujawniania agentowi credentials.
Prompty do skopiowania
Dział zatytułowany „Prompty do skopiowania”Przygotuj raport gotowości produkcyjnej dla tej dokładnej rewizji.Podlinkuj intent.md, spec.md, plan.md, CI, security, migration i rollback.Oddziel passed, failed, skipped oraz manual checks.Nie wdrażaj, nie zatwierdzaj i nie dotykaj produkcji.Zrecenzuj dowody release jako sceptyczny operator.Wypisz blokery, brakujący rollback proof, checki bez ownerai różnice między zaakceptowanym planem a rewizją.Zwróć tylko rekomendację; nazwany człowiek podejmuje decyzję.Gdy bramka zawodzi
Dział zatytułowany „Gdy bramka zawodzi”Lokalny hook jest jedyną barierą. Usuń credentials produkcji ze środowiska i egzekwuj granicę w forge oraz platformie deploymentu.
Bot może ominąć branch protection. Usuń administrative bypass i testuj prawdziwą tożsamością usługi.
Approval następuje bez pełnych dowodów. Ustaw checki dowodowe jako prerequisites środowiska.
Emergency access staje się stały. Ogranicz break-glass w czasie, loguj użycie i wymagaj post-incident review.
Weryfikacja granicy
Dział zatytułowany „Weryfikacja granicy”- Lokalny i chmurowy agent nie może znaleźć ani użyć credentials produkcji.
- Direct push i self-approval zawodzą dla faktycznej tożsamości agenta.
- Chroniony job nie startuje bez uprawnionego, nazwanego approvera.
- Approval wskazuje jedną niezmienną rewizję i jej dowody.
- Rollback jest przećwiczony bez dostępu produkcyjnego agenta implementującego.
- Audyt rozróżnia autora, reviewera, approvera, deployera i wynik.
Bramka w cyklu życia
Dział zatytułowany „Bramka w cyklu życia”Zastosuj warstwowe review z Deploy i poziomy działań z Governance i autonomia.