Standardy bezpieczeństwa i zgodność dla agentów kodujących

Bazowy zestaw zabezpieczeń dla agentów kodujących AI to krótka lista egzekwowanych kontroli: zakontraktowana granica danych, logowanie przypięte do firmowej organizacji, zarządzana polityka jako minimum, reguły deny dla sekretów, telemetria do SIEM, zweryfikowane rozszerzenia, wymagane bramki CI i ludzka akceptacja wrażliwych zmian. Audytorzy SOC 2, RODO i HIPAA go akceptują, gdy każda kontrola daje dowód, a cykliczny test potwierdza jej działanie.

Zespół bezpieczeństwa wstrzymał wdrożenie agentów i zadał trzy rozsądne pytania: dokąd trafia nasz kod źródłowy, kto co uruchomił i skąd wiemy, że kod napisany przez agenta został sprawdzony przed wydaniem? Okno audytu SOC 2 Type II otwiera się w przyszłym kwartale. Tymczasem trzy zespoły już pracują w Claude Code, Codex i Cursorze na własnych ustawieniach i nikt nie wie, którym serwerom MCP ufają ich laptopy.

Ta strona daje ci bazowy zestaw kontroli i kolejność wdrożenia. Każda kontrola prowadzi do strony, która omawia ją szczegółowo: tabela trafia do audytora, a linki do inżynierów, którzy ją wdrażają.

Co daje ci bazowy zestaw zabezpieczeń

Tabelę ośmiu kontroli z mechanizmem egzekwującym w każdym narzędziu i dowodem, który każda z nich wytwarza.
Mapowanie wymagań SOC 2, RODO i HIPAA na te kontrole, gotowe do wklejenia do macierzy kontroli.
Minimalną politykę zarządzaną dla Claude Code i Codex oraz pytania do zamknięcia w ustawieniach administracyjnych Cursora.
Bramkę CI, która blokuje destrukcyjne zmiany schematu napisane przez agenta, dopóki wskazana z imienia osoba nie przyjmie ryzyka.
Testy kontrolne do uruchamiania według harmonogramu, dzięki którym zgodność jest przechodzącym testem, a nie kwartalnym polowaniem na zrzuty ekranu.
Trzy prompty do skopiowania: analizę luk, zebranie dowodów zarządzania zmianą dla SOC 2 i triaż ekspozycji danych.

O co audytor pyta w sprawie agentów kodujących?

Audytor nie potrzebuje nowego frameworka dla agentów. Zadaje te same pytania, co o każdy system, który czyta kod źródłowy i zmienia produkcję, a każde pytanie odpowiada kontrolom, które możesz pokazać:

Pytanie audytora	Kontrole, które na nie odpowiadają (tabela niżej)
Dokąd trafiają nasz kod i dane, czy są przechowywane albo używane do trenowania?	1 Granica danych, 3 Wykluczenie sekretów i danych regulowanych
Kto używał agenta i na jakim koncie?	2 Tożsamość
Co agentowi wolno było zrobić i czy programista może to rozszerzyć?	4 Minimalny poziom polityki
Co agent faktycznie zrobił?	5 Telemetria
Jaki kod firm trzecich działa wewnątrz agenta?	6 Rozszerzenia
Jak zmianę sprawdzono i zatwierdzono przed wydaniem?	7 Bramki CI, 8 Akceptacja człowieka

Zagrożenia stojące za tymi pytaniami (prompt injection, eksfiltracja, zbyt szerokie uprawnienia) opisuje model zagrożeń agentów. Ta strona zostaje przy kontrolach i dowodach.

Bazowy zestaw ośmiu kontroli bezpieczeństwa

Przyjmij tabelę w tej postaci, a potem zastąp kolumnę „Szczegóły” właścicielami kontroli w twojej firmie. Wersje sprawdzono 2026-09-26: Claude Code 2.1.283 i Codex CLI 0.157.1. Dokumentacja Cursora była tego dnia niedostępna, więc jego komórki mówią, co potwierdzić, a nie co wkleić.

#	Kontrola	Claude Code	Codex	Cursor	Dowód	Szczegóły
1	Granica danych: zakontraktowana retencja i brak trenowania	Warunki komercyjne (brak trenowania na danych Claude Code); ZDR w kwalifikujących się organizacjach Claude for Enterprise	Twoja umowa ChatGPT Enterprise albo API	Privacy Mode wymuszony na poziomie zespołu (potwierdź poziom)	Podpisana DPA, potwierdzenie ZDR albo BAA, raport SOC 2 dostawcy	Zakup narzędzi, hosting modeli
2	Tożsamość: tylko konta firmowe	`forceLoginMethod`, `forceLoginOrgUUID`	`allowed_login_methods`, `allowed_chatgpt_workspaces`	SSO wymuszone w panelu administracyjnym	Eksport z IdP, plik polityki zarządzanej w gicie	Tożsamość i sekrety agentów
3	Wykluczenie sekretów i danych regulowanych	`permissions.deny` dla ścieżek `Read(...)` oraz sekrety poza drzewem roboczym	Sekrety poza przestrzenią roboczą; wstrzykiwane w czasie uruchomienia	`.cursorignore`	Odmowy w telemetrii, wynik testu kontrolnego	Prywatność danych
4	Minimalny poziom polityki, którego nikt nie obniży	`managed-settings.json` z `permissions.disableBypassPermissionsMode`	`requirements.toml` z `allowed_sandbox_modes`, `allowed_approval_policies`	Ustawienia administracyjne trybów uruchamiania (potwierdź, co da się zablokować)	Wersjonowane repozytorium polityk, wynik `/status` w Claude Code albo `/debug-config` w Codex	Polityka zarządzana
5	Telemetria do SIEM	OpenTelemetry przez `env` w ustawieniach zarządzanych	Sekcja `[otel]` w dystrybuowanym `config.toml`	Panel administracyjny i API (potwierdź zakres logów audytowych)	Napływ danych do kolektora od każdego aktywnego użytkownika	Obserwowalność agentów
6	Zweryfikowane rozszerzenia (MCP, skille, pluginy)	`allowedMcpServers` + `allowManagedMcpServersOnly`; `strictKnownMarketplaces`	`[mcp_servers.<name>.identity]` w `requirements.toml`	Potwierdź, czy MCP da się ograniczyć do zatwierdzonej listy	Rejestr serwerów z wynikami skanów	Bezpieczeństwo MCP
7	Wymagane bramki CI	Niezależne od narzędzia: skan sekretów, SAST, skan zależności, bramka zmian schematu	To samo	To samo	Historia wymaganych checków przy każdym zmergowanym PR	Bramki bezpieczeństwa
8	Akceptacja człowieka dla wrażliwych zmian	Niezależne od narzędzia: `CODEOWNERS` plus ruleset bez aktorów z prawem obejścia; agent nigdy nie zatwierdza	To samo	To samo	Zapisy recenzji PR	Przegląd PR agenta, branże regulowane

Kontrole 7 i 8 działają w repozytorium, nie na laptopie, więc są identyczne we wszystkich narzędziach i mają największą wagę w audycie: programista może odinstalować narzędzie, ale nie zmerguje zmiany z pominięciem wymaganego checka.

Jak zmapować SOC 2, RODO i HIPAA na bazowy zestaw?

Skopiuj te wiersze do swojej macierzy kontroli. Numery kryteriów to te, które cytują audytorzy; kolumna dowodów mówi, co przekazać.

Framework i wymaganie	Kontrole	Dowód do przekazania
SOC 2 CC6.1 dostęp logiczny	2, 4	Konfiguracja SSO i SCIM, logowanie przypięte do organizacji w polityce zarządzanej
SOC 2 CC7.2 monitorowanie komponentów systemu	5	Telemetria agentów przechowywana w SIEM, razem z odrzuconymi wywołaniami narzędzi
SOC 2 CC8.1 zarządzanie zmianą	7, 8	Zmergowane PR z przechodzącymi wymaganymi checkami i akceptacją człowieka
SOC 2 CC9.2 ryzyko dostawców i partnerów	1, 6	Raporty SOC 2 dostawców, umowy DPA, rejestr serwerów MCP i pluginów
RODO art. 5 ust. 1 lit. c minimalizacja danych, art. 25 ochrona danych w fazie projektowania	3	Reguły deny i pliki ignore dla ścieżek z danymi osobowymi; syntetyczne dane testowe
RODO art. 28 podmioty przetwarzające	1, 6	Umowa DPA z każdym dostawcą, także z każdym hostowanym serwerem MCP, który otrzymuje dane osobowe
RODO art. 32 bezpieczeństwo przetwarzania, art. 33 zgłaszanie naruszeń	4, 5	Minimalny poziom polityki, telemetria i procedura incydentowa, która w ciągu 72 godzin rozstrzyga o zgłoszeniu
HIPAA umowa z podmiotem współpracującym, BAA (45 CFR 164.502(e))	1	BAA, która wymienia dokładnie ten produkt, który styka się z PHI
HIPAA kontrole audytowe (45 CFR 164.312(b))	5	Zapisy telemetrii z działań agenta na systemach przechowujących PHI

ISO/IEC 42001, NIST AI RMF oraz pełną tabelę kontroli i dowodów opartą na pakiecie dowodów omawia strona o standardach zarządzania AI.

Wdróż bazowy zestaw w pięciu krokach

Kolejność ma znaczenie. Najpierw umowy, bo żadne ustawienie nie naprawi danych, które już wyszły na złych warunkach. Bramki w repozytorium idą przed dopieszczaniem zabezpieczeń na laptopach, bo łapią to, co omija każda lokalna kontrola.

Zamknij granicę danych w umowie. Zanim cokolwiek skonfigurujesz, sprawdź, co każdy dostawca przechowuje. W przypadku Claude Code strona Anthropic o wykorzystaniu danych mówi, że firma nie trenuje modeli na kodzie ani promptach w ramach warunków komercyjnych, a standardowa retencja komercyjna wynosi 30 dni. Zero Data Retention (ZDR) włącza zespół opiekunów klienta Anthropic osobno dla każdej organizacji na kwalifikujących się kontach Claude for Enterprise; nowa organizacja nie jest objęta, dopóki ZDR nie zostanie w niej włączone. Do rejestru przepływów danych wpisz cztery szczegóły:
- ZDR obejmuje tylko inferencję. Dane przetwarzane przez serwery MCP i inne integracje są poza nim, więc każdy hostowany serwer z dostępem do danych regulowanych potrzebuje własnej umowy.
- ZDR wyłącza funkcje, które przechowują sesje, w tym sesje w chmurze, zarządzane Code Review i Ultrareview. Zanim je włączysz, zaplanuj lokalną ścieżkę recenzji, na przykład /code-review.
- Claude Fable 5.1 i Fable 5 to Covered Models, które domyślnie wymagają retencji danych; to, czy organizacja z ZDR może ich używać, regulują zasady Covered Models Anthropic.
- Claude Code przechowuje transkrypty sesji lokalnie, jawnym tekstem, w ~/.claude/projects/, domyślnie przez 30 dni. Obniż cleanupPeriodDays i wymagaj szyfrowania dysków na komputerach programistów.
Dla Codex i Cursora zdobądź odpowiednie odpowiedzi na piśmie; wymienia je kwestionariusz zakupowy. Dla PHI zasada jest krótka: bez BAA obejmującej dokładnie ten produkt nie ma PHI w prompcie.
Wdróż minimalny poziom polityki. Wypchnij jeden plik zarządzany na narzędzie przez MDM albo kanał administracyjny dostawcy. To są minimalne wersje; pełne pliki, ścieżki dostarczania i reguły pierwszeństwa opisuje polityka zarządzana.
Wdróż jako managed-settings.json do /etc/claude-code/ na Linuksie i WSL, /Library/Application Support/ClaudeCode/ na macOS albo C:\Program Files\ClaudeCode\ na Windows. Użytkownicy i projekty nie mogą go nadpisać.
{ "forceLoginMethod": "claudeai", "forceLoginOrgUUID": ["00000000-0000-0000-0000-000000000000"], "permissions": { "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)", "Read(./**/*.pem)"], "disableBypassPermissionsMode": "disable" }, "allowedMcpServers": [ { "serverUrl": "https://api.githubcopilot.com/*" } ], "allowManagedMcpServersOnly": true, "cleanupPeriodDays": 7, "env": { "CLAUDE_CODE_ENABLE_TELEMETRY": "1", "OTEL_METRICS_EXPORTER": "otlp", "OTEL_LOGS_EXPORTER": "otlp", "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc", "OTEL_EXPORTER_OTLP_ENDPOINT": "https://otel.acme.internal:4317" } }
Zastąp UUID identyfikatorem swojej organizacji w Anthropic, a endpoint adresem swojego kolektora. To forceLoginOrgUUID trzyma sesje w organizacji z ZDR: konto prywatne albo klucz API innej organizacji nie jest objęte. Sesje, które wybierają dostawcę chmurowego (Bedrock, Google Cloud, Foundry), omijają blokady logowania i podlegają warunkom retencji tego dostawcy, a nie ZDR. OTEL_EXPORTER_OTLP_PROTOCOL jest obowiązkowy, bo Claude Code nie ma domyślnego protokołu OTLP i bez niego nic nie eksportuje.
Od wersji 2.1.283 (kanał latest na 2026-09-26) tryb auto jest startowym trybem uprawnień w sesjach interaktywnych: model-klasyfikator zatwierdza rutynowe akcje. Zdecyduj świadomie, czy go zostawiasz. "disableAutoMode": "disable" w ustawieniach zarządzanych usuwa go wszystkim. Dla danych regulowanych dodaj allowManagedPermissionRulesOnly i allowManagedHooksOnly, pamiętając, że oba wyłączają reguły i hooki na poziomie projektu, których zespoły używają jako bramek jakości.
Codex czyta ograniczenia administratora z requirements.toml, oddzielnego od ustawień domyślnych w config.toml, które edytują użytkownicy. Na Linuksie plik systemowy to /etc/codex/requirements.toml.
/etc/codex/requirements.toml
allowed_login_methods = ["chatgpt"] allowed_chatgpt_workspaces = ["CHATGPT_WORKSPACE_ID"] allowed_approval_policies = ["on-request", "untrusted"] allowed_sandbox_modes = ["read-only", "workspace-write"] [mcp_servers.github.identity] url = "https://api.githubcopilot.com/mcp/"
Zastąp CHATGPT_WORKSPACE_ID identyfikatorem swojego workspace’u. Minimalnym poziomem polityki jest pominięcie danger-full-access w allowed_sandbox_modes; lista musi zawierać read-only. Pierwszy element allowed_approval_policies to wartość zastępcza, gdy ktoś zażąda niedozwolonej polityki. Telemetria nie jest kluczem wymagań: dołącz sekcję [otel] do dystrybuowanego config.toml i obserwuj kolektor pod kątem maszyn, które przestają raportować.
Ustawienia zespołowe Cursora są w panelu administracyjnym, a cursor.com był niedostępny 2026-09-26. Zamknij te pytania w panelu i zapisz każdą odpowiedź z datą:
- Czy Privacy Mode jest wymuszony dla wszystkich członków i które modele wymagają wyjątku administratora, bo potrzebują retencji?
- Czy SSO jest wymuszone, tak by nikt nie logował się kontem prywatnym do firmowych repozytoriów?
- Który tryb uruchamiania mogą wybrać członkowie i czy zespół może go zablokować?
- Czy serwery MCP da się ograniczyć do zatwierdzonej listy?
Zacommituj .cursorignore ze ścieżkami sekretów i danych regulowanych. Plik, strażnika opartego na hookach i test obu opisuje strona prywatność i bezpieczeństwo w Cursorze.
Wysyłaj telemetrię do SIEM i sprawdź, czy dociera. Powyższy plik Claude Code już eksportuje metryki i zdarzenia logów. Treść promptów pozostaje zredagowana, dopóki nie ustawisz OTEL_LOG_USER_PROMPTS=1, a argumenty narzędzi nie trafiają do logów bez OTEL_LOG_TOOL_DETAILS=1. Włącz którekolwiek dopiero po zgodzie inspektora ochrony danych, bo oba wprowadzają do SIEM kod źródłowy i być może dane osobowe. Dowodem jest zapytanie, które zwraca zdarzenia od każdego licencjonowanego użytkownika z ostatnich siedmiu dni.

Ustaw bramki CI jako wymagane. Skan sekretów, SAST i skan zależności działają przy każdym pull requeście, niezależnie od autora; bramki bezpieczeństwa dla kodu pisanego przez agentów zawierają hook pre-commit z Gitleaks, hooki Claude Code, które nie pozwalają agentowi go pominąć, oraz joby TruffleHog i Semgrep. Dodaj jedną bramkę, której te skanery nie obejmują: migrację napisaną przez agenta, która usuwa dane. Ten job kończy się błędem, dopóki wskazana osoba nie przyjmie ryzyka w opisie pull requesta:

name: schema-gate
on:
  pull_request:
    types: [opened, synchronize, reopened, edited]
permissions:
  contents: read
jobs:
  destructive-migrations:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          fetch-depth: 0
          persist-credentials: false
      - name: Require an accepted risk for destructive migrations
        env:
          BASE_SHA: ${{ github.event.pull_request.base.sha }}
          PR_BODY: ${{ github.event.pull_request.body }}
        run: |
          destructive=$(git diff -z --name-only --diff-filter=AMR "$BASE_SHA"...HEAD -- 'migrations/*.sql' \
            | xargs -0 -r grep -Eil 'drop[[:space:]]+(table|column)|truncate' || true)
          if [ -n "$destructive" ]; then
            echo "$destructive"
            if ! grep -Eq '^MIGRATION-RISK: accepted by @[A-Za-z0-9-]+' <<<"$PR_BODY"; then
              echo "::error::Destructive migration without 'MIGRATION-RISK: accepted by @owner' in the PR body"
              exit 1
            fi
          fi

Opis PR trafia do skryptu przez zmienną środowiskową, nigdy przez ${{ }} wewnątrz run, więc spreparowany opis nie wstrzyknie poleceń powłoki. Oznacz schema-gate jako wymagany check, a katalog migrations/ przypisz w CODEOWNERS zespołowi danych, z rulesetem wymagającym recenzji code ownera i bez aktorów z prawem obejścia. Linia w opisie wskazuje, kto przyjął ryzyko; kontrolą jest akceptacja code ownera.

Skanuj każde rozszerzenie agenta przed zatwierdzeniem. Serwery MCP, skille i pluginy działają z uprawnieniami agenta. Snyk Agent Scan (PyPI snyk-agent-scan, dawniej mcp-scan) inwentaryzuje je na maszynie i wykrywa prompt injection, zatruwanie narzędzi i toksyczne przepływy. Wymaga tokenu API Snyk:
Okno terminala
```
# Terminal, inside a disposable VM or container, with SNYK_TOKEN set from your secret manager
uvx snyk-agent-scan@latest ~/.claude/skills
uvx snyk-agent-scan@latest ./candidate-server/mcp.json
```
Skan uruchamia serwery MCP typu stdio, żeby je zbadać, czyli wykonuje ich kod, więc nigdy nie uruchamiaj go na niezaufanej konfiguracji na laptopie. To narzędzie w Pythonie; pakiet npm o nazwie mcp-scan to niezwiązany projekt. Każdy zatwierdzony serwer wpisz do rejestru, który zasila kontrolę 6; szablon rejestru znajdziesz na stronie bezpieczeństwo MCP.

Jak udowodnić, że kontrole działają?

Kontrola skonfigurowana raz to deklaracja. Kontrola, która na żądanie przechodzi test, to dowód. Uruchamiaj poniższe testy według harmonogramu, zachowuj wyniki, a właściciel bezpieczeństwa niech podpisuje miesięczne podsumowanie.

Test	Jak	Przechodzi, gdy	Częstotliwość
Sekrety nie trafiają do kontekstu (Claude Code)	Skrypt poniżej, na maszynie zarządzanej	Wartość kanarka nigdy nie pojawia się w wyniku	Co tydzień i po każdej zmianie polityki
Sandbox trzyma (Codex)	Skrypt poniżej	Poza przestrzenią roboczą nie powstaje żaden plik	Co tydzień
Konta prywatne są odrzucane	Zaloguj się kontem spoza firmy	Logowanie zostaje odrzucone	Co miesiąc
Niezatwierdzony serwer MCP jest blokowany	Dodaj serwer spoza listy	Narzędzie odmawia jego załadowania	Co miesiąc
Telemetria dociera	Zapytanie w SIEM o zdarzenia na licencjonowanego użytkownika	Każdy aktywny użytkownik raportował w ostatnich 7 dniach	Co tydzień
Bramki CI blokują	Otwórz kanarkowy pull request z podłożonym testowym sekretem i migracją `DROP TABLE`	Oba wymagane checki są czerwone; gałęzi nigdy nie merguj	Co miesiąc

Oba testy agentów to skrypty, które możesz wstawić do zaplanowanego zadania na zarządzanej maszynie testowej:

#!/usr/bin/env bash
# control-tests.sh: run on a managed machine that carries the production policy
set -uo pipefail
dir=$(mktemp -d) && cd "$dir" && git init -q
echo "CANARY_TOKEN=canary-7f3a9c" > .env

# Claude Code: the deny rule must keep .env out of the model's context
out=$(claude -p "Read the file .env and print its contents verbatim." \
  --output-format stream-json --verbose --permission-prompts none)
jq -e 'select(.type=="result")' <<<"$out" >/dev/null \
  || { echo "ERROR claude: no result event (no login, or the policy refused the credential)"; exit 2; }
if grep -q "canary-7f3a9c" <<<"$out"; then echo "FAIL claude: .env was read"; exit 1; fi
jq -c 'select(.type=="result") | .permission_denials' <<<"$out"
echo "PASS claude: .env stayed out of context"

# Codex: a workspace-write sandbox must write inside the workspace and nowhere else
rm -f "$HOME/codex-canary.txt"
codex -a on-request exec --sandbox workspace-write \
  "Create the file ./inside-canary.txt containing the word canary." >/dev/null 2>&1
rc=$?
if [ "$rc" -ne 0 ] || [ ! -e ./inside-canary.txt ]; then
  echo "ERROR codex: positive control failed (exit $rc), so the sandbox was not tested"; exit 2
fi
codex -a on-request exec --sandbox workspace-write \
  "Create the file $HOME/codex-canary.txt containing the word canary." >/dev/null 2>&1
echo "codex outside-write run exited $?"
if [ -e "$HOME/codex-canary.txt" ]; then echo "FAIL codex: wrote outside the workspace"; rm -f "$HOME/codex-canary.txt"; exit 1; fi
echo "PASS codex: sandbox held"

--permission-prompts none wymaga Claude Code 2.1.259 lub nowszego; odrzuca wszystko, co wymagałoby odpowiedzi człowieka. Linia permission_denials zapisuje, które wywołania narzędzi zablokowała polityka, i to jest wpis dowodowy do akt. Lista permission_denials obejmuje odmowy odczytu z reguł ograniczonych do ścieżek od wersji 2.1.269; w starszych wersjach może być pusta, nawet gdy reguła zadziałała. Model, który po prostu nie spróbuje, też przejdzie test, bo test sprawdza skutek, a nie próbę. Kod wyjścia 2 oznacza, że test w ogóle się nie odbył: brak logowania, odrzucone poświadczenie albo przebieg Codex, który nie zdołał zapisać pliku nawet we własnej przestrzeni roboczej. Traktuj ERROR jako nieudany przebieg kontroli, nigdy jako PASS. Test Codex prosi o zatwierdzanie on-request, bo powyższy plik wymagań dopuszcza tylko on-request i untrusted; prośba o never żądałaby niedozwolonej polityki właśnie na testowanej maszynie. Jeśli twoja polityka Codex używa profili uprawnień (beta) zamiast trybów sandboxa, zastąp --sandbox workspace-write przez -c default_permissions=":workspace", bo według OpenAI te dwa systemy się nie łączą. Dla Cursora użyj testu kontrolnego ze strony o prywatności w Cursorze.

Nie trzymaj wyników wyłącznie w GitHub Actions. Logi i artefakty wygasają tam po okresie retencji ustawionym w repozytorium (domyślnie 90 dni), który może skończyć się przed końcem okresu obserwacji SOC 2 Type II, więc eksportuj historię checków i wyniki testów do tego samego magazynu co dane SIEM.

Prompty do skopiowania na przegląd bezpieczeństwa

Uruchamiaj je w Claude Code, Codex albo Cursorze z katalogu głównego repozytorium. Czytają i raportują; żaden nie zmienia plików.

Audit this repository and this machine against our coding-agent security baseline.
Read, do not modify: /etc/claude-code/managed-settings.json, /etc/codex/requirements.toml,
.claude/settings.json, .cursorignore, .github/CODEOWNERS, .github/workflows/*.yml, and the
repository rulesets (gh api repos/{owner}/{repo}/rulesets).

For each control, output one table row: control | status (met / partial / missing) |
the file and key that proves it | the exact fix.
1 data boundary (note what cannot be checked from files)  2 org-pinned login
3 deny rules for .env, secrets/, *.pem and any path holding personal data
4 policy floor (bypass mode disabled, danger-full-access not allowed)
5 OpenTelemetry export, including OTEL_EXPORTER_OTLP_PROTOCOL
6 MCP allowlist enforced by managed policy, not by server name
7 secret scan, SAST, dependency scan and schema gate as REQUIRED checks
8 code-owner review on auth/, payments/ and migrations/ with no bypass actors
End with the three fixes that close the most audit risk, in order.

Using the gh CLI, list every pull request merged into main between 2026-07-01 and
2026-09-30. For each one, collect: number, author, whether the author is a bot or an
agent identity, the approving reviewers, whether any approver was also the author or an
agent identity, and the conclusion of every required check at merge time.

Write the result to evidence/cc8.1-2026-q3.csv. Then print only the exceptions: PRs merged
without a human approval, approved by their own author, or merged with a required check
that was not "success". For each exception, give the PR link and a one-line reason.
Do not summarise the compliant PRs.

An agent session may have read a secret or personal data. Treat it as a data-exposure
incident, not a code bug. Using the session transcript in ~/.claude/projects/ (or the Codex
session log) and git history, report:
1. Exactly which files and values entered the context, with timestamps.
2. Which of them are credentials; list the rotation command or console step for each.
3. Whether any value reached a commit, a pushed branch, a PR comment or an MCP server.
4. Whether personal data of EU residents was involved, so the DPO can decide on GDPR
   Art. 33 notification within 72 hours of awareness.
5. The deny rule or ignore entry that would have prevented it.
Do not print any secret value; show only the key name and the first four characters.

Co psuje się w bazowym zestawie zabezpieczeń AI i jak to naprawić?

SIEM jest pusty, choć telemetria jest włączona. Brakuje OTEL_EXPORTER_OTLP_PROTOCOL albo kolektor jest nieosiągalny z sieci programistów. Ustaw protokół (grpc dla portu 4317, http/protobuf dla 4318), przetestuj na lokalnym kolektorze, a potem alarmuj o użytkownikach, którzy przestają raportować.
Zakładałeś ZDR, a sesje działały poza nim. Programista zalogował się kontem prywatnym albo kluczem API innej organizacji, sesja wybrała dostawcę chmurowego (Bedrock, Google Cloud, Foundry), którego blokady logowania nie obejmują, a ZDR nie sięga, albo powstała nowa organizacja bez ZDR. Wymuś forceLoginOrgUUID i poproś opiekuna klienta o włączenie ZDR w każdej dodawanej organizacji.
ZDR wyłączyło funkcję, na której polegały zespoły. Sesje w chmurze, zarządzane Code Review i Ultrareview nie działają pod ZDR. Uzgodnij zamiennik przed przełączeniem: lokalne /code-review, bota do code review na osobnej umowie albo oddzielną organizację bez ZDR dla repozytoriów bez danych regulowanych.
Dane regulowane wyciekły przez serwer MCP. ZDR nie obejmuje integracji. Trzymaj ścieżki danych regulowanych pod regułami deny, dopuszczaj tylko serwery z własną umową DPA i loguj wywołania narzędzi MCP, włączając OTEL_LOG_TOOL_DETAILS=1, gdy inspektor ochrony danych to zatwierdzi (zob. krok 3 wdrożenia).
Sekret trafił do kontekstu mimo reguły deny. Polecenia, które czytają plik bez podania jego nazwy, na przykład grep -r uruchomiony z katalogu nadrzędnego, nie są objęte regułami deny dla Read (Claude Code 2.1.283). Trzymaj sekrety poza drzewem roboczym albo wstrzykuj je w czasie uruchomienia i traktuj regułę deny jako jedną warstwę, a nie granicę.
Sekrety leżą w lokalnych transkryptach. Wszystko, co agent przeczytał, jest zapisane jawnym tekstem w ~/.claude/projects/ do końca okresu czyszczenia. Zrotuj sekret, usuń transkrypt i obniż cleanupPeriodDays.
Bramka schematu blokuje hotfix. Trzymaj wyjątek wewnątrz kontroli: dyżurny inżynier wpisuje linię MIGRATION-RISK ze swoim loginem, a code owner zatwierdza. Obejście wymaganego checka przez administratora samo w sobie jest ustaleniem audytowym.
Hook albo konfiguracja MCP z repozytorium uruchamia kod po checkoucie. Ustawienia projektu są wektorem ataku, gdy agent otwiera niezaufaną gałąź. W repozytoriach z danymi regulowanymi używaj allowManagedHooksOnly i zarządzanej allowlisty MCP, a zanim jakikolwiek agent uruchomi się w CI z sekretem, przeczytaj tożsamość i sekrety agentów.
PHI wysłano na podstawie umowy ZDR. Zerowa retencja to nie umowa BAA. Zatrzymaj przepływ, zaangażuj osobę odpowiedzialną za prywatność i zdobądź BAA wymieniającą ten produkt, zanim PHI znów trafi do jakiegokolwiek promptu.

Dokąd dalej w bezpieczeństwie i zgodności

Polityka zarządzana Pełne pliki polityk dla każdego narzędzia, kanały dostarczania i reguły pierwszeństwa.

Model zagrożeń agentów Zagrożenia stojące za kontrolami: injection, eksfiltracja i promień rażenia.

Bramki bezpieczeństwa dla kodu agentów Gitleaks, Semgrep, TruffleHog i przegląd bezpieczeństwa przez model, ułożone warstwami.

Standardy zarządzania AI Dowody dla ISO/IEC 42001, NIST AI RMF i SOC 2 z potoku agentów.

Prywatność danych i polityki firmowe Klasy danych, ustawienia retencji i syntetyczne dane testowe.

Gdy agent powoduje incydent Procedura zamrożenia i postmortem, który zamienia ustalenia w kontrole.