Inżynieria agentowa w branżach regulowanych

Inżynieria agentowa w branżach regulowanych zachowuje kontrole, które audytorzy już testują (autoryzowane zmiany, niezależne zatwierdzenie, dowody testów, kompletna ścieżka audytu), i zmienia tylko to, kto wytwarza dowody. Agenci piszą zmiany i robią wstępne review; ostatni commit zatwierdza człowiek, który nie jest ani właścicielem, ani autorem zmiany; CI zapisuje wszystko w pakiecie dowodów archiwizowanym przy merge’u.

Audyt wewnętrzny twojego banku zaplanował coroczny przegląd ogólnych kontroli IT (ITGC). W zeszłym roku audytorzy wylosowali 25 zmian i przy każdej znaleźli zgłoszenie, przebieg testów i zatwierdzenie drugiej osoby. W tym roku połowę pull requestów otworzył Claude Code albo Codex, przy części zatwierdzające review pochodzi od bota, a w kilku przypadkach Approve kliknął ten sam inżynier, który wydał agentowi polecenie. Pierwsze pytanie audytora będzie brzmiało: „Kto jest tu drugą osobą?”.

Ta strona jest dla CTO, który musi na to pytanie odpowiedzieć, i dla tech leada, który musi sprawić, żeby odpowiedź była prawdziwa w repozytorium. To inżynierska lektura frameworków kontrolnych, a nie porada prawna ani audytorska: uzgodnij projekt kontroli ze swoim audytorem, zanim się na nim oprzesz.

Źródła i sposób ich weryfikacji

Treść kontroli NIST SP 800-53 Rev. 5 odczytano 2026-09-26 z katalogu OSCAL NIST (wydanie 5.2.0). Zachowanie GitHuba sprawdzono tego samego dnia w źródłach dokumentacji GitHuba i w opisie REST API. EUR-Lex, PCI Security Standards Council, eCFR i HHS nie były dostępne, więc brzmienie przepisów DORA-EU, PCI DSS, 21 CFR Part 11 i HIPAA pochodzi z wyciągów wyszukiwarki. Przeczytaj tekst źródłowy, zanim zacytujesz przepis audytorowi.

Dlaczego agent zatwierdzający agenta nie spełnia rozdziału obowiązków

Rozdział obowiązków istnieje po to, żeby jedna strona nie mogła sama wprowadzić szkodliwej zmiany. Frameworki, według których jesteś audytowany, formułują go w kategoriach osób ponoszących odpowiedzialność:

• NIST SP 800-53 Rev. 5, AC-5, wymaga wskazania obowiązków do rozdzielenia i zdefiniowania uprawnień dostępu, które ten rozdział wspierają („define system access authorizations to support separation of duties”). CM-5(4) Dual Authorization wyjaśnia, że zmiany w wybranych komponentach „cannot occur unless two qualified individuals approve and implement such changes”, i dodaje, że „the individuals are also accountable for the changes”.
• PCI DSS v4.0.1, wymaganie 6.2.3.1 (wyciąg z wyszukiwarki), oczekuje, że ręczny przegląd kodu wykonają „individuals other than the originating code author” znający techniki review, a zmiany przed wydaniem zatwierdzi kierownictwo.
• Dla podmiotów finansowych w UE RTS do DORA-EU o ramach zarządzania ryzykiem ICT, rozporządzenie delegowane Komisji (UE) 2024/1774, art. 17 (wyciąg z wyszukiwarki), wymaga procedur zarządzania zmianą, które zapewniają niezależność funkcji zatwierdzających zmiany od funkcji, które je zlecają i wdrażają.

Agent nie jest osobą ponoszącą odpowiedzialność: agent recenzujący uruchomiony przez tego samego inżyniera to druga opinia, a nie druga osoba. GitHub doszedł do tego samego wniosku w sprawie własnego agenta: rulesety mają teraz domyślnie włączoną opcję „Require an additional approval for unattributed Copilot pull requests” (public preview na 2026-09-26), bo „requiring one approval usually means two people are involved in a change”, a to założenie przestaje działać, gdy agent otwiera pull request pod własną tożsamością aplikacji (GitHub Docs, sprawdzone 2026-09-26).

Wniosek to precyzyjna reguła, a nie zakaz: agenci mogą pisać i recenzować; zatwierdzać może tylko osoba, która nie jest ani właścicielem zmiany, ani jej autorem.

Kto co może zrobić w zmianie napisanej przez agenta?

Przypisz każdy krok do roli i ustal, czy może ją pełnić agent. Ta tabela jest rdzeniem twojego opisu kontroli.

Krok	Rola	Czy może to zrobić agent?	Dowód, który zostaje w potoku
Zlecenie zmiany	Zlecający (product owner, autor zgłoszenia)	Nie: autoryzacja pochodzi od osoby albo z zatwierdzonego backlogu	Zgłoszenie lub specyfikacja w spec.link
Odpowiedzialność za zmianę	Właściciel zmiany: inżynier, który uruchamia agenta i odpowiada za wynik	Nie	provenance.human_owner w pakiecie dowodów
Napisanie kodu i testów	Autor	Tak	Tożsamość agenta, wersja narzędzia, model i sesja w provenance
Wstępne review	Agent recenzujący (/code-review w Claude Code, codex exec review, Bugbot w Cursorze)	Tak, jako kontrola, która wytwarza ustalenia	Wynik review zarchiwizowany razem z pakietem
Zatwierdzenie zmiany	Niezależny zatwierdzający	Nie: osoba, która nie jest ani właścicielem zmiany, ani autorem pull requesta	Zatwierdzające review ostatniego commita, zapisane przez GitHuba
Zatwierdzenie wrażliwych ścieżek	Code owner dla uwierzytelniania, płatności, schematu, migracji	Nie	Review z CODEOWNERS, wymagane przez ruleset
Wdrożenie na produkcję	Potok, z bramką osoby zatwierdzającej wydanie	Potok wdraża; bramką jest osoba inna niż ta, która wdrożenie uruchomiła	Zapis wdrożenia z zatwierdzeniem środowiska
Zmiana samej bramki	Właściciel platformy	Nie	CODEOWNERS dla workflowów, polityki i plików checkera

Dwa przypadki brzegowe wymagają spisanej reguły przed audytem, a nie w jego trakcie:

1. Brak ludzkiego właściciela. Zaplanowane uruchomienie, pętla wyzwalana przez zgłoszenie albo agent uruchomiony ze wspólnego kanału czatu nie mają właściciela. Potraktuj je tak, jak GitHub traktuje nieprzypisane pull requesty Copilota: wymagaj dwóch niezależnych zatwierdzeń przez ludzi.
2. Właściciel edytuje gałąź agenta. Gdy właściciel wypycha własne commity, staje się także autorem. Ruleset poniżej wymaga zatwierdzenia przez kogoś innego niż osoba, która wypchnęła ostatnie zmiany, więc push właściciela ponownie otwiera zatwierdzanie.

Czego audytorzy w finansach, ochronie zdrowia i sektorze publicznym oczekują od potoku?

Audytorzy rzadko pytają o samego agenta. Dla próbki zmian produkcyjnych proszą o autoryzację, testy, niezależne zatwierdzenie, zapis wdrożenia i dowód, że żadna zmiana nie ominęła procesu. Sektory różnią się słownictwem i okresem przechowywania. Raz przypisz każde oczekiwanie do artefaktu potoku, a audyt sprowadzi się do zapytania.

Sektor i framework	Co testuje audytor	Gdzie odpowiada na to twój potok agentów
Finanse, spółki notowane w USA: ogólne kontrole IT SOX dla zmian w programach	Każda wylosowana zmiana autoryzowana, przetestowana i zatwierdzona przez kogoś innego niż jej autor, który nie może sam przenieść jej na produkcję	spec.link; acceptance i checks w pakiecie; check sod; środowisko produkcyjne z zablokowanym samozatwierdzaniem
Finanse, UE: DORA-EU art. 9 ust. 4 lit. e i RTS 2024/1774 art. 17 (zob. CRA, NIS2 i DORA-EU)	Udokumentowane, oparte na ryzyku zarządzanie zmianą; niezależność funkcji zatwierdzających i wdrażających	Klasa ryzyka w pakiecie; routing CODEOWNERS dla ścieżek wysokiego ryzyka; ruleset bez wyjątków (bypass)
Płatności kartowe: PCI DSS v4.0.1, wym. 6.2.3, 6.2.3.1, 6.5.1, 6.5.4	Kod tworzony na zamówienie przejrzany przed wydaniem przez kogoś innego niż autor; zmiany udokumentowane z zatwierdzeniem, testami i planem wycofania; rozdzielone role produkcyjne	Ustalenia agenta recenzującego plus niezależne zatwierdzenie człowieka; risk.rollback; zatwierdzenie wdrożenia przez osobę, która go nie uruchomiła
Ochrona zdrowia, USA: kontrole audytowe HIPAA Security Rule (45 CFR 164.312(b)); FDA 21 CFR Part 11 §11.10(e) dla systemów GxP	Aktywność w systemach z chronionymi lub regulowanymi danymi jest rejestrowana; ścieżki audytu są generowane komputerowo, opatrzone znacznikiem czasu i nie zacierają wcześniejszych wpisów	Telemetria agentów w twoim SIEM; podpisane archiwum dowodów; dane PHI trzymane poza kontekstem agenta (zob. prywatność danych)
Sektor publiczny, administracja federalna USA: NIST SP 800-53 Rev. 5 (podstawa baseline’ów FedRAMP) CM-3, CM-4, CM-5(4), AC-5, AU-10, SA-10	Zmiany przeglądane z analizą wpływu na bezpieczeństwo, przechowywane zapisy zmian, podwójna autoryzacja tam, gdzie ją wybrano, niezaprzeczalność zatwierdzeń	Sekcja ryzyka w pakiecie; zarchiwizowane zatwierdzenia powiązane z imiennymi kontami; podpisana atestacja archiwum

Kontrola zmian oprogramowania wyrobów medycznych według IEC 62304 i środki bezpieczeństwa NIS2 w unijnym sektorze publicznym korzystają z tych samych artefaktów: spec.link, spec.delta i acceptance dają śledzalność, oracle_changes pokazuje, czy weryfikacji nie osłabiono, a obowiązki opisuje strona CRA, NIS2 i DORA-EU. Jeśli certyfikujesz też system zarządzania AI albo przygotowujesz raporty SOC 2, te same artefakty obsłużą i te audyty; mapowanie kontrola po kontroli znajdziesz na stronie ISO/IEC 42001, NIST AI RMF i dowody SOC 2.

Etykieta pochodzenia służy populacji audytowej, nie routingowi

Oznaczaj zmiany napisane przez agentów, żeby audytor mógł wylistować wszystkie takie zmiany w systemach objętych zakresem w danym kwartale. Nie kieruj review na podstawie etykiety: ludzkie zmiany w kodzie rozliczeń są tak samo ryzykowne. Ryzyko wynika ze ścieżek i zmian wyroczni, które wylicza pakiet dowodów; zob. pochodzenie zmian i routing według ryzyka.

Jak wymusić rozdział obowiązków w repozytorium?

Dodaj cztery kontrole w tej kolejności, bo checki muszą istnieć, zanim ruleset zacznie ich wymagać. Kroki zakładają GitHuba i pakiet dowodów, którego job w CI nazywa się evidence.

1. Daj każdemu agentowi własną tożsamość. Agent na osobistym tokenie programisty sprawia, że autor i właściciel to to samo konto. Uruchamiaj agentów w CI jako GitHub App albo dedykowane konto maszynowe z krótkotrwałymi tokenami, tak jak opisuje strona tożsamość agentów, poświadczenia i sekrety. Zostaw wyłączone ustawienie Allow GitHub Actions to create and approve pull requests (Settings, Actions, General, Workflow permissions), chyba że jakiś workflow musi otwierać pull requesty, i nigdy nie pozwalaj tokenowi workflowu ich zatwierdzać.

2. Dodaj check rozdziału obowiązków. Przechodzi tylko wtedy, gdy bieżący commit HEAD zatwierdziła osoba z twojej listy zatwierdzających, która nie jest właścicielem zmiany, autorem pull requesta, osobą kiedykolwiek do niego przypisaną ani autorem czy committerem żadnego commita na gałęzi. Gdy zmiana nie ma ludzkiego właściciela, potrzebne są dwie takie osoby. Uruchamia się ponownie przy każdym dodaniu lub odrzuceniu review.

   .github/workflows/sod.yml

   name: separation-of-duties
   on:
     pull_request:
       types: [opened, edited, synchronize, reopened, ready_for_review]
     pull_request_review:
       types: [submitted, dismissed]
   permissions:
     contents: read
     issues: read
     pull-requests: read
   jobs:
     sod:
       runs-on: ubuntu-latest
       steps:
         - name: Require an independent human approval of the head commit
           env:
             GH_TOKEN: ${{ github.token }}
             REPO: ${{ github.repository }}
             PR: ${{ github.event.pull_request.number }}
           run: |
             set -euo pipefail
             gh api "repos/$REPO/pulls/$PR" > pr.json
             HEAD_SHA=$(jq -r .head.sha pr.json)
             BASE_SHA=$(jq -r .base.sha pr.json)
             AUTHOR=$(jq -r .user.login pr.json)
             # GitHub reports a machine account as type "User", so the type proves nothing.
             # Approvers come from a CODEOWNERS-protected list read from the base branch.
             # On a 404, gh api still prints GitHub's JSON error body, so test its exit status.
             if ! gh api -H "Accept: application/vnd.github.raw+json" \
                 "repos/$REPO/contents/.github/human-approvers?ref=$BASE_SHA" > approvers.raw; then
               echo "::error::.github/human-approvers is missing on the base branch"; exit 1
             fi
             sed -e 's/#.*//' -e 's/^@//' -e 's/[[:space:]]//g' approvers.raw | grep -v '^$' > humans.txt || true
             if [ ! -s humans.txt ]; then
               echo "::error::.github/human-approvers is empty on the base branch"; exit 1
             fi
             owner=$(jq -r '.body // ""' pr.json \
               | sed -nE 's/^[[:space:]]*human_owner:[[:space:]]*"?@?([A-Za-z0-9-]+)"?.*/\1/p' | head -n1)
             if [ -z "$owner" ]; then
               echo "::error::provenance.human_owner is missing (use none for a run without an owner)"; exit 1
             fi
             required=1
             if [ "$owner" = none ]; then required=2
             elif ! jq -e --arg o "$owner" \
                 'any(.assignees[]; (.login | ascii_downcase) == ($o | ascii_downcase))' pr.json >/dev/null; then
               echo "::error::human_owner ($owner) must be an assignee of the pull request"; exit 1
             fi
             # human_owner sits in the PR description, which the author can edit, so
             # every commit author, committer and anyone ever assigned is excluded too.
             gh api "repos/$REPO/pulls/$PR/commits" --paginate \
               --jq '.[] | .author.login?, .committer.login? | select(. != null)' > committers.txt
             gh api "repos/$REPO/issues/$PR/events" --paginate \
               --jq '.[] | select(.event == "assigned") | .assignee.login' >> committers.txt
             printf '%s\n%s\n' "$owner" "$AUTHOR" >> committers.txt
             gh api "repos/$REPO/pulls/$PR/reviews" --paginate > reviews.json
             approvers=$(jq -r --arg sha "$HEAD_SHA" '.[]
               | select(.state == "APPROVED" and .commit_id == $sha and .user.type == "User")
               | .user.login' reviews.json | sort -u)
             independent=$(printf '%s\n' "$approvers" | grep -x -i -F -f humans.txt \
               | grep -v -x -i -F -f committers.txt | grep -v '^$' || true)
             count=$(printf '%s\n' "$independent" | grep -c . || true)
             if [ "$count" -lt "$required" ]; then
               echo "::error::$HEAD_SHA needs $required approval(s) from listed humans other than the owner ($owner), the author (@$AUTHOR) or a committer; found $count"; exit 1
             fi
             echo "Independent approval of $HEAD_SHA by: $(echo $independent)"

   Check pomija zatwierdzenia starszych commitów oraz zatwierdzenia z każdego konta, którego nie ma w pliku .github/human-approvers (jeden login w wierszu). Plik jest czytany z gałęzi bazowej, więc pull request nie dopisze sobie zatwierdzającego. Sam typ konta nie wystarcza: GitHub zgłasza konto maszynowe, czyli zwykłe konto, na które loguje się agent, jako typ User, a jako Bot pokazuje tylko aplikacje GitHub. Wpisuj ludzi, nigdy kont serwisowych. Brak pliku albo pusty plik oznacza błąd checka. Pole human_owner kontroluje autor: autor albo właściciel może je przepisać, a wyzwalacz edited ponownie uruchamia check. Dlatego właściciel musi być też przypisany (assignee) do pull requesta, a check wyklucza każdego, kto kiedykolwiek był przypisany, oraz wszystkich autorów i committerów commitów. Przypisz właściciela zmiany, gdy agent otwiera pull request. Właściciel nadal deklaruje się sam: jeśli nie jest przypisany, może wpisać kolegę, który jest przypisany, a potem zatwierdzić zmianę. Dlatego bierz właściciela ze źródła, którego autor nie może edytować, na przykład z dziennika sesji agenta albo z aktora uruchamiającego zapisanego przez aplikację agenta, i niech zadanie archiwizujące oraz twój test kontroli porównują z nim human_owner. Dla uruchomienia bez ludzkiego właściciela, na przykład zaplanowanego albo wyzwalanego przez zgłoszenie, wpisz human_owner: none: check wymaga wtedy dwóch różnych niezależnych osób, które zatwierdziły commit HEAD. Ruleset tego za ciebie nie zrobi, bo jego liczba zatwierdzeń dotyczy każdego pull requesta na gałęzi.

   Autor może edytować check, który go ocenia

   Workflow na zdarzeniu pull_request uruchamia kopię sod.yml z gałęzi pull requesta, więc agent mógłby zmienić ją na exit 0. Obejmij .github/workflows/, .github/human-approvers i .github/CODEOWNERS wpisem w CODEOWNERS dla właściciela platformy; ruleset poniżej czyni to review przez człowieka obowiązkowym. Na poziomie organizacji reguła rulesetu Require workflows to pass before merging uruchamia workflow ze wskazanego repozytorium źródłowego, poza zasięgiem autora. Przypinaj każdą akcję w tych workflowach kontrolnych, także akcje GitHuba, do pełnego SHA commita z tagiem w komentarzu, żeby kontrola nie zmieniła się bez twojej wiedzy. Przykłady poniżej pokazują tagi dla czytelności; przed commitem zamień każdy na jego SHA.

3. Utwórz ruleset gałęzi. Wymaga jednego zatwierdzenia, review code ownera i zatwierdzenia ostatniego pusha przez kogoś innego niż jego autor; odrzuca nieaktualne zatwierdzenia i wymaga trzech checków: evidence, sod i agent-review, czyli joba recenzującego opisanego niżej w zakładkach narzędzi. Dzięki wymaganemu agent-review pull requesta nie da się scalić, zanim review jego commita HEAD zakończy się sukcesem, więc zadanie archiwizujące znajdzie wynik recenzji. Pusta lista wyjątków (bypass) pozwala powiedzieć audytorowi, że populacja jest kompletna. Każdy check jest przypięty do integration_id 15368, czyli aplikacji GitHub Actions: nieprzypięty wymagany check przyjmuje status o tej nazwie od każdego konta, które może zapisywać statusy commitów, także od GitHub App albo tokena samego agenta, który mógłby sam oznaczyć sod jako zaliczony.

   {
     "name": "regulated-default-branch",
     "target": "branch",
     "enforcement": "active",
     "bypass_actors": [],
     "conditions": { "ref_name": { "include": ["~DEFAULT_BRANCH"], "exclude": [] } },
     "rules": [
       { "type": "deletion" },
       { "type": "non_fast_forward" },
       { "type": "pull_request", "parameters": {
           "required_approving_review_count": 1,
           "dismiss_stale_reviews_on_push": true,
           "require_code_owner_review": true,
           "require_last_push_approval": true,
           "required_review_thread_resolution": true } },
       { "type": "required_status_checks", "parameters": {
           "strict_required_status_checks_policy": true,
           "required_status_checks": [
             { "context": "evidence", "integration_id": 15368 },
             { "context": "sod", "integration_id": 15368 },
             { "context": "agent-review", "integration_id": 15368 } ] } }
     ]
   }

   # Terminal, jako administrator repozytorium
   gh api -X POST repos/acme/payments-api/rulesets --input ruleset.json

4. Uzależnij wdrożenie produkcyjne od drugiej osoby. Utwórz środowisko production z osobami zatwierdzającymi wydania jako wymaganymi recenzentami i zablokowanym samozatwierdzaniem. Na planach GitHub Free, Pro i Team wymagani recenzenci działają tylko w repozytoriach publicznych, więc prywatny kod regulowany potrzebuje do tego kroku GitHub Enterprise.

   # Terminal, jako administrator repozytorium. 4532992 to numeryczny id zespołu
   # release-approvers: gh api orgs/acme/teams/release-approvers --jq .id
   gh api -X PUT repos/acme/payments-api/environments/production --input - <<'JSON'
   { "prevent_self_review": true,
     "reviewers": [ { "type": "Team", "id": 4532992 } ] }
   JSON

Skąd wiesz, że check rozdziału obowiązków działa?

Testuj go jak każdą wyrocznię: przypadkami, które muszą się nie udać. Na tymczasowym pull requeście z tożsamości agenta każdy przypadek oprócz ostatniego musi zostawić sod na czerwono albo zablokowany merge.

Przypadek	Oczekiwany wynik
Pakiet bez human_owner	Błąd: brak właściciela
Zatwierdza tylko właściciel zmiany	Błąd: brak niezależnego zatwierdzenia
Zatwierdza bot recenzujący	Błąd: zatwierdzenia z kont Bot są pomijane
Zatwierdza konto maszynowe (typ User), na które loguje się agent	Błąd: nie ma go w .github/human-approvers
human_owner zmieniony na inne nazwisko, potem zatwierdza prawdziwy właściciel	Błąd, gdy agent przypisał właściciela przy tworzeniu pull requesta: właściciel jest przypisany, więc check go wyklucza
Konto agenta publikuje status success o nazwie sod	Nadal zablokowane: ruleset przyjmuje sod tylko od GitHub Actions
human_owner: none i commit HEAD zatwierdza jedna niezależna osoba	Błąd, dopóki nie zatwierdzi go druga niezależna osoba
Niezależna osoba zatwierdza, a potem agent wypycha kolejny commit	Błąd, dopóki ta sama lub inna osoba nie zatwierdzi nowego commita HEAD
Próba merge’a, zanim uruchomienie agent-review na commicie HEAD zakończy się sukcesem	Zablokowane: agent-review jest wymaganym checkiem
Niezależna osoba zatwierdza commit HEAD	Sukces

Zapisz linki do tych uruchomień w pliku testowania kontroli: audytor ufa kontroli, którą potrafisz na żądanie pokazać w stanie błędu.

Jak zachować zapis po merge’u?

Pull request da się edytować: każdy z uprawnieniami zapisu może po merge’u zmienić opis, a więc i pakiet. Artefakty Actions wygasają. Zrób migawkę zapisu w chwili merge’a, podpisz ją za pomocą actions/attest i skopiuj do magazynu, którym zarządza twoja polityka retencji.

.github/workflows/archive-evidence.yml

name: archive-evidence
on:
  pull_request:
    types: [closed]
jobs:
  archive:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
      issues: read
      checks: read
      actions: read
      id-token: write
      attestations: write
      artifact-metadata: write
    steps:
      - name: Snapshot the bundle, reviews, comments, check runs and reviewer output
        id: snapshot
        env:
          GH_TOKEN: ${{ github.token }}
          REPO: ${{ github.repository }}
          PR: ${{ github.event.pull_request.number }}
          SHA: ${{ github.event.pull_request.head.sha }}
          # The workflow that runs the reviewer agent and uploads evidence/
          # as the artifact "agent-review"
          REVIEW_WORKFLOW: agent-review.yml
        run: |
          set -euo pipefail
          D="evidence-$PR"; mkdir -p "$D"
          gh api "repos/$REPO/pulls/$PR" > "$D/pull-request.json"
          gh api "repos/$REPO/pulls/$PR/reviews" --paginate --slurp > "$D/reviews.json"
          gh api "repos/$REPO/pulls/$PR/comments" --paginate --slurp > "$D/review-comments.json"
          gh api "repos/$REPO/issues/$PR/comments" --paginate --slurp > "$D/issue-comments.json"
          gh api "repos/$REPO/commits/$SHA/check-runs" --paginate --slurp > "$D/check-runs.json"
          # A missing reviewer output must not cost the rest of the record: archive
          # the snapshot, record the gap as an exception, fail the job after upload.
          run_id=$(gh run list -R "$REPO" --workflow "$REVIEW_WORKFLOW" --commit "$SHA" \
            --status success --limit 1 --json databaseId --jq '.[0].databaseId // empty' || true)
          if [ -n "$run_id" ] && gh run download "$run_id" -R "$REPO" -n agent-review -D "$D/agent-review"; then
            echo "reviewer_output=present" >> "$GITHUB_OUTPUT"
          else
            echo "EXCEPTION: no agent-review output from a successful $REVIEW_WORKFLOW run on $SHA at merge" \
              > "$D/EXCEPTION-agent-review-missing.txt"
            echo "reviewer_output=missing" >> "$GITHUB_OUTPUT"
          fi
          tar czf "$D.tgz" "$D"
      - uses: actions/attest@v4
        with:
          subject-path: evidence-${{ github.event.pull_request.number }}.tgz
      - uses: actions/upload-artifact@v7
        with:
          name: evidence-${{ github.event.pull_request.number }}
          path: evidence-${{ github.event.pull_request.number }}.tgz
      - name: Fail when the reviewer output is missing
        if: steps.snapshot.outputs.reviewer_output == 'missing'
        env:
          SHA: ${{ github.event.pull_request.head.sha }}
        run: |
          echo "::error::no agent-review output for $SHA; the archive records it as a control exception"
          exit 1

Migawka obejmuje pull request, jego review, komentarze w kodzie, komentarze w rozmowie, uruchomienia checków i wynik agenta recenzującego z artefaktu agent-review. Jeśli tego wyniku brakuje, job i tak archiwizuje i atestuje całą resztę, dodaje do archiwum plik EXCEPTION-agent-review-missing.txt, a dopiero potem kończy się błędem. Luka jest więc widoczna jako czerwone uruchomienie i zapisany wyjątek, a zapis nie przepada. Atestacja wiąże skrót archiwum z uruchomieniem workflowu, które je wytworzyło, a gh attestation verify to sprawdza. Dodaj ostatni krok, który kopiuje archiwum do magazynu jednokrotnego zapisu, na przykład bucketu z blokadą obiektów, z okresem retencji wymaganym przez regulatora. Atestacje artefaktów w repozytoriach prywatnych wymagają GitHub Enterprise Cloud.

Jak w tę kontrolę wpisują się Claude Code, Codex i Cursor?

Ruleset, checki i archiwum są takie same dla każdego narzędzia. Różnią się przypinanie wersji, wynik recenzji i dziennik aktywności.

Claude Code

Kontrola wersji narzędzia. Claude Code ma dwa kanały wydań: latest (2.1.283 na 2026-09-26) i stable (2.1.274), który jest „typically about a week behind” i pomija wydania z poważnymi regresjami. Ustaw autoUpdatesChannel: "stable" w ustawieniach zarządzanych i zapisuj wersję w provenance.agent. Kanał dotyczy tylko stacji roboczych: w CI instaluj przypiętą wersję (npm install -g @anthropic-ai/claude-code@2.1.283 albo stable 2.1.274) i zapisuj claude --version w provenance.agent. Najnowsze zmiany docierają do stable później; domyślny model dla każdego kanału podaje centrum modeli.

Wynik recenzji jako dowód. Uruchom review w trybie headless i zachowaj wynik JSON obok pakietu:

# Job CI na pull requeście (Claude Code 2.1.283). Pobierz repozytorium
# z fetch-depth: 0 albo uruchom git fetch origin main, żeby istniał origin/main.
mkdir -p evidence
claude -p "Review the diff against origin/main for security and correctness. List findings with file:line." \
  --bare --setting-sources "" --strict-mcp-config \
  --output-format json --permission-mode dontAsk \
  --allowedTools "Read,Grep,Glob,Bash(git diff:*)" \
  > evidence/claude-review.json

Prompt stoi zaraz po -p, bo --allowedTools przyjmuje listę o zmiennej długości i połknąłby prompt umieszczony za nią. --bare pomija hooki i wyszukiwanie plików CLAUDE.md, --setting-sources "" nie ładuje żadnego pliku ustawień, więc ustawienia projektu i lokalne z gałęzi kontrolowanej przez autora zostają pominięte, a --strict-mcp-config ignoruje jej serwery MCP. Z --bare skille nadal da się wywołać przez /nazwa-skilla, więc prompt żadnego nie wywołuje. Z --bare job uwierzytelnia się wyłącznie przez ANTHROPIC_API_KEY (albo poświadczenia dostawcy chmury); token OAuth nie jest odczytywany. Uruchamiaj go na pull_request z contents: read i checkoutem z persist-credentials: false, nigdy na pull_request_target. Nazwij workflow agent-review.yml, a jego job agent-review, bo tego checka wymaga ruleset, i zakończ job krokiem actions/upload-artifact, który wysyła katalog evidence/ jako agent-review; zadanie archiwizujące pobierze go przy merge’u.

Dziennik aktywności. Ustaw CLAUDE_CODE_ENABLE_TELEMETRY=1 i standardowe zmienne eksportera OTEL_* w ustawieniach zarządzanych, żeby programiści nie mogli ich wyłączyć. Compliance API jest funkcją planu Enterprise.

Codex

Kontrola wersji narzędzia. Przypnij CLI w CI (npm install -g @openai/codex@0.157.1) i wymuś na stacjach roboczych ustawienia istotne dla kontroli przez requirements.toml (profil uprawnień, dozwolone serwery MCP, wyłącznie zarządzane hooki). Ten plik nie przypina wersji, więc zapisuj codex --version w provenance.agent.

Wynik recenzji jako dowód. codex exec review zapisuje końcową wiadomość do pliku; --json zachowuje strumień zdarzeń:

# Job CI na pull requeście (Codex CLI 0.157.1). Pobierz repozytorium
# z fetch-depth: 0, żeby istniał origin/main; uwierzytelnienie przez CODEX_API_KEY.
mkdir -p evidence
codex exec review --base origin/main --json \
  -o evidence/codex-review.md > evidence/codex-review.jsonl

W wersji 0.157.1 flagi --base nie da się połączyć z własnym promptem recenzji; stałe instrukcje dla review umieść w AGENTS.md. Uruchamiaj go jako job agent-review w agent-review.yml (tego checka wymaga ruleset) na pull_request z contents: read i persist-credentials: false, a katalog evidence/ wyślij krokiem actions/upload-artifact jako agent-review; zadanie archiwizujące pobierze go przy merge’u.

Dziennik aktywności. Codex czyta tabelę [otel] w config.toml (obecną w 0.157.1). Rozprowadź tę samą tabelę do config.toml na każdej stacji roboczej, na przykład narzędziami do zarządzania urządzeniami, żeby wszystkie eksportowały do jednego kolektora.

Cursor

Kontrola wersji narzędzia. Numeracji wydań i kontroli administracyjnych Cursora nie udało się ponownie zweryfikować 2026-09-26 (cursor.com był niedostępny). Zapisuj w provenance.agent „linia Cursor 3.x, sprawdzone DATA” i potwierdź sposób przypinania wersji z administratorem Cursora, zanim opiszesz go audytorowi.

Wynik recenzji jako dowód. Bugbot „reviews pull requests and identifies bugs, security issues, and code quality problems” (sprawdzone na cursor.com 2026-08-28). Jego komentarze są w pull requeście, więc zadanie archiwizujące zapisuje je w review-comments.json i issue-comments.json. Jeśli Bugbot jest jedynym recenzentem, job i artefakt agent-review nie istnieją: usuń agent-review z wymaganych checków rulesetu, a z zadania archiwizującego wiersze pobierające wynik recenzji. Inaczej każdy merge zostanie zablokowany albo zarchiwizowany jako wyjątek.

Agenci zatwierdzający. PR Routing & Approval przydziela recenzentów i według dokumentacji „can approve low-risk PRs when your criteria are met” (sprawdzone na cursor.com 2026-08-28). W repozytorium regulowanym ogranicz go do przydzielania recenzentów: check sod ignoruje zatwierdzenia agentów, a poleganie na nich przeczyłoby twojemu opisowi kontroli. Zobacz Rollouts i PR Routing & Approval w Cursorze.

We wszystkich trzech narzędziach nie wpuszczaj danych regulowanych do kontekstu agenta: jeśli prompt zawierał dane pacjenta albo posiadacza karty, zawierają je też dzienniki sesji i archiwum. Kieruj ruch do modeli tak, jak opisuje strona gdzie działa model, i stosuj klasy danych ze strony prywatność danych i polityki firmowe.

Prompty do skopiowania na przygotowanie do audytu

Te prompty czytają dowody; żaden niczego nie zatwierdza. Uruchamiaj je z uprawnieniami tylko do odczytu.

Prompt do skopiowania: odpowiedź na próbkę zmian audytora

An auditor has sampled these merged pull requests in acme/payments-api:
#1841, #1867, #1902, #1935, #1960. For each one, use the gh CLI (read-only)
to collect: the linked ticket or spec from the evidence bundle's spec.link,
the provenance block (agent, model, human_owner), the risk class, every
approving review with reviewer login, account type and the commit it
approved, the status of the "evidence", "sod" and "agent-review" checks on
the head commit,
and the production deployment that shipped it with its approver.

Produce one table row per pull request with those columns, then a list of
exceptions: any approval by the human_owner or the author, any approval that
is not on the head commit, any approval by a Bot or by an account missing from .github/human-approvers
counted as the only approval,
any missing check, any deployment approved by the person who triggered it.
Do not infer missing data. Write "not found" and say which API call you ran.

Prompt do skopiowania: luki kontrolne w ustawieniach repozytorium

Read-only audit of the repositories acme/payments-api and acme/ledger.
Using gh api, fetch the rulesets that apply to the default branch, the
CODEOWNERS file, the Actions workflow permissions (including whether
GitHub Actions may create and approve pull requests), and the protection
rules of the "production" environment.

Compare them with this control set: pull request required; at least one
approval; code-owner review; approval of the most recent push by someone
other than the pusher; stale approvals dismissed; required checks
"evidence", "sod" and "agent-review"; empty bypass list; workflows cannot approve pull
requests; production environment with required reviewers and self-review
prevented; CODEOWNERS entries for .github/workflows/, .github/human-approvers and
the evidence policy. Output a table: control, expected, actual, gap (yes/no), and the
exact gh api call that shows it. Change nothing.

Prompt do skopiowania: szkic opisu kontroli zarządzania zmianą

Draft the change-management control narrative for our IT general controls
file, for a reader who is an external auditor. Base it only on these files:
.github/workflows/evidence-bundle.yml, .github/workflows/sod.yml,
.github/workflows/archive-evidence.yml, .github/evidence-policy.yml,
.github/CODEOWNERS and the ruleset JSON in docs/controls/ruleset.json.

Structure: control objective; roles (requester, change owner, author agent,
reviewer agent, independent approver, code owner, release approver,
platform owner) and which of them may be an AI agent; the control activities
in order; the evidence each activity leaves and where it is retained; how
emergency changes are handled; how the control is tested. Quote file paths
and job names exactly. Mark every statement you could not trace to a file
as ASSUMPTION so a human can confirm it.

Jak udowodnić, że kontrola nadal działa?

Audytorzy testują skuteczność działania w całym okresie, więc co kwartał wpisuj te trzy liczby do pliku testowania kontroli:

Metryka	Definicja	Cel
Kompletność pakietów	Scalone pull requesty do repozytoriów w zakresie z zarchiwizowanym pakietem i przechodzącym checkiem evidence na commicie HEAD, podzielone przez wszystkie scalone pull requesty do tych repozytoriów, liczone z historii gałęzi domyślnej albo listy scalonych pull requestów (gh api), a nie z archiwów	100%; każdy wyjątek ma zgłoszenie
Odsetek niezależnych zatwierdzeń	Scalone pull requesty, których archiwum pokazuje zatwierdzenie commita HEAD przez człowieka innego niż właściciel i autor, podzielone przez wszystkie scalone pull requesty	100%
Terminowo zatwierdzone zmiany awaryjne	Zmiany awaryjne z retrospektywnym niezależnym zatwierdzeniem w oknie określonym przez twoją politykę, podzielone przez wszystkie zmiany awaryjne	100%

Mianownik bierz z historii gałęzi domyślnej albo z gh api repos/acme/payments-api/pulls?state=closed przefiltrowanego do scalonych pull requestów i porównuj go z listą archiwów: merge, dla którego zadanie archiwizujące się nie uruchomiło, nie ma archiwum, więc wskaźnik liczony tylko z archiwów zawsze pokazuje 100%. Liczniki bierz z archiwów. Change failure rate i lead time definiuje strona frameworki metryk.

Co się psuje w regulowanych potokach agentów i jak to naprawić?

Awaria	Jak się objawia	Jak naprawić
Właściciel zatwierdza pracę agenta, bo autorem jest bot.	Wylosowane zmiany, w których zatwierdzający to human_owner.	Zapisz każdą jako wyjątek kontrolny, uzyskaj retrospektywne niezależne zatwierdzenie i ustaw sod jako wymagany check.
Bot recenzujący liczy się jako zatwierdzenie. Token workflowu, konto aplikacji albo konto maszynowe wysyła zatwierdzające review.	Zatwierdzenia z kont typu Bot albo spoza .github/human-approvers; włączone ustawienie Allow GitHub Actions to create and approve pull requests.	Wyłącz to ustawienie na poziomie organizacji, odbierz aplikacjom agentów prawo zatwierdzania i uruchom ponownie prompt o lukach.
Zatwierdzenie starszego commita. Agent wypchnął poprawkę po zatwierdzeniu.	commit_id zatwierdzającego review różni się od scalonego HEAD.	Włącz dismiss_stale_reviews_on_push i require_last_push_approval; check sod już porównuje commit.
Dowody edytowane po merge’u. Ktoś po miesiącach „porządkuje” pakiet.	Bieżący pull request nie zgadza się z archiwum.	Zapisem jest podpisane archiwum, a nie bieżąca strona. Zweryfikuj je gh attestation verify i odnotuj edycję.
Bypass użyty przy hotfiksie i nigdy nie uregulowany. Administrator scalił zmianę bezpośrednio podczas incydentu.	Zdarzenia bypass w rulesecie albo zmiana produkcyjna bez pull requesta.	Spisz ścieżkę awaryjną: imienną rolę break-glass, pull request po fakcie i retrospektywne niezależne zatwierdzenie w oknie polityki. Zobacz gdy incydent wywoła agent.
Zadanie archiwizujące nie zadziałało przy merge’u. Błąd API GitHuba albo awaria runnera zatrzymały archive-evidence albo zabrakło wyniku recenzji.	Scalony pull request z czerwonym lub brakującym uruchomieniem archive-evidence albo archiwum z plikiem EXCEPTION-agent-review-missing.txt.	Od razu uruchom job ponownie i zapisz wyjątek kontrolny: spóźniona migawka czyta bieżący pull request, który może edytować każdy z uprawnieniami zapisu, więc porównaj opis z historią jego edycji i odnotuj każdą zmianę po merge’u. Gdy brakuje wyniku recenzji, najpierw uruchom ponownie agent-review dla scalonego commita HEAD, potem zadanie archiwizujące.
Agent osłabił test, który dowodzi zmiany.	oracle_changes z kierunkiem looser albo niezadeklarowana edycja testu.	Pakiet podnosi zmianę do ryzyka high i wymusza review code ownera. Pliki wyroczni powinny należeć do ludzi, jak opisuje strona ochrona wyroczni.

Dokąd dalej z regulowanymi potokami agentów

Pakiet dowodów Kontrakt pull requesta, który czytają kontrole z tej strony: specyfikacja, akceptacja, checki, klasa ryzyka i pochodzenie.

CRA, NIS2 i DORA-EU Unijne regulacje stojące za wierszami o finansach i sektorze publicznym, z datami i obowiązkami.

ISO/IEC 42001, NIST AI RMF i dowody SOC 2 Tabela kontrola–dowód dla audytów systemu zarządzania AI i SOC 2 z tego samego potoku.

Governance i autonomia Klasy ryzyka i poziomy autonomii, które decydują, gdzie stoi ludzka bramka.

Tożsamość agentów, poświadczenia i sekrety Osobne tożsamości agentów i krótkotrwałe tokeny, warunek czytelnej historii zatwierdzeń.

AI Act dla firm tworzących oprogramowanie z agentami Co AI Act dodaje, a czego nie dodaje, firmie, która używa agentów do kodowania.