Dlaczego asystent AI do kodowania to dziura w Twoim bezpieczeństwie (i jak to naprawić)

Kilka dni temu doszedłem do wniosku, że przez miesiące pozwalałem narzędziu AI na uruchamianie dowolnych poleceń na moim komputerze. Miało dostęp do kluczy AWS, SSH, prywatnych repo na GitHubie i wszystkiego w moim katalogu domowym. Najgorsze? W ogóle o tym nie myślałem. Bo narzędzie było mega przydatne, a nic złego się nie stało.

To właśnie takie myślenie kasuje bazy danych w produkcji.

Wygoda blokuje myślenie o ryzyku

Prawda boli: dzisiejsze AI do kodowania dostają tyle dostępu, co zaufany devops na pierwszy dzień. Nikomu nie dasz nowemu podwykonawcy pełnego SSH do wszystkich serwerów. Ale LLM-owi? Bez mrugnięcia okiem.

Nie chodzi o złośliwość. Chodzi o nieuwagę. Narzędzia są tak dobre, że zapominamy, co mogą zrobić. Jeden prompt injection z repo, zły cel albo niewinna komenda – i dane lecą do atakującego. Nawet nie zauważysz.

Dobra wiadomość? Narzędzia jak Claude Code mają solidne zabezpieczenia. Tylko mało kto je włącza.

Co kryje się za domyślnymi ustawieniami

Wielu agentów AI działa w trybie "auto". Uruchamiają komendy bez pytania, chyba że coś jest zablokowane. Brzmi sprawnie? W praktyce to znaczy:

Przy pustej liście blokad AI może bez problemu:

• Wysłać curl gdziekolwiek
• Pobrać pliki przez wget
• Połączyć się ssh z serwerami
• Otworzyć połączenia nc
• Przeczytać każdy plik .env
• Zajrzeć do ~/.aws/credentials, ~/.ssh, ~/.gnupg
• Wpychać kod do repo

Wszystko cicho. Bez powiadomień. Po prostu znika.

Trzy warstwy ochrony

Potrzebujesz precyzyjnej kontroli. Nie wszystko wymaga zgody, ale niektóre akcje tak. Oto plan:

Warstwa 1: Bezwzględny zakaz

Zacznij od listy rzeczy z danymi uwierzytelniającymi:

{
  "deny": [
    "Read(~/.ssh/**)",
    "Read(~/.aws/**)",
    "Read(~/.gnupg/**)",
    "Read(~/.azure/**)",
    "Read(~/.kube/**)",
    "Read(~/.npmrc)",
    "Read(~/.git-credentials)",
    "Read(*.env)",
    "Read(.env.*)",
    "Bash(curl *)",
    "Bash(wget *)",
    "Bash(nc *)",
    "Bash(ssh *)"
  ]
}

To jak firewall. Nic z tej listy nie przejdzie. Nawet jeśli AI zechce ukraść klucze, system to zablokuje.

Warstwa 2: Punkt kontroli

Lista "ask" dla ryzykownych, ale odwracalnych akcji:

{
  "ask": [
    "Bash(git push *)",
    "Bash(git commit *)",
    "Bash(git merge *)",
    "Bash(git reset *)",
    "Bash(npm publish *)",
    "Bash(docker push *)"
  ]
}

AI może to robić – push kodu, publikacja paczek, deployment – ale najpierw pyta. Masz szybkość bez wpadek.

Warstwa 3: Zielone światło

Lista "allow" dla bezpiecznych operacji:

{
  "allow": [
    "Bash(npm run *)",
    "Bash(git status *)",
    "Bash(git diff *)",
    "Bash(git log *)",
    "Bash(ls *)",
    "Read(src/**)",
    "Read(tests/**)"
  ]
}

Te idą bez pytania. Nie zmieniają stanu albo robią to bezpiecznie.

Wybór trybu domyślnego

Tu większość się myli. Po listach deny/ask wybierz tryb dla reszty. Opcje:

1. auto – Wszystko poza blokadami leci samo. Najszybciej, ale lista deny musi być idealna.

2. acceptEdits – Czyta i proponuje zmiany swobodnie, ale pyta o bash poza allow. Zrównoważone.

3. ask – Pyta o wszystko ryzykowne. Najwolniej, ale najbezpieczniej.

Dla zespołów acceptEdits to złoty środek. Produktywność bez ślepego zaufania.

Praktyczny przykład konfiguracji

Oto gotowy plik na produkcję:

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.gnupg/**)",
      "Read(~/.azure/**)",
      "Read(~/.kube/**)",
      "Read(~/.npmrc)",
      "Read(~/.git-credentials)",
      "Read(~/.config/gh/**)",
      "Read(*.env)",
      "Read(.env.*)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(nc *)",
      "Bash(ssh *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(git commit *)",
      "Bash(npm publish *)",
      "Bash(docker push *)"
    ],
    "allow": [
      "Bash(npm run *)",
      "Bash(npm install *)",
      "Bash(npm test *)",
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "defaultMode": "acceptEdits"
  }
}

AI pomaga z testami, lintingiem i kodem. Ale nie kradnie kluczy, nie pushe bez zgody ani nie łączy się z serwerami.

Dwa podejścia do różnych sytuacji

Używam dwóch aliasów w shellu:

# Domyślnie: zrównoważone
alias cc="claude --permission-mode auto"

# Debug: pełne zaufanie (rzadko)
alias ccd="claude --permission-mode dangerously-skip-permissions"

cc na co dzień. ccd tylko w kryzysie, świadomie ryzykując.

Problem całej branży

To nie tylko Claude Code. Każdy AI z shell-em ma ten sam problem: Copilot, Devin, Cursor, ChatGPT z kodem. Wszędzie ten sam dylemat: wygoda kontra bezpieczeństwo.

Claude daje narzędzia do kontroli. Inne każe albo ufać na ślepo, albo nie używać.

Co to znaczy dla Twojej infrastruktury

W zespole to kluczowe. Nie licz na deweloperów – nie pomyślą, póki nie wybuchnie.

Zrób:

• Wymuś deny w shared configach
• Blokuj pliki z kluczami na poziomie FS
• Używaj tymczasowych tokenów zamiast stałych
• Kontroluj sieć przed wyciekiem
• Ucz o różnicy między prędkością a ryzykiem

Podsumowanie

AI do kodowania to potęga. Warto używać. Ale nie za darmo. Kontrole istnieją – włącz je.

Dziś poświęć 15 minut. Zrób deny na klucze. Ask na deployment. Wybierz dobry default. I śpij spokojnie: AI pomaga, ale nie panoszy się.

"Dotychczas nic złego" to żadna strategia bezpieczeństwa.