Przewodnik po bezpieczeństwie Claude Code: uprawnienia, MCP, piaskownica

Tradycyjne chatboty działają za API, więc w najgorszym razie mogą halucynować. Agent AI do kodowania działa w twoim repozytorium, terminalu i (często) z twoimi poświadczeniami do chmury, czyli dużo bliżej uprzywilejowanych środowisk deweloperskich niż wszystko, co kiedyś nazywaliśmy chatbotem.

Pytanie brzmi: jak bezpiecznie używać Claude Code bez spowalniania pracy. Odpowiednio dobrane uprawnienia, kontrola MCP i piaskownica zaprowadzą cię do celu.

W tym artykule pokażę ci, jak faktycznie działa model bezpieczeństwa Claude Code, gdzie warto zachować czujność oraz jakie praktyki utrzymują go w ryzach, nie dając mu większego dostępu, niż planowałeś.

Jeśli dopiero zaczynasz z Claude i Claude Code, zapisz się na nasz bezpłatny kurs Claude Code 101 i poznaj podstawy w jedno popołudnie.

Zrozumieć model bezpieczeństwa Claude Code

Zanim zaczniesz stroić reguły, potrzebujesz mentalnego modelu tego, co Claude Code rzeczywiście kontroluje.

Jest pięć elementów: system uprawnień, który decyduje, co wolno; kontrola dostępu do narzędzi, która ogranicza konkretne możliwości; uprawnienia MCP dla zewnętrznych integracji; piaskownica zapewniająca izolację na poziomie systemu operacyjnego oraz audytowalność do przeglądu post factum. Każdy rozwiązuje inny problem, ale razem tworzą całość.

System uprawnień

System uprawnień to warstwa statyczna.

Deklarujesz, co Claude może robić, w pliku settings.json, używając trzech list: allow, ask i deny. Reguły są oceniane w kolejności: najpierw deny, potem ask, potem allow, a wygrywa pierwszy dopasowany wpis. Reguła deny blokuje wywołanie, nawet jeśli szersza reguła allow też by je objęła.

Jeśli żadna reguła nie pasuje, Claude wraca do defaultMode bieżącej sesji (o trybach w kolejnym rozdziale).

Kontrola dostępu do narzędzi

Uprawnienia przypisujesz do narzędzi, a nie do agenta jako całości.

Claude Code ma własny zestaw wbudowanych narzędzi, na przykład Bash do poleceń powłoki, Read, Edit i Write do operacji na systemie plików, WebFetch do żądań HTTPS, WebSearch do zapytań i kilka innych. Każda reguła podaje nazwę narzędzia i (opcjonalnie) specyfikator w nawiasie, jak Bash(git commit:*) czy Read(./.env).

To właśnie umożliwia zasadę najmniejszych uprawnień. Możesz zezwolić na Bash(npm run:*) do testów bez dawania Claude pełnego dostępu do powłoki.

Uprawnienia MCP

Serwery MCP rozszerzają Claude Code o narzędzia, do których nie został pierwotnie zaprojektowany.

Każdy serwer dostarcza własny zestaw narzędzi (serwer GitHub dodaje narzędzia do PR-ów, serwer bazy danych dodaje narzędzia do zapytań itd.). System uprawnień obejmuje je również, ale ze składnią mcp__nazwa_serwera__nazwa_narzędzia zamiast nawiasowego specyfikatora.

Pamiętaj, że MCP mniej więcej podwaja problem, bo decydujesz nie tylko, co Claude może robić w twojej powłoce, ale też co może zrobić w każdym zewnętrznym systemie, który do niego podłączysz.

Piaskownica

Piaskownica to zabezpieczenie na poziomie systemu operacyjnego, działające pod narzędziem Bash.

Reguły uprawnień mówią Claude, co powinien robić. Piaskownica egzekwuje, co może robić, ograniczając dostęp do systemu plików i połączeń sieciowych na poziomie OS. Na macOS działa to od razu dzięki Seatbelt. Na Linuksie i WSL2 musisz najpierw zainstalować bubblewrap i socat.

Obie warstwy działają podobnie, ale obejmują różne scenariusze. Uprawnienia powstrzymują Claude przed próbą, a piaskownica powstrzymuje udanie się próby, jeśli wstrzyknięcie promptu namówi Claude do działania mimo wszystko.

Audytowalność

Ostatnim elementem jest możliwość zobaczenia, co się wydarzyło.

Polecenie /permissions wypisuje każdą aktywną regułę i plik ustawień, z którego pochodzi, więc możesz odpowiedzieć na pytanie „dlaczego Claude to uruchomił?”. Hooki (PreToolUse, PostToolUse i inne) pozwalają logować każde wywołanie narzędzia do własnego systemu. W zespołach eksporterzy OpenTelemetry wysyłają dane o użyciu i wywołaniach narzędzi do twojego stosu obserwowalności.

Uprawnienia i kontrola dostępu w Claude Code

Najwięcej bezpieczeństwa zapewniają ustawienia uprawnień, więc to nad nimi spędzisz najwięcej czasu.

Dostęp do plików

Domyślnie Claude może czytać i edytować pliki w katalogu, z którego został uruchomiony.

Czytanie kontroluje narzędzie Read, a edycję Edit i Write. Każde przyjmuje wzorzec ścieżki w nawiasie, w składni jak gitignore, np. Read(**/.env) dopasowuje każdy plik .env na dowolnej głębokości, a Edit(src/**) dopasowuje wszystko pod src/.

Reguła deny na Read obejmuje narzędzia plikowe Claude Code (Read, Grep, Glob, LS), ale to tylko najlepsza próba. Skrypt w Pythonie lub Node uruchomiony przez Bash nadal może otworzyć plik, bo odczyt odbywa się przez powłokę, a nie narzędzie Read Claude’a. Jeśli sekret ma znaczenie, połącz deny na Read z deny na Bash dla cat, head i tail tych ścieżek.

Aby rozszerzyć dostęp poza katalog roboczy, użyj additionalDirectories w settings.json. Tak dasz Claude dostęp do współdzielonej biblioteki poza repozytorium lub pliku konfiguracyjnego w katalogu domowym, bez całkowitego znoszenia granicy katalogu roboczego.

Wykonywanie poleceń

Narzędzie Bash to to, które musisz najbardziej precyzyjnie ograniczyć.

Goła reguła Bash pozwala na każde polecenie. Reguła zawężona, jak Bash(npm run:*), pozwala tylko na pasujące wywołania. Wzorzec dwukropek-gwiazdka jest tu obowiązkowy, a Claude Code rozumie operatory powłoki, więc reguła Bash(safe-cmd:*) nie dopasuje safe-cmd && rm -rf /.

Niektóre polecenia działają bez pytania w każdym trybie, bo domyślnie traktowane są jako tylko do odczytu. Lista obejmuje ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd i formy git tylko do odczytu. Nie możesz ręcznie jej skrócić, ale możesz dodać regułę ask lub deny dla dowolnego z nich, by nadpisać domyślne zachowanie.

Dla wszystkiego, co nie jest wstępnie zatwierdzone, Claude pyta w trybie domyślnym. Prompt pokazuje dokładne polecenie i pozwala zatwierdzić je jednorazowo, zatwierdzić wszystkie przyszłe wywołania pasujące do wzorca albo odrzucić.

Tryby uprawnień

Reguły uprawnień są statyczne, ale tryby uprawnień zmieniają zachowanie w przypadku niedopasowanych wywołań.

Jest ich pięć:

• default: pyta przy pierwszym użyciu każdego narzędzia.

• acceptEdits: automatycznie zatwierdza edycje plików w katalogu roboczym, a nadal kontroluje polecenia powłoki. Przydatne, gdy ufasz edycjom, ale nie powłoce.

• plan: Claude czyta i analizuje, ale nie może edytować plików ani uruchamiać poleceń. Właściwy tryb do code review lub sesji planowania.

• dontAsk: automatycznie odrzuca wszystko, co nie jest wyraźnie dozwolone.

• bypassPermissions: pomija każdy prompt. Bezpieczne tylko w całkowicie izolowanych środowiskach, jak kontener lub VM.

W trakcie sesji możesz przełączać trzy główne tryby skrótem Shift+Tab albo wybrać domyślny w settings.json:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": ["Read(**/.env)", "Read(**/.env.*)"]
  }
}

W zespołach zarządzane ustawienia dają warstwę, której użytkownik nie nadpisze. Plik ma ten sam format JSON i znajduje się w ścieżce systemowej:

• /Library/Application Support/ClaudeCode/managed-settings.json na macOS

• /etc/claude-code/managed-settings.json na Linuksie

• C:\ProgramData\ClaudeCode\managed-settings.json w Windows

Reguły deny w zarządzanych ustawieniach obowiązują we wszystkich projektach na maszynie, co pozwala egzekwować zasady w stylu „nikt nie czyta plików .env” lub „nikt nie uruchamia bypassPermissions” w całej organizacji.

Za tym wszystkim stoi zasada najmniejszych uprawnień — ta sama, którą stosujesz do każdego konta serwisowego. 

Zacznij od najmniejszego zestawu uprawnień, który pozwala wykonać pracę, i rozszerzaj je tylko wtedy, gdy napotkasz ścianę. Wskazówki Anthropic idą w tym samym kierunku — przeglądaj zmiany wprowadzane przez Claude, audytuj reguły poleceniem /permissions i trzymaj ustawienia specyficzne dla projektu w kontroli wersji, by zespół uzgadniał, nad czym Claude może pracować.

Piaskownica w Claude Code

Im więcej pozwalasz Claude działać autonomicznie, tym bardziej sensowna staje się piaskownica.

Narzędzie Bash ma najszerszą ekspozycję, bo polecenia powłoki mogą czytać każdy plik, do którego ty masz dostęp, i modyfikować wszystko, do czego mają prawo zapisu. Piaskownica narzuca granice OS na każde polecenie Bash i jego procesy potomne, więc Claude może działać swobodniej wewnątrz granicy bez twojej akceptacji każdego wywołania. Anthropic zbudował to specjalnie z myślą o bezpieczniejszych autonomicznych uruchomieniach.

Ważny szczegół: piaskownica obejmuje tylko Bash i jego procesy potomne. Nie ogranicza narzędzi Read, Edit ani Write — te nadal przechodzą przez system uprawnień.

Natywna piaskownica

Natywna piaskownica jest wbudowana w Claude Code i włącza się poleceniem /sandbox.

Na macOS używa wbudowanego Seatbelt i nic nie musisz instalować. Na Linuksie i WSL2 instalujesz bubblewrap do izolacji systemu plików i socat do proxy sieciowego. Natywny Windows nie jest wspierany, więc uruchamiasz Claude Code wewnątrz dystrybucji WSL2.

Granica systemu plików jest prosta: odczyty działają wszędzie poza ścieżkami z deny, a zapisy tylko wewnątrz katalogu roboczego i dodatkowych dozwolonych ścieżek. Jeśli spróbujesz zapisać do ~/.bashrc z piaskownicy, dostaniesz „Operation not permitted”, zanim Claude dowie się o porażce.

Granica sieci działa nieco inaczej. Ruch wychodzący przechodzi przez proxy poza piaskownicą, które sprawdza każde żądanie względem listy allowedDomains. Nowe domeny wywołują prompt z prośbą o zgodę, więc dokładnie widzisz, po co sięga Claude.

Działająca konfiguracja wygląda tak:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowWrite": ["/workspace", "/tmp"],
      "denyRead": ["~/.aws", "~/.ssh"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

W wewnętrznym użyciu Anthropic piaskownica zmniejsza liczbę promptów o 84%.

Kontenery deweloperskie

Dev containers to kolejny poziom izolacji.

Anthropic ma referencyjny devcontainer dla Claude Code, który przygotowuje środowisko Ubuntu, montuje twoje repo i daje agentowi powłokę do pracy. Przewaga nad natywną piaskownicą to odtwarzalność — każdy w zespole dostaje to samo środowisko, z tymi samymi narzędziami i konfiguracją.

Minusem jest jednak narzut. 

Dochodzi budowa kontenera, montowanie plików i (czasem) wolniejsza pętla informacji zwrotnej. Dla pojedynczego dewelopera natywna piaskownica zwykle wystarczy. Dla zespołu lub CI — warto.

Izolacja oparta na Dockerze

Dla długotrwałych autonomicznych sesji agenta Docker może dodatkowo poszerzyć granice piaskownicy.

Zwykle wygląda to tak:

• Minimalny obraz bazowy: usuń menedżery pakietów i narzędzia sieciowe, których zadanie nie wymaga.
• Użytkownik bez uprawnień roota: Claude nigdy nie działa jako root, więc nie może zmieniać plików systemowych ani instalować globalnych pakietów.
• System plików root tylko do odczytu: zamontuj root kontenera jako read-only, z możliwością zapisu tylko w konkretnych katalogach wyjściowych.
• Proxy wyjściowe: kieruj ruch wychodzący przez proxy, które dopuszcza rejestry pakietów (npm, PyPI) i blokuje resztę, by działało npm install, ale dowolny curl już nie.
• Limity zasobów: ustaw limity CPU, pamięci i I/O, by proces nie położył hosta.

Docker Sandboxes dają każdej piaskownicy własny microVM z prywatnym demonem Dockera. Demon hosta nawet ich nie widzi w docker ps. Granica jest bliższa VM niż kontenerowi, co zamyka większość dróg ucieczki z kontenera, o które martwią się deweloperzy.

Strategie piaskownic w przedsiębiorstwie

W organizacjach pytanie brzmi, jak warstwować techniki piaskownicy, a nie czy ich używać.

Zwykle podchodzą do tego tak:

• Reguły uprawnień trafiają do managed-settings.json i nie mogą być nadpisane przez deweloperów.

• Natywna piaskownica działa pod warstwą uprawnień.

• Pod nią działają dev containers lub Docker.

• W scenariuszach najwyższego zaufania (dostęp produkcyjny, praca z sekretami) ostatnią warstwą jest dedykowana VM bez montowania systemu plików hosta.

Claude Code w przeglądarce to zarządzona wersja tej samej idei. Każda sesja działa w VM zarządzanej przez Anthropic, wrażliwe poświadczenia jak tokeny git są umieszczone poza piaskownicą w proxy, a granice egzekwuje infrastruktura.

Bezpieczeństwo MCP w Claude Code

MCP to część Claude Code, która najszybciej rośnie.

Każdy podłączony serwer MCP mniej więcej mnoży możliwości Claude, ale też zwiększa powierzchnię, do której może dotrzeć wstrzyknięty prompt lub skompromitowana zależność. 

Na przykład:

• Serwer MCP GitHub daje Claude dostęp do pull requestów.
• Serwer MCP bazy danych daje mu twoje schematy i zapytania.
• Serwer Slack daje mu twoje kanały.

To nie jest problem samo w sobie, ale oznacza, że MCP potrzebuje własnego nadzoru. Treści pobrane przez narzędzie MCP (strona WWW lub odpowiedź API) mogą zawierać wstrzyknięte instrukcje, które Claude wykona tak, jakbyś je wpisał. Dodatkowo każdy serwer dodaje poświadczenie i ścieżkę uwierzytelniania, które trzeba osobno zarządzać.

Uprawnienia narzędzi

Narzędzia MCP używają innej konwencji nazewniczej niż wbudowane narzędzia.

Format reguły to mcp__servername__toolname, bez nawiasowego specyfikatora. Na przykład mcp__github__create_pull_request pozwala Claude wywołać dokładnie to narzędzie, a deny na mcp__github__delete_repo zablokuje niebezpieczne. Listy allow, ask i deny działają tak samo jak dla Bash czy Read.

Obowiązują te same zasady pierwszeństwa — najpierw deny, potem ask, potem allow. Deny w managed-settings na mcp__github__delete_* działa we wszystkich projektach na maszynie.

Uprawnienia do zasobów

Serwery MCP mogą udostępniać wraz z narzędziami także zasoby.

Zasób to porcja danych, które serwer udostępnia do odczytu dla Claude (plik w serwerze zarządzania projektami lub wiersz w serwerze bazy danych). Dostęp do zasobów przechodzi przez tę samą kontrolę zaufania co wywołania narzędzi, a pierwsze połączenie z serwerem MCP uruchamia weryfikację zaufania zanim jakiekolwiek jego narzędzia czy zasoby będą dostępne.

Słuszny domyślny wybór to traktować zasoby jak kolejne narzędzie. Jeśli nie przyznałbyś poświadczeń, nie przyznawaj też dostępu do zasobów.

Zatwierdzone serwery MCP

Katalog Anthropic zawiera konektory, które Anthropic zrecenzował według własnych kryteriów listingu.

Dla organizacji dobrym wzorcem jest wewnętrzna lista dozwolonych. Masz dwa ustawienia, które dają kontrolę:

• allowedMcpServers: wzorzec glob serwerów, które deweloperzy mogą dodać do projektów (np. company-*, by dopuścić tylko wewnętrznie utrzymywane serwery).

• deniedMcpServers: wzorzec serwerów, których nie można dodać, nawet jeśli deweloper próbuje.

Wymagane serwery, które powinny być obecne w każdej sesji, dostarczaj przez plik managed-mcp.json w zarządzanych ustawieniach. Deweloperzy nie mogą usuwać ani zmieniać tych wpisów.

Ustawienia, którego należy unikać we współdzielonych repo, to enableAllProjectMcpServers, które automatycznie zatwierdza każdy serwer MCP zdefiniowany w .mcp.json. Dla pracy solo wygodne, ale niebezpieczne w czymkolwiek zacommitowanym, bo złośliwy PR może dodać nowy serwer do .mcp.json i uruchomić go bez promptu.

Dostęp do narzędzi w duchu najmniejszych uprawnień

Ta sama zasada co przy uprawnieniach Basza, tylko zastosowana do MCP.

Pytanie wyjściowe: jakie poświadczenia ma każdy serwer. Serwer MCP bazy danych powinien łączyć się z repliką do odczytu z prawami tylko do odczytu, a nie z primary z zapisem. Serwer MCP API powinien używać tokenu ograniczonego do najmniejszego niezbędnego zestawu endpointów, a nie osobistego tokenu z pełnym dostępem do organizacji. I tak dalej.

Subagenci to kolejny sposób ograniczania dostępu MCP. Definicja subagenta w .claude/agents/ może wskazać dokładnie, do jakich narzędzi ma dostęp (składnia mcp:<server>:<tool>), więc „deploy-agent” dostaje serwer infrastruktury, a „review-agent” tylko Read, Grep i Glob. Agent nie wywoła narzędzi, których mu nie przydzielono.

Nadzór nad MCP

Dla zespołu lub organizacji używającej Claude Code na dużą skalę MCP potrzebuje takiej samej formy nadzoru jak każda inna integracja produkcyjna.

To znaczy: rejestr zatwierdzonych serwerów z przypisanymi właścicielami, pełne ścieżki audytu wywołań narzędzi (które narzędzia MCP, przez kogo, z jakimi parametrami) i okresowy przegląd listy zatwierdzeń. Eksporterzy OpenTelemetry w Claude Code dostarczają dane audytowe w formacie pasującym do twojego stosu obserwowalności.

W większych organizacjach najczystszym rozwiązaniem jest scentralizowana brama MCP. 

Deweloperzy łączą się z bramą zamiast rejestrować pojedyncze serwery. Brama obsługuje uwierzytelnianie, wymusza dostęp oparty na rolach na poziomie narzędzia i emituje jeden strumień audytowy. Rozwiązuje też rozrost poświadczeń, bo jeden zestaw poświadczeń w bramie zastępuje trzymanie przez deweloperów kopii każdego klucza API.

Zarządzanie sekretami i danymi wrażliwymi

Claude Code może czytać wszystko, co ty możesz czytać, więc sekrety są w zasięgu.

Domyślnie Claude Code może czytać każdy plik dostępny twojemu kontu użytkownika. To obejmuje pliki .env w projekcie, poświadczenia AWS w ~/.aws/, klucze prywatne SSH w ~/.ssh/, tokeny GitHub w twoim pliku rc powłoki i zmienne środowiskowe w każdym procesie potomnym utworzonym przez Claude. To całkowicie normalne i celowe.

Trzymaj sekrety poza przestrzenią roboczą

Pierwszy krok to upewnić się, że sekrety nie leżą w katalogu, który czyta Claude.

.env to najczęstsze pliki. Leżą w katalogu głównym projektu, są ładowane przez każde narzędzie deweloperskie i zawierają dokładnie te wartości, których nie chcesz w kontekście Claude (URL-e baz danych i klucze API). 

Oto kilka wzorców, których możesz użyć:

• Przenieś sekrety do katalogu poza drzewem roboczym, np. ~/.config/myapp/secrets.env, i ładuj je przez menedżera środowiska lub konfigurację direnv, która wskazuje na zewnętrzny plik.

• W pracy kontenerowej trzymaj folder .secrets/ poza bind mountem, by plik był niewidoczny z wnętrza kontenera.

• Dodaj Read(**/.env) i Read(**/.env.*) do listy permissions.deny i sparuj je z deny Bash(cat:*/.env), by skrypt powłoki nie mógł odczytać tego, czego nie może narzędzie Read.

Używaj menedżera sekretów

Do czegokolwiek poza demami właściwym miejscem na sekrety jest menedżer sekretów.

Wzorzec jest taki sam niezależnie od dostawcy (1Password, AWS Secrets Manager, HashiCorp Vault, Doppler, Infisical). Sekrety trafiają do menedżera. Twoja powłoka lub runtime pobierają je na żądanie i ujawniają tylko procesowi, który ich potrzebuje. Claude nigdy nie widzi rzeczywistej wartości.

W przypadku Claude Code oznacza to ustawienie CLAUDE_CODE_SUBPROCESS_ENV_SCRUB, by usuwać poświadczenia Anthropic i dostawców chmury ze środowiska procesów potomnych, albo użycie sandbox.credentials, by odczyścić konkretne zmienne dla poleceń w piaskownicy. Pierwsze powstrzymuje Claude przed przekazaniem twojego ANTHROPIC_API_KEY do skryptu builda, a drugie obejmuje szerszy przypadek dowolnej wrażliwej zmiennej środowiskowej trafiającej do polecenia powłoki.

Ogranicz dostęp do repozytorium

Trzecia opcja dotyczy poziomu repo.

Jeśli deweloper nie potrzebuje zapisu do konfiguracji tylko produkcyjnej, to jego sesja Claude Code też nie. Brzmi oczywiście, ale w większości zespołów domyślnie deweloperzy mają szerszy dostęp, niż rutynowo używają, a Claude go dziedziczy.

Oto dwa kroki, które możesz wykonać:

• Podziel konfigurację produkcyjną do osobnego repo z ostrzejszym dostępem, by środowisko deweloperskie, w którym pracuje Claude, w ogóle nie zawierało sekretów produkcyjnych.

• Używaj tokenów o zawężonym zakresie dla każdej usługi, z którą wchodzi w interakcję Claude. Np. token GitHub do code review nie potrzebuje repo:delete.

Bezpieczeństwo Claude Code dla zespołów

Samodzielny deweloper może zmieniać settings.json jak chce. Zespół nie może, bo ogólne bezpieczeństwo jest tak dobre, jak najsłabsza konfiguracja na najsłabszej maszynie. Dla zespołów i organizacji Claude Code ma osobną warstwę kontroli, którą admin narzuca z góry i której użytkownicy nie nadpiszą.

Zarządzane ustawienia

Zarządzane ustawienia to fundament.

Plik jest w ścieżce systemowej, do której zapis wymaga uprawnień administratora:

• /Library/Application Support/ClaudeCode/managed-settings.json na macOS

• /etc/claude-code/managed-settings.json na Linuksie

• C:\ProgramData\ClaudeCode\managed-settings.json w Windows

Ustawienia w tym pliku mają pierwszeństwo nad ustawieniami użytkownika i projektu. Reguła deny tutaj działa we wszystkich projektach na maszynie, a deweloper nie usunie jej edycją własnego settings.json. Większość organizacji dystrybuuje ten plik przez MDM (Mobile Device Management) lub ten sam kanał, co inne narzędzia dev.

Oto ustawienia warte uwagi na warstwie zarządzanej:

• permissions.deny dla wrażliwych ścieżek i niebezpiecznych poleceń

• defaultMode ustawione na default lub plan (nigdy bypassPermissions)

• allowManagedPermissionRulesOnly: true, aby zablokować zestaw uprawnień

• enableAllProjectMcpServers: false, aby wymagać jawnej akceptacji MCP

• Konfiguracja eksportera OpenTelemetry do logowania

Wspólne polityki uprawnień

Zespół, który uzgadnia, co może robić Claude, powinien wersjonować tę umowę.

Ustawienia projektowe są w .claude/settings.json w katalogu głównym repo. Wszystko, co tam zacommitujesz, dotyczy każdego, kto uruchomi Claude w tym repo. To właściwe miejsce na dozwolenia i zakazy specyficzne dla projektu.

Miej na uwadze podział między ustawieniami zarządzanymi a projektowymi:

• Zarządzane zawierają politykę organizacji (nikt nie uruchamia bypassPermissions, nikt nie czyta .env).

• Projektowe zawierają konwencje workflow (testy w tym repo uruchamiamy npm test; skrypt deploy w tym repo jest poza zasięgiem).

Nadzór zespołowy

Przy wdrożeniu zespołowym warstwa polityk potrzebuje właściciela.

Większość zespołów używających Claude Code na skalę ma małą grupę — zwykle security i platform engineering — która odpowiada za zarządzane ustawienia, listę dozwolonych MCP, skrypty hooków i potok OpenTelemetry. Ta sama grupa przegląda wnioski o wyjątki i dostosowuje politykę, gdy pojawiają się nowe przypadki użycia.

Warto mieć spisane następujące elementy:

• Które repozytoria są w zakresie, a które nie, z trybami dobranymi do ryzyka (repo z danymi regulowanymi prawdopodobnie działa w trybie plan, a repo strony marketingowej w acceptEdits).
• Kto może przyznawać wyjątki i jak są śledzone.
• Kadencja przeglądów (często kwartalna), podczas której zespół wraca do reguł uprawnień, serwerów MCP i danych incydentów.

Logowanie audytowe

Claude Code emituje zdarzenia OpenTelemetry dla każdej decyzji narzędzia, połączenia z serwerem MCP, zmiany trybu uprawnień i żądania API. Żadne dane nie płyną, dopóki admin nie skonfiguruje endpointu OTLP w zarządzanych ustawieniach.

Oto minimalny blok zarządzanych ustawień do telemetrii:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.internal:4317"
  }
}

Domyślnie treść promptów i parametry narzędzi są wykluczone z eksportu, więc zbierasz metadane, a nie pełną rozmowę. Aby uwzględnić treść promptu, ustaw OTEL_LOG_USER_PROMPTS=1. Aby dołączyć argumenty narzędzi (co zwykle chcesz do audytu), ustaw OTEL_LOG_TOOL_DETAILS=1. Obie decyzje mają implikacje prywatności, więc większość zespołów traktuje je jako świadome wybory polityczne i konfiguruje backend telemetrii tak, by filtrował lub zaciemniał dane przed zapisem.

Monitorowanie użycia

Ten sam strumień OpenTelemetry stoi za audytem i monitorowaniem użycia.

Claude Code eksportuje metryki użycia tokenów, kosztu na żądanie, liczby sesji i wskaźników decyzji narzędzi. Zsumowane, mówią, które zespoły czerpią największą wartość, które workflow generują najwięcej odrzuceń i które modele napędzają koszty. Backend’y jak Datadog, Honeycomb, SigNoz, Elastic i Splunk przyjmują standardowy format OTLP.

Skok zdarzeń permission_decision z decision=deny może oznaczać, że Claude próbuje zbyt wiele, ale może też znaczyć, że reguły allow zespołu są zbyt wąskie.

Częste błędy bezpieczeństwa w Claude Code

Niewielki zestaw błędnych konfiguracji pojawia się w większości incydentów z Claude Code. Pokażę ci, jakie to i co z nimi zrobić.

Zbyt szerokie uprawnienia

Najszybszy sposób na stępienie systemu uprawnień to pozwolić na zbyt wiele.

Prompty per polecenie dodają tarcie i łatwo to „naprawić” szerokim Bash(*) allow lub ustawieniem defaultMode: bypassPermissions. Oba te kroki niweczą większość działania systemu uprawnień.

Zawężaj reguły allow do konkretnych narzędzi i poleceń, których naprawdę używasz (np. Bash(npm test:*) i Bash(git status)), a resztę zostaw na prompt. Na początku promptów będzie więcej, ale po kilku sesjach masz na liście allow swoje komendy i prośby w dużej mierze znikają.

Nieograniczony dostęp MCP

Drugi błąd to podłączanie serwerów MCP bez sprawdzenia, jakich poświadczeń używają i do czego mają dostęp.

Zwykle dzieje się tak, bo ktoś włącza enableAllProjectMcpServers, podłącza kilka serwerów z publicznego katalogu MCP i nigdy do nich nie wraca. Gdy serwer ze słabymi poświadczeniami wycieknie coś wrażliwego, połączenie jest tak dawno w konfiguracji, że nikt nie pamięta jego akceptacji.

Rozwiązanie jest takie samo jak przy uprawnieniach. Używaj jawnej listy dozwolonych przez allowedMcpServers, wewnętrznego managed-mcp.json dla serwerów potrzebnych wszystkim i cyklicznych przeglądów listy.

Brak piaskownicy

Jeśli piaskownica jest wyłączona, system uprawnień to jedyna bariera między Claude a twoim systemem plików.

To w porządku przy krótkich interaktywnych sesjach, gdy i tak zatwierdzasz każde polecenie. Nie jest w porządku dla autonomicznych uruchomień, sesji z poszerzonymi allow ani pracy z kodem z zewnętrznych źródeł.

/sandbox ją włącza. Jeśli brakuje zależności, menu pokaże, co zainstalować dla twojej platformy. Po włączeniu liczba promptów spada, a system operacyjny łapie przypadki, których nie obejmują twoje reguły allow.

Ślepe akceptowanie zmian

acceptEdits jest i wygodne, i ryzykowne.

Gdy Claude przepisuje funkcję, a ty to nadzorujesz, autoakcept jest OK. Gdy Claude iteruje po 30 plikach przez godzinę, przestajesz czytać diffy i zaczynasz ufać agentowi. Wtedy mogą pojawić się problemy.

Dwie dobre praktyki:

• Zawsze rób commit przed pozwoleniem Claude działać autonomicznie, by ścieżka rollbacku była o jedno git reset dalej.

• Przeglądaj diff przed każdym commitem autorstwa Claude, a nie zbiorczy diff na końcu sesji.

Ignorowanie ścieżek audytu

Zespół używający Claude Code bez telemetrii nie odpowie na pytanie „która sesja to zrobiła?”. Zdarzenia gromadzą się lokalnie na każdej maszynie i tam zostają. Pierwszy raz, gdy potrzebujesz ścieżki audytu, to najgorszy moment, by odkryć, że jej nie skonfigurowałeś.

Minimalna użyteczna podstawa to eksport zdarzeń tool_decision, permission_decision i api_request do stosu obserwowalności, który zespół już ma. Potem budujesz dashboardy i alerty w miarę potrzeb.

Podsumowanie

Najgorszy scenariusz dla chatbota to zła odpowiedź. Dla agenta kodującego to polecenie powłoki uruchomione na produkcji z twoimi poświadczeniami.

Dlatego liczą się trzy filary:

• Uprawnienia decydują, co Claude może robić
• Kontrole MCP decydują, do jakich systemów zewnętrznych ma dostęp
• Piaskownica decyduje, co się stanie, gdy dwa pierwsze nie wystarczą

Każdy z nich obejmuje tryb awarii, którego nie obejmują pozostałe. Razem definiują realną granicę, w której działa Claude.

Jeśli chcesz zdobyć certyfikację z generatywnej AI, znajdziesz tu porównania, najlepsze kursy, wskazówki i FAQ dla Najlepszych certyfikatów z generatywnej AI w 2026.