Przejdź do głównej zawartości

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.

  1. Tożsamość: commity agenta i joby CI używają osobnych service identities.
  2. Credentials: lokalne sesje i zwykłe runnery nie dostają sekretów produkcji. Chroniony job otrzymuje krótkotrwałe dane dopiero po approval.
  3. Repozytorium: direct push i bypass są blokowane; required checks i code owners zależą od ścieżki i ryzyka.
  4. 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.

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 --force do omijania approvals w pracy regulowanej.
  • Codex CLI: preferuj --sandbox workspace-write przy implementacji; approval policy ustaw osobno i nie traktuj przestarzałego --full-auto jako polityki produkcyjnej.
  • Wszystkie: pracuj w izolowanym worktree z lokalnymi lub efemerycznymi usługami, nigdy w checkout z dostępem do żywej produkcji.

Przed pokazaniem człowiekowi przycisku approval job ujawnia:

  • podlinkowane intent.md, spec.md, plan.md i 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.

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 ownera
i różnice między zaakceptowanym planem a rewizją.
Zwróć tylko rekomendację; nazwany człowiek podejmuje decyzję.

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.

  • 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.

Zastosuj warstwowe review z Deploy i poziomy działań z Governance i autonomia.