Governance i autonomia: człowiek przy bramkach

Governance AI-native daje agentom szeroką możliwość analizy i weryfikacji, ale rezerwuje nieodwracalne, regulowane oraz produkcyjne decyzje dla wskazanych ludzi i kontroli platformy. Autonomia wynika z ryzyka i środowiska, nie z pewności modelu ani producenta. Każda sesja ma tożsamość, zakres, kontrakt dowodu i bramkę.

Nadzór człowieka przenosi się z pisania każdej linii na jawne decyzje: zaakceptuj problem, design, ryzyko implementacji, merge i produkcję. Deterministyczne checki pilnują niezmienników; agenci ujawniają kontekst i wyjątki.

Zdefiniuj cztery tiery ryzyka

Tier	Typowa zmiana	Agent może	Wymagana decyzja człowieka
0. Tylko odczyt	Research, inwentaryzacja, plan, review	Czytać zaakceptowane źródła i tworzyć artefakty lub findings	Zaakceptować albo odrzucić artefakt
1. Odwracalna lokalnie	Testy, dokumentacja, izolowana implementacja	Edytować izolowany checkout i uruchamiać lokalne checki	Przejrzeć diff i wykonać merge
2. Współdzielone non-production	Preview, staging, próba migracji	Użyć ograniczonych poświadczeń non-production i zatwierdzonych runbooków	Zaakceptować mutację wspólnego stanu i promocję
3. Produkcja lub regulacje	Deploy, migracja danych, wyjątek security, operacja destrukcyjna	Przygotować dowody, dry run, rollback i prośbę o approval	Wskazany właściciel zatwierdza, a platforma wykonuje akcję

Ryzyko rośnie wraz z blast radius, wrażliwością danych, odwracalnością, skutkiem regulacyjnym i zakresem poświadczeń. Mały diff nadal może być Tier 3, jeśli zmienia logowanie, billing albo dane produkcyjne.

Rozdziel tożsamość i uprawnienia

1. Nadaj agentom nieinteraktywnym osobną tożsamość usługową. Nie używaj szerokiego tokenu programisty.

2. Przyznaj najmniejszy zakres repozytorium, sieci, chmury i danych potrzebny w danym tierze.

3. Odmów sekretów produkcyjnych zadaniom Tier 0–2. Prompt “nie wdrażaj” nie jest granicą dostępu.

4. Wymagaj branch protection i akceptacji code ownera przy merge.

5. Wymagaj osobnej akceptacji środowiska wdrożeniowego dla Tier 3. Agent piszący i agent review nie mogą jej spełnić.

6. Loguj inicjującego człowieka, tożsamość agenta, wersje artefaktów, komendy, findings, approval, wdrożenie i wynik rollbacku.

Użyj kontraktu dowodu

Każde zadanie autonomiczne lub w tle definiuje:

• Wejście: commit, artefakty, ticket, okno telemetrii i dozwolone źródła.
• Zakres: katalogi, narzędzia, sieć, poświadczenia i limit czasu lub budżetu.
• Dowód: komendy, oczekiwany status, screenshoty, schemat lub próg pewności.
• Wyjście: plik, PR, komentarz lub rekord odczytywany przez następną bramkę.
• Błąd: niezerowy status, timeout, brak zależności, niska pewność i właściciel eskalacji.
• Uprawnienia: akcje bez approval oraz pierwsza akcja zawsze zatrzymywana dla człowieka.

Powtarzalny prompt:

Run as risk tier TIER on commit SHA. Inputs: ARTIFACTS.
Allowed scope: PATHS, TOOLS, NETWORK, CREDENTIAL_CLASS, TIME_LIMIT.
Required proof: COMMANDS_AND_EXPECTED_RESULTS.
Output: DESTINATION_AND_SCHEMA.
Fail closed on missing evidence, permission errors, or uncertainty.
Do not merge, deploy, mutate production, weaken tests, or approve your own work.
Escalate to OWNER with the evidence already collected.

Dobierz kontrolę do warstwy

Potrzeba	Właściwa kontrola
Wyjaśnienie architektury lub konwencji	CLAUDE.md, .cursor/rules/*.mdc lub AGENTS.md
Powtarzalny wieloetapowy workflow	Skill
Deterministyczne blokowanie albo logowanie narzędzia	Hook lub execution policy
Ograniczenie plików, komend i sieci	Sandbox oraz ograniczona tożsamość
Review przed mergem	Branch protection i code owners
Autoryzacja przed produkcją	Środowisko wdrożeniowe lub bramka change management
Bezpieczne odzyskanie	Przećwiczony rollback ze wskazanym właścicielem
Dowód zdarzeń	Niezmienne logi CI, PR, wdrożenia i incydentu

Dwa agenty nie tworzą rozdziału obowiązków

Agent piszący i agent review poprawiają wykrywanie, lecz mogą dzielić poświadczenia, konfigurację, ślepe punkty modelu i organizację. Prawdziwa bramka używa niezależnej tożsamości albo polityki platformy i wymaga człowieka odpowiedzialnego za ryzykowną decyzję.

Przećwicz kontrole

1. Poproś agenta Tier 1 o zapis poza dozwolonym workspace. Sandbox musi to zablokować.
2. Poproś o pominięcie nieprzechodzącego wymaganego testu. Workflow musi się zatrzymać.
3. Spróbuj merge bez akceptacji code ownera. Branch protection musi zablokować operację.
4. Spróbuj wydania produkcyjnego bez wskazanej zgody. Platforma wdrożeniowa musi je zablokować.
5. Uruchom rollback w reprezentatywnym non-production i zmierz czas odzyskania.
6. Zmień regułę, skill albo hook i uruchom evale harnessu przed rolloutem.

Problemy governance

Tekst doradczy jest traktowany jako egzekwowanie. Przenieś niezmienniki do hooków, execution policy, CI lub uprawnień platformy.

Jeden token sięga każdego środowiska. Rozdziel tożsamości i rotuj poświadczenia. Worktree lub kontener nie zawęża tokenu chmurowego.

Ludzka bramka nie ma kryteriów decyzji. Przed automatyzacją zdefiniuj dowody, próg ryzyka, właściciela, timeout i ścieżkę eskalacji.

Rollback istnieje tylko w dokumencie. Przećwicz go w reprezentatywnym non-production i zmierz czas przywrócenia.

Zastosuj governance w narzędziach

Adapter Claude Code Dobierz permission mode, hooki, worktree i tożsamość CI bez przekazywania produkcji Claude.

Adapter Cursora Połącz tryby, sandbox, hooki, worktree, Bugbota i zewnętrzne bramki.

Adapter Codex Połącz sandbox, approval policy, hooki, worktree aplikacji, review i bramki.

Przejdź do Deploy po procedurę review i wydania albo do Maintain po ograniczoną pracę uruchamianą z produkcji.