Agent Skills prüfen, bevor der Agent sie ausführt

Ein Coding-Agent darf auf dem Rechner meistens viel: Dateien lesen, Befehle in der Shell ausführen, Pakete installieren, Anfragen ins Netz schicken. Ein Skill nutzt diese Rechte. In Claude Code kann er sich zusätzlich über das Feld allowed-tools im Kopf der SKILL.md Werkzeuge freigeben, die dann ohne Rückfrage laufen. Laut Dokumentation gilt das auch in Ordnern, denen nie ausdrücklich vertraut wurde. Die Freigabe gilt für den Schritt, in dem der Skill läuft, und deny-Regeln in den eigenen Einstellungen gehen vor. Quelle: Claude Code, Skills.

Steht in einer Datei die Anweisung, vor dem eigentlichen Schritt ein Setup-Skript herunterzuladen, führt der Agent das im Zweifel aus. Er hält es für einen Teil der Aufgabe.

Anthropic formuliert die Empfehlung in den Sicherheitshinweisen zu Agent Skills deutlich: Skills nur aus vertrauenswürdigen Quellen nutzen, also selbst geschrieben oder von Anthropic. Alles andere soll vor dem Einsatz gründlich geprüft werden, und zwar alle Dateien. Die Installation eines Skills sei wie die Installation von Software zu behandeln. Quelle: Agent Skills, Security considerations.

Wie das in der Praxis aussieht, hat Zenity Labs im August 2026 dokumentiert. Auf skills.sh, dem Skill-Verzeichnis von Vercel, tauchten Anfang Juli Skills auf, die zunächst wörtliche Kopien echter Skills des Open-Source-Projekts Paperclip waren. Dazu gehörten eine nachgemachte GitHub-Organisation und die Domain getpaperclipp.com, mit einem p mehr als das Original.

Am 11. Juli kam in sieben Skill-Pfaden eine neue Datei setup-installation.md hinzu. Sie wies den Agenten an, ein Skript von dieser Domain zu laden und auszuführen. Das Skript suchte über 100 Pfade nach SSH-Schlüsseln, Cloud-Zugangsdaten, Git- und npm-Tokens, .env-Dateien und CI-Konfigurationen und schickte die Funde an den Server der Angreifer.

Bis zur Sperrung am 2. August zählte skills.sh mehr als 1,7 Millionen Installationen dieser Skill-Familie. Zenity betont, dass es sich um aufsummierte Installationen handelt, nicht um einzelne Betroffene. Quelle: Attackers Target Agents via The Skill Supply Chain.

Drei Dinge nehme ich daraus mit. Die Skills standen den ganzen Juli in den Trends des Verzeichnisses, Beliebtheit hat also nichts geschützt. Die Anleitungsdateien waren bis zum 10. Juli unauffällig; wer sie da geprüft und danach automatisch aktualisiert hat, hatte ab dem 11. Juli trotzdem die schädliche Fassung. Und die Anweisung stand in einer Nebendatei, auf die verwiesen wurde, während die SKILL.md weiter eine legitime Aufgabe beschrieb.

Wo ein solcher Skill ausgeführt wurde oder sich das nicht ausschließen lässt, empfiehlt Zenity, den Rechner als kompromittiert zu behandeln und alle erreichbaren Zugangsdaten auszutauschen.

1. Wer hat den Skill veröffentlicht, und heißt er wirklich so?

Viele schädliche Skills tragen Namen, die einem bekannten Skill oder Anbieter zum Verwechseln ähnlich sind. Im Sicherheitsjargon heißt das Typosquatting. Die OWASP führt es in ihren Agentic Skills Top 10 unter dem ersten Risiko, den schädlichen Skills. Quelle: OWASP Agentic Skills Top 10.

Ich vergleiche deshalb Organisation, Repository und Domain mit dem, was auf der offiziellen Website des Projekts steht. Sterne, Downloadzahlen und ein Label wie „verified“ beweisen dabei wenig. Stammt ein Skill aus einer Community-Sammlung, suche ich zuerst das Original.

2. Lädt der Skill etwas von außen nach?

Ein Skill kann sauber aussehen, weil der eigentliche Code woanders liegt. Typische Stellen sind curl … | bash, npx oder pip install mit unbekannten Paketen oder ein Verweis auf eine URL, deren Inhalt der Agent als Anweisung liest.

Bei jedem Download hilft es, vorher zu klären:

• Was wird geladen, und wofür braucht der Skill das?

• Wer kontrolliert die Quelle, und kann sich ihr Inhalt später ändern?

• Liest der Agent das Geladene als Anweisung, oder führt er es als Code aus?

• Hat mein Scan diese Quelle überhaupt erfasst?

Die letzte Frage ist die unangenehmste. Ein Scanner prüft, was im Ordner liegt. Was erst zur Laufzeit geladen wird, sieht er nicht.

3. Gibt es versteckte Anweisungen?

Anweisungen am Ende langer Dateien, in HTML-Kommentaren, als Base64 kodiert oder in unsichtbaren Unicode-Zeichen sind kaum je ein Versehen. Dasselbe gilt für Abschnitte mit Überschriften wie „IMPORTANT“ oder „Prerequisites“, die etwas verlangen, das mit der beschriebenen Aufgabe nichts zu tun hat.

Ein schneller erster Blick über alle Dateien eines Skill-Ordners, mit ripgrep, weil es unter macOS und Linux gleich läuft. Die Option -uu ist wichtig: Ohne sie überspringt ripgrep versteckte und per .gitignore ausgeschlossene Dateien, also genau die Stellen, an denen sich etwas verstecken lässt.

# Downloads, Ausführung, Kodierung
rg -n -uu 'curl|wget|base64|eval|exec\(|\| *(ba)?sh|npx |pip install' ./mein-skill

# HTML-Kommentare und unsichtbare Zeichen
rg -n -uu '<!--|[\x{200B}-\x{200F}\x{2060}\x{FEFF}]' ./mein-skill

# Zugriffe auf Zugangsdaten und vorab freigegebene Werkzeuge
rg -n -uu '\.ssh|\.aws|\.env|id_rsa|token|credential|allowed-tools' ./mein-skill

Ein Treffer ist noch kein Beweis. Ein Skill zum Einrichten von Deployments liest zu Recht Umgebungsvariablen. Dann lohnt es sich, die Stelle zu lesen.

4. Greift der Skill auf Daten außerhalb seiner Aufgabe zu?

Ein Skill, der PDFs zusammenfasst, braucht keinen Zugriff auf ~/.ssh. Ein Skill für Präsentationen muss weder Tokens ausgeben noch Unternehmensdokumente außerhalb des Projekts lesen.

Ich prüfe deshalb, welche Pfade, Umgebungsvariablen und Dienste ein Skill anspricht und welche Werkzeuge er sich in allowed-tools freigibt. Das vergleiche ich mit dem, was er laut Beschreibung tut. Jede Abweichung muss sich erklären lassen.

5. Drängt der Skill den Agenten, Prüfungen zu umgehen?

Am eindeutigsten ist ein Skill, der den Agenten anweist, Sicherheitsabfragen auszuschalten, Fehlermeldungen zu ignorieren, Bestätigungen zu überspringen oder dem Nutzer bestimmte Schritte zu verschweigen. Für solche Anweisungen gibt es in einem nützlichen Skill keinen Grund.

Dazu gehören auch Hinweise, den Agenten mit --dangerously-skip-permissions oder ohne Sandbox zu starten, „damit der Skill funktioniert“.

Im Lauf des Jahres 2026 sind mehrere Werkzeuge erschienen, die Skills vor der Installation untersuchen. Die vier folgenden sind kostenlos. Bitdefender und der Skill Inspector von Snyk laufen im Browser, SkillSpector von NVIDIA und der Skill Scanner von Cisco als Open Source auf dem eigenen Rechner. Stand der Angaben: November 2026.

Bitdefender AI Skills Checker

Eine kostenlose Website: Link zu einem Skill einfügen oder ein Archiv hochladen, das Ergebnis reicht von „Seems clean“ bis „High risk“. Unterstützt werden unter anderem skills.sh, OpenClaw, LobeHub und GitHub-Repositorys. Bitdefender bietet das Werkzeug zusätzlich als Skill an, der andere Skills prüft:

npx skills add bitdefender/agent-skill-scanner

Link: Bitdefender AI Skills Checker

Snyk Agent Scan mit Skill Inspector

Der Skill Inspector ist die kostenlose Weboberfläche von Snyk Agent Scan. Er nimmt eine Marktplatz-URL, ein GitHub-Repository oder einen lokalen Ordner per Drag-and-drop. Geprüft werden unter anderem Prompt-Injection, schädlicher Code, verdächtige Downloads, fest eingetragene Zugangsdaten und Zugriffe auf Finanzsysteme. Quelle: Snyk Labs, zum Werkzeug: Skill Inspector.

Für Automatisierung und CI gibt es die Kommandozeile. Sie braucht ein Token aus dem Snyk-Konto:

export SNYK_TOKEN=…
uvx snyk-agent-scan@latest ~/pfad/zu/mein-skill/SKILL.md

Die Inhalte werden dabei an die API von Snyk geschickt. Link: snyk/agent-scan auf GitHub

NVIDIA SkillSpector

SkillSpector ist Open Source (Apache 2.0). Er kombiniert statische Analyse, YARA-Regeln und eine Prüfung der Abhängigkeiten gegen bekannte Sicherheitslücken in der Datenbank OSV. Laut README prüft standardmäßig zusätzlich ein Sprachmodell und bekommt dafür Dateiinhalte. Mit --no-llm bleibt es sicher bei der lokalen Analyse. Er akzeptiert einen Ordner, eine einzelne SKILL.md, ein ZIP-Archiv oder eine Git-URL und gibt auch SARIF aus, das Format für GitHub Code Scanning.

git clone https://github.com/NVIDIA/SkillSpector.git
cd SkillSpector
uv venv .venv && source .venv/bin/activate
make install

# ohne Sprachmodell, nur lokale Analyse
skillspector scan ./mein-skill/ --no-llm

# Git-URL, Bericht für GitHub Code Scanning
skillspector scan https://github.com/user/mein-skill --format sarif --output report.sarif

Link: Dokumentation bei NVIDIA

Cisco Skill Scanner

Der Skill Scanner von Cisco AI Defense ist ebenfalls Open Source. Er verbindet Musterregeln, eine Analyse der Abhängigkeiten und optional ein Sprachmodell als Gutachter. Es gibt einen fertigen GitHub-Workflow, mit dem sich Skills im Pull Request prüfen lassen.

pip install cisco-ai-skill-scanner

# nur Regeln, für einen ersten Test
skill-scanner scan ./mein-skill

# mit Sprachmodell; braucht einen API-Schlüssel in SKILL_SCANNER_LLM_API_KEY
skill-scanner scan ./mein-skill --use-llm --policy balanced --fail-on-severity high

Nach Ciscos eigener Dokumentation erkennen die Regeln allein nur rund 8 % der schädlichen Skills. Für Skills von Dritten lohnt sich die Prüfung mit Sprachmodell deshalb. Quelle: Quick Start.

Wohin der Skill beim Scannen geht

Bei den beiden Webwerkzeugen, bei der Kommandozeile von Snyk und bei jeder Prüfung mit Sprachmodell verlässt der Skill den eigenen Rechner. Für öffentliche Skills ist das unproblematisch.

Für interne Skills mit Kundennamen, Prozessbeschreibungen oder Pfaden aus dem eigenen Netz nehme ich SkillSpector mit --no-llm oder den Cisco Skill Scanner ohne --use-llm. SkillSpector fragt dann nur noch Namen und Versionen der Abhängigkeiten bei OSV ab. Soll trotzdem ein Sprachmodell prüfen, dann eines, dessen Datenverarbeitung vertraglich geregelt ist. Was dabei zu beachten ist, steht im Artikel KI DSGVO-konform im Unternehmen nutzen.

Am 11. November 2026 haben wir die Scanner selbst ausprobiert. Geprüft haben wir die vier Skills aus unserem öffentlichen Skill-Repository und vier präparierte Testskills nach dem Muster von Paperclip. Die Testskills fassen angeblich PDFs zusammen und enthalten jeweils eine schädliche Anweisung. Die Domain darin ist example.invalid, ausgeführt wurde nichts.

• a: Der Download-Befehl steht in einer Nebendatei setup-installation.md, mit der Bitte, ihn still auszuführen und nicht zu erwähnen.

• b: Dieselbe Anweisung in derselben Nebendatei, aber nur als Prosa, ohne Befehl.

• c: Der Befehl steht direkt in der SKILL.md.

• d: Ein beiliegendes Skript lädt Code nach und schickt ~/.ssh/id_rsa an die fremde Domain.

Cisco Skill Scanner: ein Treffer von vier

Wir haben ihn ohne Sprachmodell laufen lassen, mit Regeln und Verhaltensanalyse. Die Testskills a, b und c galten danach als sicher, gemeldet wurde nur die fehlende Lizenzangabe. Bei d meldete er „Tool Chaining Abuse“ mit mittlerer Schwere, das Gesamturteil blieb trotzdem „sicher“. Nach Ciscos eigener Angabe überrascht das nicht. Den Modus mit Sprachmodell haben wir ausgelassen, weil er einen API-Schlüssel braucht und die Inhalte an einen Anbieter schickt.

Für unsere vier Skills brauchte er vier bis fünf Sekunden und meldete nur fehlende Lizenzangaben. Aufschlussreicher war, was fehlte: Den Skill ship hat er gar nicht geprüft. Im Kopf seiner SKILL.md steht ein Doppelpunkt mitten in einem Satz, und damit ist der Block kein gültiges YAML. Der Scanner führte ship nur in einer Liste übersprungener Skills, die Zusammenfassung sprach von drei geprüften und drei sicheren Skills. Nach jedem Lauf lohnt deshalb zuerst der Blick in diese Liste. Den Fehler in ship haben wir noch am selben Tag behoben. Seitdem prüft eine automatische Kontrolle im Repository bei jeder Änderung, ob der Kopf jeder SKILL.md gültiges YAML ist.

Bitdefender AI Skills Checker: drei Treffer von vier

Unsere vier Skills bewertete der Checker als „Seems clean“, ohne Befund, und las dabei auch die mitgelieferten Skripte. Testskill a stufte er als „High risk“ ein, mit fünf Befunden. Darunter war die Aufforderung, die Ausführung vor dem Nutzer zu verbergen. c bekam „High risk“ mit vier Befunden, d „High risk“ mit acht, darunter den Zugriff auf den SSH-Schlüssel.

Bei b widersprach sich das Ergebnis selbst. Die Zusammenfassung beschrieb die Anweisung zutreffend als Versuch, fremden Code nachzuladen und auszuführen. Das Urteil lautete trotzdem „Seems clean“, mit null Befunden. Wer nur auf das Urteil schaut, übersieht das. Die Zusammenfassung zu lesen, dauert eine halbe Minute.

Snyk und SkillSpector: kein Ergebnis

Der Skill Inspector von Snyk brach die Analyse unseres Skills zweimal mit „Analysis could not be completed“ ab. Auch das Beispiel, das die Seite selbst anbietet, lieferte nach 30 Sekunden noch kein Ergebnis. Bei SkillSpector brach uv sync auf unserem Mac ab, die Meldung verwies auf die Abhängigkeit yara-python. Den Weg über make install aus der Anleitung haben wir nicht mehr versucht. Das kann an unserer Umgebung oder an diesem Tag gelegen haben, weiter verfolgt haben wir es nicht.

Was der Test zeigt

Keiner der beiden Scanner, die ein Ergebnis lieferten, hat alle vier Testskills erkannt. Bitdefender fand drei von vier, Cisco ohne Sprachmodell nur das Skript, und damit nichts, was Bitdefender übersehen hätte. Die Anweisung in Prosa (b) stufte keiner als Risiko ein, obwohl ein Agent sie genauso als Arbeitsauftrag liest wie einen Befehl. Auch die rg-Muster oben finden b nicht.

Wer die Dateien selbst liest, erkennt b an den Fragen 2 und 5: Der Skill lädt etwas nach und will es verschweigen. Für mich heißt das: Der Scanner zeigt, wo ich zuerst hinsehe. Gefunden hätte ich b nur beim Lesen.

Alle vier Werkzeuge prüfen den Stand, der ihnen vorliegt. Im Fall Paperclip hätte ein Scan der Anleitungsdateien vor dem 11. Juli nichts gefunden.

Dazu kommen Angriffe, die sich auf mehrere Dateien verteilen: eine unauffällige SKILL.md, ein Hilfsskript, das für sich harmlos aussieht, und eine Referenzdatei, die beides verbindet. Musterbasierte Prüfungen sehen in jeder Datei einzeln nichts Auffälliges.

Umgekehrt melden Scanner auch Dinge, die im Zusammenhang normal sind. Eine Studie vom März 2026 hat Skills mehrerer Marktplätze untersucht: Je nach Marktplatz stuften die Scanner bis zu 46,8 % der Skills als schädlich ein. Mit dem Kontext des zugehörigen Repositorys blieben 0,52 % verdächtig. Quelle: Context Matters: Repository-Aware Security Analysis of the Agent Skill Ecosystem.

Jeden Befund sehe ich mir deshalb im Code an. Die Entscheidung trifft kein Scanner: Er sagt mir, wo ich zuerst lesen soll, nicht, ob ich lesen muss.

Skills aus fremden Repositorys gehören auf einen bestimmten Commit, nicht auf „latest“ aus einem Verzeichnis. Projekt-Skills liegen bei uns versioniert unter .claude/skills/. Ein Update ist so ein Diff, der durch denselben Pull Request läuft wie jede Codeänderung. Dabei werden alle Dateien gelesen. Gerade Skripte und Referenzen werden beim Durchsehen gern übersprungen.

Begrenzen lässt sich auch der Agent selbst. In Claude Code lassen sich Lesezugriffe auf sensible Pfade in den Einstellungen sperren:

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(./.env*)"
    ]
  }
}

Das hält den Agenten davon ab, diese Dateien selbst zu lesen. Ein Skript, das er startet, liest sie trotzdem, und genau so lief Paperclip ab. Quelle: Claude Code, Permissions.

Weiter reicht die Sandbox von Claude Code. Sie ist standardmäßig aus und wird mit /sandbox eingeschaltet. Dann laufen Shell-Befehle und alles, was sie starten, unter einer Begrenzung auf Ebene des Betriebssystems. Ins Netz kommen sie nur über einen Proxy, der jede Domain prüft: Was nicht freigegeben ist, muss bestätigt werden, und wer mit --dangerously-skip-permissions arbeitet, hebt auch diese Sperre auf. Ein Skript wie das von Paperclip könnte seine Funde also nicht mehr unbemerkt verschicken. Lesen darf es Dateien wie ~/.ssh aber weiterhin, bis das in den Sandbox-Einstellungen gesperrt ist (filesystem.denyRead). Hooks und MCP-Server laufen außerhalb der Sandbox.

Neue Skills gehören zuerst in einen Container oder eine Sandbox ohne echte Zugangsdaten. So zeigt sich, was ein Skill tatsächlich tut, bevor er im Projekt mit Kundendaten läuft.

Für die Abläufe, die uns wichtig sind, schreiben wir eigene Skills. Sie liegen öffentlich bei unseren Skills für KI-Agenten. Auch für sie gilt, was hier steht: erst lesen, dann installieren.

Ist ein verdächtiger Skill bereits gelaufen, reicht Löschen nicht. Alle Schlüssel und Tokens, die der Agent oder ein von ihm gestartetes Skript erreichen konnte, werden ausgetauscht.

Ein Skill ist in Sekunden installiert. Die Prüfung dauert länger. Sie ist trotzdem der günstigere Teil.