Warum dein AI-Coding-Assistent ein Sicherheitsrisiko ist – und wie du das änderst

Vor Kurzem ist mir aufgefallen: Monatelang habe ich einem AI-Assistenten freien Zugriff auf meinen Rechner gegeben. Er konnte an AWS-Zugangsdaten, SSH-Keys und private GitHub-Repos. Das Beunruhigende? Mir ist das nie durch den Kopf gegangen. Der Tool war nützlich, und es ist nichts passiert.

Genau so denkt man, bis der Prod-Datenbank leer ist.

Bequemlichkeit täuscht Sicherheit vor

AI-Coding-Tools bekommen heute oft dieselben Rechte wie ein erfahrener Admin. Einen neuen Freelancer lassen wir nicht an alle Server ran. Aber einem LLM überlassen wir das Äquivalent, ohne zu zögern.

Schuld ist keine Bosheit, sondern Fahrlässigkeit. Die Tools sind zu praktisch. Wir vergessen, wozu sie fähig sind. Ein Prompt-Trick in einem geklonten Repo, ein falsches Ziel oder ein harmlos wirkender Befehl – und Credentials wandern zu Angreifern. Unsichtbar.

Zum Glück bieten Tools wie Claude Code echte Schutzmechanismen. Die meisten aktivieren sie nie.

Die Fallstricke im Standard-Modus

Viele AI-Assistenten laufen standardmäßig im "auto"-Modus. Sie führen Befehle aus, ohne zu fragen – außer bei explizit blockierten Aktionen. Klingt effizient? In der Praxis bedeutet das:

Leer-Deny-List plus auto: Der Assistent darf:

• curl an beliebige Endpoints
• wget für Downloads
• ssh zu Servern
• nc für Netzwerkverbindungen
• Alle .env-Dateien lesen
• ~/.aws/credentials, ~/.ssh-Keys, ~/.gnupg durchsuchen
• Direkt in Repos pushen

Alles leise. Kein Ping. Weg.

Dein Drei-Schichten-Schutz

Du brauchst Feinkontrolle. Nicht alles muss abgefragt werden, aber Risiken schon. So baust du es auf:

Schicht 1: Absolute Sperre

Blocke Credential-Zugriffe hart:

{
  "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 *)"
  ]
}

Das ist dein Firewall-Regelwerk. Nix kommt durch, egal was der AI plant.

Schicht 2: Abfrage-Punkte

Für rückgängig machbare, aber riskante Aktionen:

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

Der AI kann das brauchen – Code pushen, Packages veröffentlichen. Aber du prüfst vorab. Effizienz ohne Chaos.

Schicht 3: Freie Bahn

Erlaube Harmloses explizit:

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

Keine Abfrage nötig. Kein Schaden möglich.

Den richtigen Default-Modus wählen

Nach Deny- und Ask-Listen kommt der Standard für den Rest. Drei Varianten:

1. auto – Ungeblocktes läuft stumm. Schnell, aber deine Liste muss wasserdicht sein.

2. acceptEdits – Lesen und Edit-Vorschläge frei, Bash-Befehle (außer allow) werden abgefragt. Ausgeglichen.

3. ask – Jede Riskante Aktion wird gefragt. Langsam, aber bombensicher.

acceptEdits passt für die meisten. Produktivität bleibt, Entscheidungen sind bewusst.

Konfiguration für den Alltag

So sieht eine echte Prod-Konfig aus:

{
  "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"
  }
}

Genug Freiheit für Tests und Code-Verständnis. Kein Diebstahl, kein unkontrollierter Push, keine Server-Verbindungen.

Zwei Modi für verschiedene Fälle

Ich nutze Shell-Aliase:

# Standard: sicher und ausbalanciert
alias cc="claude --permission-mode auto"

# Debug: volle Power (nur kurz)
alias ccd="claude --permission-mode dangerously-skip-permissions"

cc für den Alltag. ccd nur bei echten Notfällen – bewusst riskiert.

Das Problem in der Branche

Claude Code ist nicht allein. Jeder AI mit Shell-Zugriff hat diese Lücke: Copilot-Extensions, Devin, Cursor, ChatGPT mit Execution. Alle balancieren Komfort gegen Risiko.

Claude Code hebt sich ab: Granulare Kontrollen statt All-or-Nothing.

Auswirkungen auf dein Team

In Firmen wird's kritisch. Entwickler denken selten voraus. Mach's zentral:

• Deny-Listen in Team-Configs vorsehen
• Credential-Dateien filesystem-mäßig sperren
• Temporäre Tokens statt fester Keys
• Netzwerk-Filter gegen Exfiltration
• Schulungen zu Produktivität vs. Risiko

Fazit

AI-Coding-Assistenten rocken. Aber Sicherheit kostet Aufwand. Die Tools dafür gibt's – nutz sie.

Heute 15 Minuten investieren: Deny-List für Keys, Ask für Deploys, guter Default. Danach arbeitest du entspannt.

"Noch nix passiert" ist keine Strategie.