Przejdź do głównej zawartości

Polityka korzystania z AI, której inżynierowie będą przestrzegać

Polityka korzystania z AI dla agentów kodujących to dokument zasad dopuszczalnego użycia, obejmujący klasy danych, zatwierdzone ścieżki dostępu, ujawnianie, obowiązki recenzji i zakazane działania, w którym każdy punkt ma oznaczenie sposobu egzekwowania: ustawienia zarządzane, hook lub reguła repozytorium, wykrywanie po fakcie albo samo zaufanie. Punkty oparte na zaufaniu wymagają nazwanej kontroli.

Wiosną dział prawny rozesłał czterostronicowy PDF „Zasady korzystania z generatywnej AI”. Od tamtej pory dwóch deweloperów zalogowało się do Claude Code kontami prywatnymi, ktoś dodał niesprawdzony serwer MCP, który czyta całą instancję Jiry, a nikt nie potrafi wskazać, które scalone pull requesty napisał agent. PDF nie był błędny; był nieegzekwowalny i nieweryfikowalny.

Ta strona jest dla CTO, który podpisuje politykę, i dla tech leada, który ma sprawić, żeby obowiązywała w ośmiu repozytoriach. Korzysta z poziomów klasyfikacji danych z prywatności danych i polityk firmowych, a dystrybucję i audyt zostawia jednej polityce dla wszystkich agentów kodujących.

  • Politykę w 28 numerowanych punktach do podręcznika zespołu, z typem egzekwowania przy każdym punkcie.
  • Mapę egzekwowania, która wskazuje ustawienie Claude Code, Codex, Cursora albo repozytorium stojące za każdym punktem.
  • Plik ustawień zarządzanych dla Claude Code i requirements.toml dla Codex.
  • Hook sprawdzający prompty i kontrolę ujawniania w pull requestach.
  • Procedurę weryfikacji oraz typowe awarie, które po cichu wyłączają punkty polityki.

Dlaczego inżynierowie ignorują większość polityk AI?

Dział zatytułowany „Dlaczego inżynierowie ignorują większość polityk AI?”

Większość polityk AI opisuje wartości („korzystaj z AI odpowiedzialnie”), a nie zachowania, które recenzent mógłby sprawdzić. Inżynier albo trzyma się litery i traci narzędzia, albo kieruje się własnym osądem i liczy na szczęście. Żadne z nich nie daje „jasnego i zakomunikowanego stanowiska wobec AI” (Clear and communicated AI stance), które DORA wymienia jako pierwszą z siedmiu zdolności w swoim modelu AI (blog Google Cloud, Storer i DeBellis, 2025-09-23). Uzasadnienie DORA: „Niejasność rodzi ryzyko. Jasna polityka daje deweloperom psychologiczne bezpieczeństwo potrzebne do skutecznego eksperymentowania” (oryg. ang.: „Ambiguity creates risk. A clear policy provides the psychological safety developers need to experiment effectively”; blog Google Cloud, Harvey i Park, 2025-12-10).

Polityka, której inżynierowie przestrzegają, jest krótka i konkretna: każdy punkt nazywa działanie, klasę danych albo ustawienie narzędzia, a punkt, którego nie da się złamać konkretnym czynem, należy do preambuły. Jest egzekwowana tam, gdzie pozwala narzędzie, i uczciwa co do reszty: punkty, których nie wyegzekwuje żadne ustawienie („nie wklejaj danych klientów do czatu w przeglądarce na telefonie”), oznacza jako punkty zaufania z nazwaną kontrolą.

OznaczenieZnaczenieDowód, że punkt obowiązuje
[MANAGED]Egzekwowany przez zarządzaną konfigurację narzędzia, której użytkownik ani repozytorium nie nadpiszą/status w Claude Code wskazuje źródło zarządzane; /debug-config w Codex pokazuje źródło wymagań
[HOOK]Egzekwowany przez hook wdrożony przez organizację, który blokuje działanie w trakcie pracyZdarzenia blokad hooka w telemetrii; ćwiczenie, które wyzwala blokadę
[REPO]Egzekwowany przez reguły repozytorium albo wymaganą kontrolę CI, niezależnie od narzędzia, które napisało kodKonfiguracja rulesetów i wymaganych kontroli (status checks); testowy PR, który nie przechodzi
[DETECT]Nie jest blokowany, ale wykrywany po fakcie przez telemetrię, logi audytowe lub skanowanieNazwany dashboard lub raport i jego właściciel
[TRUST]Opiera się na osądzie inżyniera; żadne narzędzie nie widzi tego działaniaNazwana okresowa kontrola (próbkowanie, oświadczenie, rejestr szkoleń)

Dąż do przewagi punktów [MANAGED], [HOOK] i [REPO]; polityka złożona głównie z [TRUST] to PDF działu prawnego, tylko lepiej sformatowany.

Skopiuj go do podręcznika i podmień właścicieli oraz listę narzędzi. Zostaw stałe numery punktów, bo cytują je hooki, komunikaty CI i zgłoszenia wyjątków.

# Polityka korzystania z AI w inżynierii oprogramowania (v1.0, właściciel: CTO, przegląd co kwartał)
Cel: każdy inżynier codziennie korzysta z agentów kodujących w prawdziwej pracy, w granicach,
które egzekwują narzędzia. Tam, gdzie granicy nie da się wyegzekwować, ta polityka mówi to wprost.
## 1. Zakres
1.1 Dotyczy każdego pracownika i współpracownika, który używa narzędzia AI do kodowania (agent w IDE,
agent CLI, agent w chmurze, asystent czatu) przy kodzie, danych lub systemach firmy. [TRUST]
1.2 Dotyczy agentów działających bez nadzoru (zadania CI, pętle cykliczne, boty recenzujące)
przez ich właścicieli wpisanych do rejestru tożsamości agentów. [DETECT]
## 2. Klasy danych (poziomy z polityki prywatności danych)
2.1 Kod Publiczny i Wewnętrzny może trafiać do każdej zatwierdzonej ścieżki (sekcja 3). [MANAGED]
2.2 Materiały Poufne (niewydane funkcje, logika cenowa, projekt zabezpieczeń) mogą trafiać
wyłącznie do zatwierdzonych ścieżek, których warunki wykluczają trenowanie na danych firmy. [MANAGED]
2.3 Poświadczenia nigdy nie pojawiają się w prompcie. [HOOK]
2.4 Dane osobowe klientów, dane płatnicze i medyczne nigdy nie trafiają do kontekstu agenta:
ani w promptach, ani w plikach, które agent może czytać, ani w logach, ani w danych
testowych. [TRUST]
2.5 Agent nie może czytać plików z sekretami (.env*, pliki poświadczeń chmury, klucze SSH). [MANAGED]
2.6 Dane produkcyjne trafiają do agenta tylko jako zanonimizowana lub syntetyczna kopia. [TRUST]
## 3. Zatwierdzone ścieżki
3.1 Używaj tylko narzędzi z rejestru, po zalogowaniu do firmowej organizacji. Konta
prywatne przy pracy dla firmy są niedozwolone. [MANAGED]
3.2 Używaj tylko modeli z listy zatwierdzonych; nowe modele dodaje proces zmiany modelu. [MANAGED]
3.3 Serwery MCP, pluginy i marketplace'y pluginów muszą być na liście dozwolonych. [MANAGED]
3.4 Asystentów czatu w przeglądarce spoza rejestru narzędzi wolno używać tylko do materiałów
Publicznych. [TRUST]
3.5 Narzędzie spoza rejestru można przetestować przez wyjątek (sekcja 7), nigdy przez
instalację i pytanie o zgodę później. [DETECT]
## 4. Ujawnianie
4.1 Commity, których autorem lub współautorem jest agent, mają trailer atrybucji narzędzia;
nie usuwaj go. [MANAGED] [DETECT]
4.2 Każdy pull request podaje poziom udziału AI: none, assisted albo agent-authored. [REPO]
4.3 Materiały dla klientów tworzone z agentami spełniają klauzulę o ujawnianiu z umowy
z klientem. [TRUST]
## 5. Obowiązki recenzji
5.1 Człowiek z prawem scalania zatwierdza każdą zmianę, zanim trafi do gałęzi domyślnej;
zatwierdzenie przez agenta nigdy nie liczy się jako wymagana recenzja. [REPO]
5.2 Zatwierdzający odpowiada za zmianę tak, jakby sam ją napisał, i zatwierdza na podstawie
dowodów (testy, kontrole, kryteria akceptacji), a nie podsumowania agenta. [TRUST]
5.3 Zmiany w ścieżkach należących do zespołów bezpieczeństwa, płatności lub infrastruktury
wymagają recenzji zespołu-właściciela. [REPO]
5.4 Bramki CI (sprawdzanie typów, lint, testy, skanowanie sekretów, kontrola zależności) muszą
przejść; żaden agent nie może ich wyłączyć ani pominąć. [REPO]
## 6. Zakazane działania
6.1 Wklejanie poświadczeń do promptu, pliku lub konfiguracji agenta. [HOOK]
6.2 Uruchamianie agenta z całkowicie wyłączonymi zatwierdzeniami i sandboxem poza jednorazowym
sandboxem z ograniczoną siecią. [MANAGED]
6.3 Pozwalanie agentowi na force-push, przepisywanie wspólnej historii lub push do chronionych
gałęzi. [MANAGED] [REPO]
6.4 Pozwalanie agentowi na wdrożenie na produkcję, migracje na produkcyjnej bazie lub zmianę
sekretów produkcyjnych bez bramki człowieka z polityki zarządzania autonomią. [REPO]
6.5 Dodawanie do repozytorium hooków, serwerów MCP lub pluginów, które poszerzają uprawnienia
agenta, bez przeglądu zespołu platformowego. [MANAGED]
6.6 Używanie wyników agenta do decyzji o ludziach (rekrutacja, ocena pracy). [TRUST]
## 7. Wyjątki i przegląd
7.1 O wyjątek prosi się w zgłoszeniu z numerem punktu, zakresem i datą końcową; zatwierdzają go
właściciel platformy i bezpieczeństwo. [DETECT]
7.2 Politykę przegląda się co kwartał i po każdym incydencie związanym z AI; każda zmiana
wskazuje punkt, powód i zmianę w sposobie egzekwowania. [TRUST]

Szablon ma 28 punktów: 17 egzekwują ustawienia zarządzane, hooki lub reguły repozytorium (6.3 oba mechanizmy; 4.1 jest też wykrywany w CI), 3 są tylko wykrywane, a 8 opiera się na zaufaniu.

Które punkty wyegzekwują Claude Code, Codex i Cursor?

Dział zatytułowany „Które punkty wyegzekwują Claude Code, Codex i Cursor?”

Mapa egzekwowania to dokument roboczy zespołu platformowego: każdy wiersz nazywa ustawienie lub regułę, dzięki której punkt obowiązuje. Kolumna Cursora jest uboższa, bo jego ustawień administracyjnych nie dało się ponownie zweryfikować 2026-09-26; traktuj punkt w Cursorze jako [REPO] plus [TRUST], dopóki administrator Cursora nie potwierdzi kontroli.

PunktClaude Code (ustawienia zarządzane)Codex (requirements.toml)CursorRepozytorium
2.2 Poufne tylko na ścieżkach bez trenowaniaLogowanie do organizacji firmowej (3.1) plus warunki przechowywania danych w tym planieLogowanie do firmowego workspace’u (3.1) plus jego warunkiUstawienia prywatności: potwierdź w panelu—
2.3 Poświadczenia poza promptamiHook UserPromptSubmit kończący się kodem 2[hooks] UserPromptSubmit w requirements.tomlHooki (JSON przez stdio)Skanowanie sekretów z push protection
2.5 Zakaz czytania plików z sekretamipermissions.deny plus sandbox.filesystem.denyRead[permissions.filesystem] deny_read (ścieżki bezwzględne lub globy)Potwierdź w ustawieniach bezpieczeństwa agenta—
3.1 Tylko organizacja firmowaforceLoginMethod, forceLoginOrgUUIDallowed_login_methods, allowed_chatgpt_workspacesSSO w planie zespołowym: potwierdź—
3.2 Zatwierdzone modeleavailableModels, enforceAvailableModels; deniedModels wymaga v2.1.283 (kanał latest na 2026-09-26)Brak klucza listy dozwolonych modeli w requirements.toml (sprawdzone w 0.157.1); model_provider przypina dostawcę, a [models.new_thread] ustawia tylko wartości domyślneKontrola modeli: potwierdź—
3.3 Lista dozwolonych MCP, pluginów i marketplace’ówallowedMcpServers + allowManagedMcpServersOnly, strictKnownMarketplaces[mcp_servers.<name>.identity], plugins, marketplacesPotwierdź w panelu administracyjnym—
4.1 Trailer atrybucjiattribution w ustawieniach zarządzanychWbudowana instrukcja dodania Co-authored-by: Codex <noreply@openai.com>, włączana ustawieniem konta użytkownika—Wykrywanie trailera w CI
4.2, 5.1, 5.3, 5.4, 6.4———Rulesety, CODEOWNERS, wymagane kontrole, zatwierdzenia środowisk
6.2 Zakaz pełnego obejściapermissions.disableBypassPermissionsMode: "disable"allowed_sandbox_modes bez danger-full-access; allowed_approval_policiesPotwierdź kontrolę trybów uruchamiania—
6.3 Zakaz force-pushpermissions.deny dla Bash(git push --force *)[rules] prefix_rules z decision = "forbidden"HookiRulesety gałęzi blokują force-push
6.5 Zakaz hooków dodanych w repozytoriumallowManagedHooksOnly, allowManagedPermissionRulesOnlyallow_managed_hooks_only = true—CODEOWNERS dla .claude/, .codex/, .cursor/

Kolumna repozytorium ocenia zmianę, a nie narzędzie, więc obejmuje każdego agenta, także nieautoryzowane narzędzia; dlatego trafiły tam punkty od 5.1 do 5.4 oraz 6.4. Oba narzędzia dodają atrybucję, instruując model, a nie przepisując commit. Codex bierze przełącznik z ustawień konta użytkownika (commit_attribution_enabled w openai/codex na tagu rust-v0.157.1, sprawdzone 2026-09-26), a requirements.toml nie ma na to klucza, więc w Codex punkt 4.1 jest tylko wykrywany. Człowiek może poprawić każdy commit, więc dowodem dla obu narzędzi jest kontrola trailera w CI.

Jak wyegzekwować punkty o danych i ścieżkach dostępu?

Dział zatytułowany „Jak wyegzekwować punkty o danych i ścieżkach dostępu?”

Rozsyłaj te pliki przez zarządzanie urządzeniami, a nie przez repozytorium (zobacz pierwszą awarię opisaną niżej).

Claude Code czyta ustawienia zarządzane z /Library/Application Support/ClaudeCode/managed-settings.json na macOS, /etc/claude-code/managed-settings.json na Linuksie i WSL oraz z C:\Program Files\ClaudeCode\managed-settings.json na Windowsie, albo z ustawień zarządzanych po stronie serwera w konsoli administracyjnej claude.ai w planach Team i Enterprise. Ustawienia zarządzane mają pierwszeństwo przed argumentami wiersza poleceń oraz ustawieniami projektu i użytkownika.

{
"forceLoginMethod": "claudeai",
"forceLoginOrgUUID": "ORG_UUID",
"availableModels": ["opus", "sonnet"],
"enforceAvailableModels": true,
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(~/.aws/**)",
"Read(~/.ssh/**)",
"Bash(git push --force *)",
"Bash(git push -f *)"
],
"disableBypassPermissionsMode": "disable"
},
"allowManagedPermissionRulesOnly": true,
"sandbox": {
"enabled": true,
"filesystem": { "denyRead": ["~/.aws/credentials", "~/.ssh"] }
},
"allowedMcpServers": [
{ "serverUrl": "https://api.githubcopilot.com/mcp/*" },
{ "serverUrl": "https://mcp.internal.example.com/*" }
],
"allowManagedMcpServersOnly": true,
"strictKnownMarketplaces": [
{ "source": "github", "repo": "anthropics/claude-plugins-official" },
{ "source": "github", "repo": "acme-corp/approved-plugins" }
],
"allowManagedHooksOnly": true,
"attribution": {
"commit": "Co-Authored-By: Claude <noreply@anthropic.com>\nAI-Policy: v1.0"
},
"companyAnnouncements": [
"Obowiązuje polityka korzystania z AI v1.0: handbook/ai-usage-policy. Dane zastrzeżone nigdy nie trafiają do promptu."
]
}

ORG_UUID to identyfikator twojej organizacji w Anthropic. Reguły deny dla Read obejmują narzędzia plikowe Claude’a i polecenia plikowe, które Claude Code rozpoznaje w Bashu, na przykład cat i sed. Przy włączonym sandboxie Claude Code kopiuje każdą ścieżkę z reguł Read(...) do listy denyRead sandboxa, którą system operacyjny egzekwuje dla każdego polecenia w sandboxie; jawne wpisy denyRead dokładają pliki poświadczeń w katalogu domowym, które domyślna polityka odczytu sandboxa zostawiłaby dostępne. Wpisz marketplace’y, które faktycznie zatwierdzasz: pusta tablica strictKnownMarketplaces blokuje każde źródło, łącznie z oficjalnym marketplace’em Anthropic.

Punkty 2.3 i 6.1 wymagają kontroli, która działa, zanim model zobaczy prompt. Poniższy skrypt odrzuca prompt zawierający klucz prywatny albo poświadczenie w typowym formacie; nie rozpozna danych osobowych klientów, dlatego punkt 2.4 zostaje [TRUST]. Zapisz go tam, gdzie deweloperzy nie mogą go edytować, i zarejestruj w ustawieniach zarządzanych.

#!/usr/bin/env bash
# /etc/claude-code/hooks/block-credentials.sh (AI usage policy 2.3, 6.1)
command -v jq >/dev/null || { echo 'Polityka AI: brak jq, prompt zablokowany' >&2; exit 2; }
prompt=$(jq -r '.prompt // empty') || { echo 'Polityka AI: nieczytelne wejście hooka, prompt zablokowany' >&2; exit 2; }
if printf '%s' "$prompt" | grep -Eq -- '-----BEGIN [A-Z ]*PRIVATE KEY-----|AKIA[0-9A-Z]{16}|gh[pousr]_[A-Za-z0-9]{36}|sk-ant-[A-Za-z0-9_-]{20,}'; then
echo "Zablokowane przez politykę AI, punkt 2.3/6.1: prompt zawiera poświadczenie. Usuń je i odwołaj się do sekretu po nazwie." >&2
exit 2
fi
exit 0
{
"hooks": {
"UserPromptSubmit": [
{ "hooks": [{ "type": "command", "command": "/etc/claude-code/hooks/block-credentials.sh" }] }
]
}
}

W Claude Code kod wyjścia 2 z hooka UserPromptSubmit odrzuca prompt i pokazuje komunikat; kod 1 to błąd nieblokujący, który przepuszcza prompt. Przy ustawionym allowManagedHooksOnly działają tylko hooki zarządzane i hooki z pluginów włączonych przez politykę. Dwa warunki z jq sprawiają, że hook blokuje prompt, gdy brakuje jq albo wejścia nie da się sparsować.

Codex ma to samo zdarzenie UserPromptSubmit wśród swoich 12 zdarzeń hooków. Zarejestruj skrypt w tabeli [hooks] pliku requirements.toml (struktura z hook_config.rs i config_requirements.rs w openai/codex na tagu rust-v0.157.1, sprawdzone 2026-09-26):

[hooks]
managed_dir = "/etc/codex/hooks"
windows_managed_dir = 'C:\ProgramData\OpenAI\Codex\hooks'
[[hooks.UserPromptSubmit]]
[[hooks.UserPromptSubmit.hooks]]
type = "command"
command = "/etc/codex/hooks/block-credentials.sh"
timeout = 10

Warstwa użytkownika ani projektu nie podmieni tych hooków zarządzanych. Kod źródłowy nie przesądza, czy Codex odczytuje kod wyjścia 2 tak jak Claude Code, więc potwierdź blokadę w /hooks i promptem testowym. Lista wzorców to minimum: połącz ją z regułami swojego skanera sekretów.

Jak wyegzekwować ujawnianie i recenzję w repozytorium?

Dział zatytułowany „Jak wyegzekwować ujawnianie i recenzję w repozytorium?”

Punkty 4.2 oraz od 5.1 do 5.4 opierają się na trzech kontrolach:

  1. Ruleset na gałęzi domyślnej, który wymaga pull requesta, jednej zatwierdzającej recenzji, zielonych wymaganych kontroli i blokuje force-push. Liczą się tylko zatwierdzenia kont z prawem zapisu, więc nie dawaj go tożsamościom agentów.
  2. CODEOWNERS dla ścieżek należących do bezpieczeństwa i katalogów konfiguracji agentów (.claude/, .codex/, .cursor/, .mcp.json), żeby poszerzenie uprawnień agenta wymagało zespołu platformowego.
  3. Wymagana kontrola ujawniania, poniżej, na każdym pull requeście.
name: ai-disclosure
on:
pull_request:
types: [opened, edited, synchronize]
permissions:
contents: read
jobs:
disclosure:
runs-on: ubuntu-latest
steps:
- name: Require an AI assistance declaration (policy 4.2)
env:
PR_BODY: ${{ github.event.pull_request.body }}
run: |
if ! printf '%s' "$PR_BODY" | grep -Eq '^AI assistance: (none|assisted|agent-authored)[[:space:]]*$'; then
echo "::error::Add 'AI assistance: none|assisted|agent-authored' to the PR description (AI usage policy 4.2)."
exit 1
fi

Workflow przekazuje niezaufaną treść PR przez env:, zamiast wstawiać ją do skryptu. Dowodzi, że deklaracja istnieje, a nie że jest prawdziwa: dodaj drugi krok, który oznacza PR, gdy jego commity mają trailer Co-Authored-By: Claude albo Co-authored-by: Codex, a opis mówi none. Klucz odpowiedzi o pochodzeniu zmian pokazuje, jak zamienić zadeklarowany poziom na głębokość recenzji.

Jak sprawić, żeby punkty zaufania dało się sprawdzić?

Dział zatytułowany „Jak sprawić, żeby punkty zaufania dało się sprawdzić?”

Osiem punktów zostaje [TRUST]. Dla każdego nazwij kontrolę i właściciela, żeby „zaufanie” znaczyło „zaufanie i próbkowanie”, a nie „nikt tego nie ogląda”:

PunktKontrolaWłaścicielCzęstotliwość
1.1, 3.4 Zakres i czat w przeglądarceCoroczne oświadczenie plus rejestr szkoleń z kompetencji AIKierownicy zespołów inżynierskichCo rok, przy onboardingu
2.4 Brak danych osobowych, płatniczych i medycznychPróbka 10 zapisów sesji agenta oraz danych testowych i logów, których dotykały; szukaj prawdziwych danych klientówInspektor ochrony danychCo kwartał
2.6 Zanonimizowane dane produkcyjnePróbka 10 plików z danymi testowymi dodanych w PR-ach agenta; szukaj prawdziwych identyfikatorówInspektor ochrony danychCo kwartał
4.3 Ujawnianie klientowiChecklista umowy na starcie każdego projektu dla klientaKierownik realizacji projektuPrzy każdym projekcie
5.2 Zatwierdzanie na podstawie dowodówPróbka 20 scalonych PR-ów agenta; czy zatwierdzający potrafi wskazać dowody?Tech leadziCo miesiąc
6.6 Brak decyzji o ludziachPrzegląd procesów HRHR i CTOCo rok
7.2 Przegląd politykiDziennik zmian z punktem, powodem i zmianą egzekwowaniaCTOCo kwartał

Rejestr szkoleń z kompetencji AI może też posłużyć jako dowód działań na rzecz kompetencji personelu w zakresie AI, których art. 4 AI Act nadal wymaga (według podsumowania Gibson Dunn, sprawdzonego 2026-09-26, Digital Omnibus złagodził ten obowiązek, ale go nie usunął); zobacz AI Act dla firm tworzących oprogramowanie z agentami.

Trzy punkty [DETECT] również potrzebują nazwanego źródła i właściciela:

PunktŹródło wykrywaniaWłaścicielCzęstotliwość
1.2 Agenci bez nadzoru w rejestrzeRejestr tożsamości agentów uzgadniany z kontami usługowymi CI i tokenami botówZespół platformowyCo miesiąc
3.5 Brak narzędzi spoza rejestruInwentarz oprogramowania z systemu zarządzania urządzeniami plus pokrycie zdarzeniem claude_code.managed_settings_resolvedIT i bezpieczeństwoCo miesiąc
7.1 Wyjątki wygasająZgłoszenia wyjątków po dacie końcowejBezpieczeństwoCo tydzień

Punkt oznaczony [MANAGED], który nie został wdrożony, jest gorszy niż punkt [TRUST], bo wszyscy wierzą, że działa. Przeprowadzaj tę procedurę przy wdrożeniu i co kwartał.

  1. Potwierdź źródło zarządzane na próbce maszyn. W Claude Code /status pokazuje Enterprise managed settings w wierszu Setting sources, a claude doctor wypisuje wpisy odrzucone jako nieprawidłowe. W Codex /debug-config pokazuje warstwy konfiguracji i źródła wymagań.
  2. Przećwicz każdy egzekwowany punkt w jednorazowym testowym repozytorium bez prawdziwych sekretów: najpierw potwierdź, że claude --dangerously-skip-permissions, codex -s danger-full-access i codex --dangerously-bypass-approvals-and-sandbox są odrzucane (6.2), a potem, w zwykłej sesji, wklej fałszywy klucz pasujący do wzorca hooka, dodaj serwer MCP spoza listy i wykonaj force-push z poziomu agenta. Każda próba musi się nie udać z komunikatem, który cytuje punkt polityki.
  3. Sprawdź kontrole repozytorium testowym PR-em. Otwórz PR bez linii ujawniania i drugi, który zmienia .claude/settings.json. Pierwszy musi oblać wymaganą kontrolę, drugi musi wymagać recenzji zespołu platformowego.
  4. Obserwuj sygnały wykrywania. Przy eksporcie OpenTelemetry z Claude Code (CLAUDE_CODE_ENABLE_TELEMETRY=1 i endpoint OTLP ustawiony w ustawieniach zarządzanych) zdarzenie claude_code.managed_settings_resolved pokazuje, które źródło zarządzane wczytała każda sesja, a claude_code.hook_execution_complete liczy decyzje blokujące (num_blocking) dla każdego hooka. Pokrycie poniżej 100% oznacza maszyny poza wdrożeniem, a rosnąca liczba blokad jednego punktu oznacza, że blokuje on prawdziwą pracę (zobacz niżej). Przewodnik po obserwowalności agentów opisuje cały potok.
  5. Zapisz wyniki. Przechowuj dziennik ćwiczeń razem z wersją polityki: to dowód dla audytora i wejście do kwartalnego przeglądu (punkt 7.2).

Zatwierdzenie: właściciel platformy podpisuje dziennik ćwiczeń, bezpieczeństwo kontrasygnuje mapę egzekwowania, a CTO zatwierdza każdą wersję polityki. Model operacyjny umieszcza te role w swojej macierzy RACI.

Uruchom oba prompty w Claude Code lub Codex w katalogu głównym repozytorium z podręcznikiem.

Punkt 6.1 ćwicz osobno, bo hook odrzuciłby wspólny prompt już przy wysłaniu: wyślij jednowierszowy prompt zawierający AKIAABCDEFGHIJKLMNOP i oczekuj komunikatu 2.3/6.1. Punkt 6.2 ćwicz z powłoki, jak w kroku 2 procedury weryfikacji.

„No” w kolumnie blokady to ustalenie audytowe, a nie błąd agenta.

Dlaczego polityki korzystania z AI zawodzą w praktyce?

Dział zatytułowany „Dlaczego polityki korzystania z AI zawodzą w praktyce?”

Polityka zapisana w ustawieniach projektu. .claude/settings.json albo .codex/config.toml w repozytorium można zmienić na dowolnej gałęzi. Naprawa: przenieś każdy klucz egzekwujący do ustawień zarządzanych albo requirements.toml, pliki projektu zostaw na wartości domyślne i ustaw CODEOWNERS na katalogach agentów.

Przypinanie logowania złym kluczem. W Claude Code forceLoginMethod wstępnie wybiera metodę na interaktywnym ekranie /login, ale jej tam nie wymusza; logowanie do claude.ai ogranicza do twojej organizacji dopiero forceLoginOrgUUID ze źródła zarządzanego. Naprawa: ustaw oba klucze i przetestuj logowanie kontem prywatnym.

Reguły deny, które wyglądają na kompletne. Reguły deny dla Read nie obejmują poleceń, które czytają pliki bez podawania nazw, jak grep -r, ani dowolnych podprocesów. Naprawa: włącz sandbox z sandbox.filesystem.denyRead i trzymaj sekrety poza przestrzenią roboczą, zgodnie z tożsamością agentów, poświadczeniami i sekretami.

Plik zarządzany, który blokuje start lub wyłącza funkcję. Claude Code odmawia uruchomienia, gdy plik ustawień zarządzanych nie jest poprawnym JSON-em, allowManagedHooksOnly uniemożliwia działanie /goal, bo ta komenda opiera się na hookach, allowManagedPermissionRulesOnly ignoruje każdą regułę allow użytkownika i projektu, a sandbox.enabled wymaga bubblewrap na Linuksie i WSL2 i nie działa na natywnym Windowsie. Naprawa: waliduj plik w CI, wpisz wspólne reguły allow do ustawień zarządzanych, potraktuj osobno natywny Windows i zacznij od pilotażu.

Hook, który zawodzi w stronę przepuszczenia. Bez tych warunków brakująca zależność albo wejście, którego nie da się sparsować, daje pusty prompt i kod 0, więc przechodzi wszystko, choć punkt nadal ma znacznik [HOOK]. Naprawa: niech hook zawodzi w stronę blokady, jak robią to warunki z jq powyżej, i włącz go do ćwiczenia.

Klucze Codex w złym pliku albo w złym systemie. allow_managed_hooks_only w config.toml nic nie robi, a wpis [rules] z decision = "allow" nie przechodzi parsowania. Jeśli używasz już profili uprawnień (beta), allowed_sandbox_modes to zły klucz: użyj allowed_permission_profiles, bo według OpenAI profile i starszy system sandboxa się nie łączą. Naprawa: trzymaj requirements.toml z lintem w repozytorium platformy i po każdej zmianie sprawdzaj /debug-config na próbce maszyn.

Runnery CI objęte plikiem dla deweloperów. Pominięcie never w allowed_approval_policies blokuje też codex -a never na każdej maszynie z tym plikiem, także na runnerze CI. Naprawa: wyłącz runnery z wdrożenia na urządzenia i daj im osobny requirements.toml.

Polityka blokuje pracę. Inżynierowie obchodzą zatwierdzoną ścieżkę, która jest wolniejsza niż zakazana. Obserwuj kolejkę wyjątków (punkt 7.1) i liczbę blokad hooków; punkt, który co tydzień generuje wyjątki, potrzebuje lepszej zatwierdzonej ścieżki, a nie surowszego okólnika.

Nieautoryzowane narzędzia (shadow AI), których mapa nie objęła. Nowy agent w IDE albo rozszerzenie przeglądarki nie mają żadnych twoich ustawień zarządzanych. Dodaj narzędzie do rejestru albo zablokuj je na poziomie urządzeń, zgodnie z kluczem odpowiedzi o polityce narzędzi.

Każde naruszenie polityki, które dotrze na produkcję, traktuj jak incydent: unieważnij tożsamość, a potem napraw kontrolę, która zawiodła; zobacz gdy incydent wywoła agent.