Akceptacja produkcji jako granica systemu

Poziom 2 Poradnik Zaktualizowano 2026-10-12

Bramka akceptacji produkcji nie pozwala agentom wdrożyć niesprawdzonych zmian, bo umieszcza decyzję tam, dokąd żadna sesja agenta nie sięga: osobne tożsamości agenta i wdrożenia, brak stałych poświadczeń produkcyjnych w środowiskach agentów, chronione gałęzie bez obejść oraz środowisko wdrożeniowe zatwierdzane przez wskazanego człowieka. Prompty i hooki jedynie wcześnie wyłapują pomyłki.

Twoi agenci przez cały dzień otwierają pull requesty, a jeden z nich właśnie uruchomił w terminalu deploy.sh production, bo token leżał w .env, a prompt mówił „dokończ zadanie”. Tym razem nic się nie zepsuło. Ta strona jest dla dewelopera, który odpowiada za potok wydań, i dla tech leada, który na pytanie „co właściwie powstrzymuje agenta przed wdrożeniem na produkcję?” musi odpowiedzieć czymś lepszym niż „kazaliśmy mu tego nie robić”.

Pytanie scorecardu (Q20): Jakie kontrole powstrzymują agenta przed bezpośrednim wdrożeniem niezweryfikowanych zmian na produkcję?

Odpowiedź za maksimum punktów: Środowisko agenta nie ma stałych poświadczeń produkcyjnych; chronione gałęzie i ograniczone środowisko CI wymagają akceptacji wskazanego człowieka i zostawiają ślad audytowy.

Co daje ci bramka akceptacji produkcji

Konfigurację GitHuba w sześciu krokach, w której jedyną drogą na produkcję jest jeden zatwierdzony job na jednej rewizji.
Workflow wydania, który najpierw buduje dowody, a poświadczenia chmurowe wydaje dopiero po akceptacji.
Ograniczenia po stronie sesji w Claude Code, Codeksie i Cursorze, które trzymają produkcję poza zasięgiem, zanim w ogóle zadziała CI.
Trzy prompty do skopiowania: raport gotowości, sceptyczny przegląd wydania i audyt samej bramki.
Siedem testów granicy uruchamianych jako tożsamość agenta, dzięki którym udowadniasz, że bramka działa, zamiast ufać stronie ustawień.

Dlaczego prompt, hook ani zmienna środowiskowa nie są bramką?

Agent może zmienić, przeformułować albo obejść wszystko, co żyje w jego własnej sesji. RELEASE_APPROVAL=true to napis, który ustawi każdy proces, prompt systemowy to rada, a hook dopasowuje tekst polecenia: sh -c '…', skrypt opakowujący albo inny klient prześlizgną się obok niego. Takie kontrole przydają się jako wczesne ostrzeżenie. Granicą muszą być cztery kontrole, których tożsamość agenta nie może zmienić:

Kontrola	Co egzekwuje	Jak ją testujesz
Tożsamość	Commity agenta, osoba scalająca lub zatwierdzająca i chmurowa rola wdrożeniowa (przyjmowana przez OIDC) to odrębne podmioty	Ślad audytowy chmury pokazuje rolę wdrożeniową, nigdy poświadczenie agenta ani osobiste
Poświadczenia	Żadna sesja agenta ani zwykły runner nie ma sekretu produkcji; zatwierdzony job dostaje krótkotrwały	Wylistowanie zmiennych i sekretów z sesji agenta nie znajduje nic użytecznego
Repozytorium	Każda zmiana trafia do domyślnej gałęzi przez pull request, wymagane checki i code ownera, bez obejść	Bezpośredni push jako tożsamość agenta kończy się błędem
Wdrożenie	Job produkcyjny czeka na wskazanego recenzenta, który go nie uruchomił	Nie da się zatwierdzić własnego wdrożenia, a akceptacja wskazuje jeden SHA commita

Etap Deploy umieszcza tę bramkę w cyklu życia. Ta strona to szczegółowa konfiguracja.

Jak skonfigurować bramkę produkcji w GitHubie?

Kroki dotyczą GitHuba, bo jego reguły środowisk i claimy OIDC zweryfikowaliśmy (dokumentacja GitHuba, sprawdzona 2026-09-26). Inne platformy hostingu kodu (GitLab, Bitbucket) i platformy wdrożeniowe potrzebują tych samych czterech kontroli pod własnymi nazwami.

Daj agentowi własną tożsamość. Uruchamiaj agentów jako GitHub App albo osobne konto bota z prawem zapisu tylko do gałęzi i pull requestów — nigdy jako administratora i nigdy z osobistym tokenem inżyniera, który ich uruchomił. GitHub App dostaje prawo zapisu do zawartości i pull requestów, ale nigdy uprawnienia workflows, więc nie może zmienić .github/workflows/. Tożsamość agentów, poświadczenia i sekrety opisuje konta usługowe per agent i zakresy tokenów.
Chroń domyślną gałąź rulesetem. W Settings › Rules › Rulesets wskaż domyślną gałąź i włącz: wymagany pull request, wymagane review code ownerów, odrzucanie nieaktualnych akceptacji po nowych commitach (albo akceptację kogoś innego niż ostatni pushujący) oraz wymagane status checki z przypiętą aplikacją źródłową. Listę obejść (bypass list) zostaw pustą. Aplikacja agenta na tej liście unieważnia wszystkie pozostałe reguły.
Utwórz środowisko production z wymaganymi recenzentami. W Settings › Environments dodaj do sześciu użytkowników lub zespołów jako required reviewers (jedna akceptacja przepuszcza job), włącz Prevent self-reviews i ogranicz gałęzie wdrożeniowe do domyślnej. Domyślnie administratorzy mogą omijać reguły ochrony środowiska, więc wyłącz tę opcję. W planach GitHub Free, Pro i Team required reviewers działają tylko w repozytoriach publicznych; prywatne repozytorium wymaga GitHub Enterprise albo równoważnej bramki w platformie wdrożeniowej.
Usuń stałe sekrety produkcji. Usuń tokeny produkcyjne z sekretów repozytorium, z plików .env deweloperów i z runnerów agentów. Job wdrożeniowy wymienia token OIDC GitHuba na krótkotrwałe poświadczenia chmurowe, a polityka zaufania w chmurze akceptuje tylko subject repo:ORG/REPO:environment:production. Job, który nie odwołuje się do środowiska — także każdy job uruchomiony przez agenta z gałęzi — dostaje token z innym subjectem i chmura go odrzuca.
Zbuduj dowody przed akceptacją. Osobny job składa dowody wydania i zapisuje je w podsumowaniu joba, a job produkcyjny ma go w needs. Zatwierdzający czyta dowody na tej samej stronie przebiegu, na której pojawia się przycisk Review deployments.
Zapisz decyzję. Historię akceptacji przebiegu można odpytać (GET /repos/OWNER/REPO/actions/runs/RUN_ID/approvals); zawiera recenzenta, czas i komentarz. Przechowuj ją razem z rekordem wdrożenia, żeby audytor połączył autora, recenzenta, zatwierdzającego, wdrażającego i wynik na jednym SHA.

Workflow wydania realizujący kroki 4 i 5:

name: release
on:
  push:
    branches: [main]
permissions:
  contents: read            # every job starts read-only
jobs:
  evidence:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - run: ./scripts/release-evidence.sh "$GITHUB_SHA" > release-evidence.md
      - run: cat release-evidence.md >> "$GITHUB_STEP_SUMMARY"
      - uses: actions/upload-artifact@v7
        with:
          name: release-evidence
          path: release-evidence.md

  deploy-production:
    needs: evidence
    runs-on: ubuntu-latest
    environment: production  # waits here for a required reviewer
    concurrency:
      group: production
      cancel-in-progress: false
    permissions:
      contents: read
      id-token: write        # OIDC, issued only after approval
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - uses: aws-actions/configure-aws-credentials@v6
        with:
          role-to-assume: ${{ vars.PROD_DEPLOY_ROLE_ARN }}   # trust policy: sub = repo:ORG/REPO:environment:production
          aws-region: eu-central-1
      - run: ./scripts/deploy.sh "$GITHUB_SHA"

Grupa concurrency pilnuje, żeby naraz trwało tylko jedno wdrożenie produkcyjne. Akceptacja wskazuje jeden SHA, więc gdy nowszy push zastąpi oczekujący przebieg, starszy odrzuć zamiast go zatwierdzać.

PROD_DEPLOY_ROLE_ARN to zmienna, nie sekret: nazwa roli bez tokenu OIDC niczego nie daje. Krok AWS zastąp akcją logowania OIDC swojej chmury; liczy się warunek na subject. W tym workflow nie działa żaden agent. Jeśli dodasz krok agenta, na przykład do szkicu release notes, umieść go w jobie evidence bez tokenu z prawem zapisu, tak jak opisuje AI w CI/CD.

Jak trzymać sesję agenta z dala od produkcji?

Bramka jest w CI. Kontrole sesji powstrzymują agenta przed dotarciem do produkcji, zanim w ogóle zadziała CI, i różnią się między narzędziami. We wszystkich trzech pracuj w izolowanym worktree podłączonym do lokalnych albo efemerycznych usług, nigdy w checkoucie, który sięga żywych danych. Uprawnienia, sandboksy i tryby zatwierdzania porównują te kontrole w pełni.

Zablokuj polecenia wdrożeniowe i ukryj poświadczenia w .claude/settings.json albo w managed settings, żeby inżynier nie mógł ich usunąć:

{
  "permissions": {
    "deny": ["Bash(./scripts/deploy.sh *)", "Bash(terraform apply *)", "Read(./.env.production)"]
  }
}

Dodaj hook PreToolUse z etapu Deploy, żeby odrzucone wdrożenie mówiło agentowi, która droga działa. Ustawienie sandboksa sandbox.credentials potrafi zablokować albo zamaskować pliki i zmienne z poświadczeniami; domyślnie nic nie jest chronione. W jobach review w CI claude -p --restricted --strict-mcp-config usuwa narzędzia uruchamiające polecenia, ignoruje ustawienia projektu i nie uruchamia żadnego serwera MCP z pliku .mcp.json repozytorium; samo --restricted nadal te serwery uruchamia (sprawdzone w claude --help, 2.1.283).

Implementację uruchamiaj z profilem uprawnień (-c default_permissions=":workspace", beta) albo ze starszym --sandbox workspace-write i zostaw akceptacje włączone przez -a on-request. Nie łącz profilu z --sandbox: według OpenAI te dwa systemy się nie składają. --full-auto już nie istnieje (brak w codex --help 0.157.1). Administrator może przypiąć permission_profile i zarządzane hooki w requirements.toml. Nigdy nie używaj --dangerously-bypass-approvals-and-sandbox poza jednorazowym sandboksem z ograniczoną siecią i nigdy w powłoce, w której jest poświadczenie produkcyjne.

Co zatwierdzający powinien zobaczyć przed kliknięciem „approve”?

Zatwierdzający decyduje na podstawie dowodów, nie diffu. Podsumowanie joba zawiera sekcję wydania z pakietu dowodów:

Dowód	Po co zatwierdzającemu
SHA commita i podlinkowane `intent.md`, `spec.md` oraz `plan.md`	Dowodzi, że to ta rewizja, która została wyspecyfikowana i zaplanowana
Wyniki testów, lintu, typów, bezpieczeństwa i migracji, podzielone na passed, failed, skipped i manual	Pominięty check to nie to samo co zaliczony
Uwagi z review i sposób rozwiązania każdej	Pokazuje, że uwagi Important zamknięto, a nie zignorowano
Zasięg szkód, zapytania obserwowalności do śledzenia i polecenie rollbacku z datą ostatniej próby	Pozwala ocenić ryzyko, a nie tylko korzyść
Brakujące checki i wyjątki, każdy z właścicielem	Zamienia znaną lukę w decyzję zamiast niespodzianki
Provenance lub podpisy artefaktów, jeśli platforma je obsługuje	Wiąże wdrożony artefakt z recenzowanym commitem

Odrzucenie musi być równie tanie jak akceptacja. Zatwierdzający odrzuca w platformie, a agent odczytuje powód z przebiegu, nigdy kanałem, który dałby mu poświadczenia.

Kolejny prompt uruchom w sesji agenta tylko do odczytu albo w jobie evidence bez tokenu z prawem zapisu, żeby naszkicować raport, który publikuje scripts/release-evidence.sh.

Prepare a production-readiness report for the current HEAD of main. Do not deploy,
approve, or read any production credential.

Link intent.md, spec.md and plan.md for every merged PR since the last production
tag. From the CI run for this commit, list each check as passed, failed, skipped or
manual; a skipped check is never reported as passed. List database migrations and
whether each is reversible, feature flags that change state, the rollback command
and when it was last rehearsed in staging. End with open gaps, each with an owner.
Write it as Markdown for scripts/release-evidence.sh to publish in the job summary.

Act as a skeptical release operator reviewing release-evidence.md for
the current HEAD of main.
List, in priority order: blockers; any mismatch between the approved plan.md and
the files actually changed (git diff --stat against the last production tag);
missing or unrehearsed rollback proof; manual checks with no owner; migrations that
cannot be reversed. Return a recommendation (ship, ship with conditions, hold) and
the reason in three sentences. You do not approve; the named release owner does.

Audit this repository's production gate using read-only gh api calls only.
Report: the default-branch ruleset (pull request required, code-owner review,
stale-approval handling, required checks and their source app, every bypass actor);
the production environment (required reviewers, prevent_self_review, deployment
branch policy); every workflow job that references environment: production and the
permissions it requests; any repository-level secret whose name suggests production.
Flag each gap against this rule: no agent identity can push to main, approve its own
deployment, or read a production credential. Do not change any setting.

Jak udowodnić, że bramka działa, bez czytania każdego workflow?

Strony ustawień opisują zamiar. Zachowanie udowadniają testy uruchamiane jako prawdziwe tożsamości. Wykonaj je po konfiguracji, po każdej zmianie reguł i cyklicznie:

Jako tożsamość agenta git push origin HEAD:main zostaje odrzucony.
Jako tożsamość agenta push zmiany w .github/workflows/ zostaje odrzucony.
Jako tożsamość agenta nie da się zatwierdzić oczekującego wdrożenia w przebiegu, który agent sam uruchomił.
Z sesji agenta env, magazyn sekretów i system plików runnera nie pokazują żadnego poświadczenia produkcyjnego.
Gałąź inna niż main, która odwołuje się do environment: production, zostaje odrzucona przez politykę gałęzi wdrożeniowych.
Historia akceptacji ostatniego wydania wskazuje jednego człowieka i jeden SHA commita.
Rollback przechodzi tą samą chronioną ścieżką i nie daje agentowi implementującemu dostępu do produkcji.

Kontrole ustawień zamień w wykrywanie dryfu: cykliczny job wywołuje gh api repos/OWNER/REPO/environments/production i kończy się błędem, gdy prevent_self_review ma wartość false, lista recenzentów jest pusta albo polityka gałęzi dopuszcza każdą gałąź. Próby rollbacku opisuje strona Przećwiczony rollback.

Co psuje się w bramce produkcji i jak to naprawić?

Hook jest jedyną barierą. Wdrożenie idzie przez sh -c i nic go nie zatrzymuje. Naprawa: najpierw usuń poświadczenie produkcyjne ze wszystkich środowisk agentów, potem egzekwuj bramkę w platformie hostingu kodu i platformie wdrożeniowej. Hook zostaw jako wczesne ostrzeżenie.

Pull request agenta zmienia samą bramkę. Usuwa zależność needs: evidence z release.yml albo osłabia scripts/release-evidence.sh, a zwykłe review code ownera to przepuszcza i nikt nie zauważa, że zmieniła się bramka. Naprawa: przypisz .github/workflows/, scripts/deploy.sh i scripts/release-evidence.sh w CODEOWNERS właścicielowi wydań i dodaj test granicy, który sprawdza, że zmiana workflow wypchnięta jako tożsamość agenta zostaje odrzucona.

Aplikacja agenta jest na liście obejść. Ktoś ją dodał, „żeby odblokować automatyzację”, i każda reguła stała się opcjonalna. Naprawa: opróżnij bypass list rulesetu, powtórz test bezpośredniego pusha jako tożsamość agenta i daj automatyzacji własną ścieżkę przez pull request.

Administratorzy mogą omijać środowisko. Tak jest domyślnie, a agent działający na tokenie administratora to dziedziczy. Naprawa: wyłącz obejście dla administratorów w production i nigdy nie uruchamiaj agentów z poświadczeniami administratora.

Akceptacja zapada na niepełnej stronie dowodów. Recenzent zatwierdza, bo przycisk jest pod ręką. Naprawa: zrób job dowodów zależnością needs, która kończy się błędem, gdy brakuje którejkolwiek wymaganej sekcji — wtedy wdrożenie bez dowodów w ogóle nie zostanie zaproponowane.

Długowieczny token wdrożeniowy przetrwał w sekrecie repozytorium. Workflow z innej gałęzi go odczytuje i omija środowisko. Naprawa: zrotuj token, usuń sekret repozytorium i przejdź na OIDC z warunkiem na subject środowiska.

Dostęp awaryjny (break-glass) staje się stały. Uprawnienie nadane podczas incydentu działa jeszcze miesiące później. Naprawa: nadawaj dostęp awaryjny z datą wygaśnięcia, loguj każde użycie i omawiaj je w postmortemie, jak opisuje Gdy incydent wywoła agent.

Dokąd dalej po bramce produkcji

Q21 · Przećwiczony rollback Ćwicz odtwarzanie tą samą chronioną ścieżką.

Pakiet dowodów Kontrakt pull requesta, na którym opierają się dowody wydania.

Progressive delivery Ogranicz szkody zatwierdzonego wydania flagami i canary.

Governance i autonomia Klasy ryzyka i kto co zatwierdza — dla CTO.

Oficjalne źródła: środowiska wdrożeniowe GitHuba, OpenID Connect w GitHubie, reguły dostępne w rulesetach oraz hooki Claude Code.

Najczęstsze pytania

Jakie kontrole uniemożliwiają agentowi bezpośrednie wdrożenie niesprawdzonych zmian na produkcję?

Bramka akceptacji produkcji tworzy twardą granicę systemową: osobne tożsamości agenta i wdrożenia, brak stałych poświadczeń produkcyjnych w środowisku agenta, chronione gałęzie bez obejść oraz job wdrożeniowy zatwierdzany przez wskazanego człowieka.

Czy prompty i lokalne hooki wystarczą jako bramka przed wdrożeniem na produkcję?

Nie, prompty i lokalne hooki pozwalają jedynie wcześnie wyłapać pomyłki w sesji agenta, natomiast właściwa ochrona produkcji wymaga separacji tożsamości i zatwierdzania wdrożeń poza zasięgiem agenta.