Claude Skills Sicherheitsrisiken: Was 2026 wirklich zählt

Micha, Consultant für KI-Infrastruktur und Security bei Pexon Consulting | 9 Min. Lesezeit | 11.09.2026

TL;DR: Claude Skills Sicherheitsrisiken in fünf Sätzen

Claude Skills sind Markdown-Erweiterungen, die mit den vollen Rechten des Agents laufen. Eine Analyse von 42.447 Skills fand in 26,1 Prozent mindestens eine Schwachstelle. Ungeprüfte Marketplace-Skills riskieren Prompt Injection, Datenoffenlegung und kompromittierte Entwickler-Rechner. Pexon Consulting (80 Mitarbeiter, Deutschland, Microsoft Partner) prüft installierte Skills, Berechtigungen und Deny-Regeln im Claude Code Security-Audit mit priorisiertem Maßnahmenbericht.

Was sind Claude Skills und warum sind sie ein Sicherheitsthema?

Ein Claude Skill ist im Kern eine SKILL.md-Datei: Anweisungen plus optionale Skripte, die Claude Code bei passendem Prompt automatisch lädt und ausführt. Das macht Skills so praktisch und gleichzeitig so heikel. Es gibt keine Installation im klassischen Sinne, keinen Paketmanager mit Signaturprüfung, kein Admin-Gate.

Skills landen per Copy oder Git-Clone in ~/.claude/skills/ auf dem Entwickler-Rechner. Von dort laufen sie mit allem, was der Agent darf: Dateisystemzugriff, Codeausführung über Bash, Netzwerkzugriffe, Zugriff auf alle verbundenen MCP-Server. Ein Skill erbt das komplette Berechtigungssystem der Session, in der er läuft.

In einem Kundenprojekt haben wir beim ersten Inventarisierungslauf über 400 Agent Skills auf Workstations gefunden, von denen das Security-Team nichts wusste. Das ist kein Ausreißer, sondern der Normalfall: Skills erzeugen kein SIEM-Event, tauchen in keinem MDM-Inventar auf und werden von klassischen Endpoint-Scannern schlicht als Textdateien gelesen. Damit sind Claude Skills Sicherheitsrisiken zuerst ein Sichtbarkeits-Problem: Was niemand sieht, prüft auch niemand.

Das Problem: Ein Marketplace ohne Türsteher

Die Zahlen aus 2026 sind deutlich. Snyk hat in der ToxicSkills-Studie die Skills-Supply-Chain untersucht und in 36 Prozent der geprüften Agent Skills Prompt-Injection-Muster gefunden, dazu 1.467 als bösartig oder verwundbar eingestufte Skills. Eine zweite, breitere Analyse über 42.447 Skills kam auf 26,1 Prozent mit mindestens einer Schwachstelle. Und im Februar 2026 lief mit ClawHavoc die erste koordinierte Malware-Kampagne über einen öffentlichen Skill-Marketplace: über 300 vergiftete Pakete, dahinter ein Infostealer, der Logins, Keychain-Passwörter und Wallet-Dateien abgriff.

Warum funktioniert das? Weil die Hürde zum Publizieren praktisch null ist. Für einen Marketplace-Eintrag reichte zeitweise ein GitHub-Konto, das eine Woche alt ist, und eine SKILL.md. Kein Code-Signing, kein Review, keine Sandbox per Default. Die Parallele zu npm und PyPI drängt sich auf, mit einem entscheidenden Unterschied: Ein npm-Paket wird ausgeführt, wenn ein Entwickler es bewusst einbindet. Ein Skill wird ausgeführt, wenn ein Sprachmodell entscheidet, dass er zum Prompt passt.

Die OWASP hat darauf reagiert und im März 2026 die Agentic Skills Top 10 (AST10) formalisiert. Dass eine eigene Top-10-Liste nötig wurde, sagt genug über die Angriffsfläche: Claude Skills Sicherheitsrisiken sind inzwischen eine eigene Prüfkategorie, und die gefundenen Sicherheitslücken haben Namen und Nummern.

Claude Skills Sicherheitsrisiken in der Praxis: die vier, die zählen

Wir raten davon ab, sich an theoretischen Bedrohungskatalogen abzuarbeiten. In unseren Audits tauchen immer wieder dieselben vier Muster auf:

Der gefährlichste Verstärker ist dabei hausgemacht: --dangerously-skip-permissions. Das Flag schaltet jede Rückfrage ab und ist in Tutorials erschreckend verbreitet. Unsere Position ist eindeutig: Auf Rechnern mit Zugriff auf Produktionssysteme oder Kundendaten hat dieses Flag nichts verloren, auch nicht „nur kurz zum Testen“. Wer volle Autonomie braucht, nimmt eine virtuelle Maschine oder einen Container ohne Secrets und ohne Netzwerkroute in interne Systeme.

Was Anthropic im September 2026 geändert hat

Anthropic hat nachgelegt. Das Claude-Code-Release von September 2026 bringt eine OS-Level-Sandbox für Bash, also eine sandboxed Laufzeitumgebung: Dateisystemzugriff wird auf das Arbeitsverzeichnis begrenzt, Netzwerkzugriffe laufen über einen Proxy, der nur freigegebene Domains durchlässt. In Anthropics interner Nutzung sanken die Permission-Prompts damit um rund 84 Prozent, weil harmlose Kommandos ohne Rückfrage laufen können und nur echte Grenzüberschreitungen eskalieren. Die Sandbox-Runtime ist zudem als Open-Source-npm-Paket verfügbar und lässt sich in eigene Agent-Projekte einbauen.

Das ist ein echter Fortschritt, aber kein Freifahrtschein. Die Sandbox begrenzt, was ein Skill technisch erreichen kann. Sie beantwortet nicht, welche Skills überhaupt auf den Rechnern liegen, wer sie geprüft hat und ob die Berechtigungskonfiguration zum Schutzbedarf passt. Dazu kommt: Die Sandbox greift nur dort, wo sie auch aktiviert und richtig konfiguriert ist. In gewachsenen Umgebungen mit Dutzenden Entwickler-Setups ist genau diese Konsistenz das eigentliche Problem, nicht das Feature-Set des Herstellers. Governance bleibt Aufgabe des Unternehmens, egal mit welchem Modell die Entwickler arbeiten, ob claude-sonnet-5 im Tagesgeschäft oder größere Modelle für Spezialfälle.

So prüfen Sie Skills, bevor sie laufen

Die kurze Antwort: Allowlist statt Blocklist, und jede SKILL.md liest vor dem ersten Lauf ein Mensch. Konkret hat sich bei unseren Kunden dieses Vorgehen bewährt:

1) Inventar aufbauen: Welche Skills liegen auf welchen Rechnern? Ein einfacher Sweep reicht für den Anfang:

# Skills auf dem Rechner inventarisieren (User- und Projekt-Ebene)
for d in ~/.claude/skills */.claude/skills; do
  [ -d "$d" ] && find "$d" -name "SKILL.md" -exec echo {} ;
done

# Verdächtige Muster grob vorfiltern: Netzwerk-Calls und Encoding
grep -rEn "curl|wget|base64|eval" ~/.claude/skills --include="*.md" --include="*.sh"

2) Nur vertrauenswürdige Quellen zulassen: internes Repo mit Review-Pflicht statt direkter Marketplace-Installation. Jeder Skill durchläuft ein Code-Review wie andere externe Abhängigkeiten auch.

3) Berechtigungen hart konfigurieren: Deny-Regeln in der settings.json gehören zentral verwaltet, nicht in die Hand jedes einzelnen Entwicklers:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl:*)",
      "WebFetch"
    ]
  }
}

4) Regelmäßig nachprüfen: Skills ändern sich per Git-Pull. Ein Skill, der beim ersten Review sauber war, ist es nach dem nächsten Update nicht automatisch noch. Die Berechtigungsprüfung gehört deshalb in einen wiederkehrenden Takt, nicht in ein einmaliges Onboarding.

Das klingt nach Aufwand, ist aber deutlich billiger als der Gegenentwurf. Ein einziger Infostealer auf einem Entwickler-Rechner mit Produktions-Credentials kostet mehr als jede gründliche Prüfung des gesamten Skill-Bestands.

Wo Skills trotzdem die richtige Entscheidung sind

Bei aller Risikodiskussion: Die Antwort auf Claude Skills Sicherheitsrisiken heißt nicht Verbot. Teams, die Skills sauber einsetzen, standardisieren damit Deployment-Abläufe, Review-Checklisten und Doku-Workflows und sparen messbar Zeit. Ein Verbot treibt die Nutzung nur in den Schatten, und Schatten-Skills sind das schlechteste aller Szenarien, wie die 400 unbekannten Skills aus dem Kundenbeispiel oben zeigen.

Unsere Empfehlung ist deshalb ein Dreiklang: erlauben, aber nur aus dem internen, reviewten Katalog. Begrenzen, über Sandbox und Deny-Regeln. Und prüfen, in festem Rhythmus statt einmalig. Private Projekte auf Privat-Rechnern kann man Entwicklern lassen; sobald Firmencode oder Kundendaten im Spiel sind, gelten die drei Regeln ohne Ausnahme.

Häufig gestellte Fragen

Was kostet ein Security-Audit für Claude Code und Skills?

Das hängt von der Zahl der Entwickler-Umgebungen und der Tiefe ab. Ein fokussiertes Audit über Skills, Berechtigungen und MCP-Konfiguration ist als Festpreis-Paket in wenigen Tagen machbar, deutlich unterhalb eines klassischen Pentests. Den konkreten Zuschnitt zeigt unsere Security-Audit-Seite.

Sind Claude Skills DSGVO-konform einsetzbar?

Ja, aber nicht automatisch. Entscheidend ist, welche Daten ein Skill lesen und wohin er sie senden kann. Mit Deny-Regeln auf personenbezogene Datenpfade, einem Netzwerk-Proxy mit Allowlist und einem AVV mit Anthropic ist der Einsatz sauber gestaltbar.

Wie erkenne ich einen bösartigen Skill?

Verlässlich nur durch Review. Warnzeichen sind Netzwerk-Calls an unbekannte Domains, Base64-kodierte Blöcke, Anweisungen wie „ignoriere vorherige Regeln“ und Skripte, die außerhalb des Projektverzeichnisses lesen oder schreiben. Automatische Scanner helfen beim Vorfiltern, ersetzen das Review aber nicht.

Sind Claude Skills riskanter als MCP-Server?

Es sind zwei verschiedene Angriffsflächen. MCP-Server sind laufende Prozesse mit definierten Tools, Skills sind Anweisungstexte mit vollen Session-Rechten. Skills sind leichter einzuschleusen, MCP-Server haben oft weitreichendere Systemzugriffe. Ein Audit sollte immer beide zusammen betrachten.

Reicht die neue Sandbox von Anthropic nicht aus?

Die Sandbox aus dem September-2026-Release begrenzt Dateisystem- und Netzwerkzugriffe deutlich, ist aber opt-in-konfiguriert und schützt nicht vor Skills, die innerhalb der erlaubten Grenzen Schaden anrichten. Inventar, Review-Prozess und Berechtigungs-Governance bleiben notwendig.

Nächster Schritt

Wenn Claude Code bei Ihnen im Einsatz ist, lohnt sich ein nüchterner Blick auf den Ist-Zustand: Welche Skills laufen, mit welchen Rechten, geprüft von wem? Genau das beantwortet das Security-Audit, bevor es ein Vorfall tut.

Verwandte Themen