Bei der Installation war es harmlos: Fingerabdrücke für deine Agent-Skills


Vor drei Monaten hast du einen PDF-Skill installiert. Er konvertiert PDFs noch immer einwandfrei – nur liegt im Verzeichnis jetzt ein fetch_helper.sh, das es damals nicht gab, und in SKILL.md ist eine Zeile dazugekommen, die ein Skript von einer unbekannten IP-Adresse nachlädt. Der Skill-Marketplace hat den Skill genau einmal geprüft: zum Zeitpunkt der Veröffentlichung. Seitdem liegen diese Dateien auf deiner Festplatte, wo das Upstream-Repository, ein Auto-Update-Skript oder ein einziger unbedachter git pull sie umschreiben kann. skill-integrity gibt es genau für dieses Zeitfenster: Es bewertet keine Inhalte, es sagt dir nur, welche Bytes sich bewegt haben.

„Ich habe es installiert, also ist es sicher“ ist eine Illusion

Ein Agent-Skill ist ein Ordner – eine SKILL.md plus ein paar Skripte und Assets. Hermes liest sie aus ~/.hermes/skills/, Claude Code aus ~/.claude/skills/. Es gibt keine Signaturprüfung und keine Versionssperre. Sicherheitsleute nennen die daraus entstehende Angriffsklasse Rug-Pull: bei der Installation harmlos, später still umgeschrieben, sobald der Skill dein Vertrauen gewonnen hat – ein zusätzlicher ausgehender Aufruf, eine ausgetauschte Download-URL, ein Skript, das deine Umgebung ausliest.

Genau zwei Eigenschaften solcher Änderungen sind es, die Hashing zuverlässig erwischt: Sie verändern immer die Bytes der Datei, und sie betreffen meist nur eine Handvoll Dateien.

Das kleinste nützliche, was es tut

skill-integrity berechnet für jede Datei in jedem Skill-Verzeichnis einen SHA-256, legt das Ergebnis als Snapshot-Manifest ab und berechnet bei jeder Prüfung neu, um dann zu vergleichen:

skills scanned: 23  (snapshot taken 2026-10-10T21:44:32+0800)

[~] pdf-extractor — MODIFIED
    changed: SKILL.md
    added:   fetch_helper.sh

1 skill(s) changed since snapshot. Review diffs before trusting them.

Details, die man kennen sollte:

  • Standardmäßig scannt es ~/.hermes/skills und ~/.claude/skills und hält fest, welche Verzeichnisse ein Snapshot abgedeckt hat – spätere check-Läufe übernehmen diese Liste, damit ein abweichendes Verzeichnis nicht eine Wand aus falschen „entfernt“-Einträgen erzeugt.
  • Dateien über 512KB werden übersprungen, ebenso __pycache__, node_modules und .git. Wie viele übersprungen wurden und welche pro Skill, wird immer ausgegeben, nie versteckt.
  • Ein Skill-Verzeichnis, in das nicht hineingelesen werden kann, wird als Befund gemeldet, niemals als sauberer leerer Scan – ein unlesbarer Skill ist genau der Ort, an dem sich eine Manipulation verstecken würde.
  • Die Exit-Codes haben Bedeutung: 0 sauber, 1 Befunde, 2 noch kein Snapshot oder Nutzungsfehler. --no-fail-on-change erzwingt 0, solange du das Werkzeug noch testest.
  • Das Manifest hat den Modus 0600, bleibt lokal, null Netzwerkaufrufe.

Installieren, dann die Baseline setzen

Es steht im kuratierten Katalog (skill-integrity, Community-Tier, erfordert Hermes >= 0.21.6). Wenn dein Build den Eintrag im Katalog führt, installiere per Namen:

hermes plugins install skill-integrity
hermes plugins enable skill-integrity

Falls dein Katalog diesen Eintrag noch nicht kennt, installiere aus dem Repository so, wie es die README beschreibt:

git clone https://github.com/ZidoCode/skill-integrity ~/.hermes/plugins/skill-integrity
hermes plugins enable skill-integrity

Dann tue das eine, was alle vergessen – eine Baseline setzen, sonst hat die Prüfung nichts zum Vergleichen und bleibt für immer stumm:

/skill-integrity snapshot   # Baseline aufzeichnen, die der stündliche Hook liest
/skill-integrity check      # Diff auf Dateiebene gegen den Snapshot
/skill-integrity show       # Zusammenfassung des Snapshots

Du kannst es auch eigenständig als einzelne Datei ohne Abhängigkeiten ausführen (Python 3.8+):

python3 skill_integrity.py snapshot
python3 skill_integrity.py check --json

Beide Wege halten ihren Zustand an unterschiedlichen Orten: Das Plugin schreibt ~/.hermes/plugin-data/skill-integrity/manifest.json, das Standalone-CLI nutzt standardmäßig ~/.skill-integrity/manifest.json. Richte das CLI mit --state-dir auf den Zustand des Plugins:

python3 skill_integrity.py --state-dir ~/.hermes/plugin-data/skill-integrity check --json

Lass den Agenten seine eigenen Skills überwachen

Das Plugin registriert einen pre_llm_call-Hook, der etwa stündlich läuft und nur die Namen geänderter Skills in den Kontext des Agenten einspeist. Saubere Läufe sagen nichts, also bekommst du weder Rauschen noch ein falsches Gefühl von Sicherheit.

Lieber ein externer Timer? Ein Cron-Eintrag tut es auch:

0 */12 * * * python3 ~/skill-integrity/skill_integrity.py check --json >> ~/.skill-integrity/checks.log

Entscheide, wo dieses Log liegt und wer es lesen darf; die Hinweise zu Session-Grenzen sind ein guter Einstieg in diese Art von Hygiene.

Die Grenzen, zu denen es ehrlich ist

Solche Werkzeuge werden gefährlich, wenn man sie für ein Sicherheitszertifikat hält, deshalb benennt die README die Grenzen – und sie sind es wert, wiederholt zu werden:

  • Hashes beweisen geänderte Bytes, nicht Absicht. Ein legitimes Upstream-Update und ein bösartiges Umschreiben sehen identisch aus. Du bekommst den Auslöser und die Dateiliste; den Diff zu lesen ist deine Hälfte des Vertrags.
  • Es schreibt historische Snapshots nicht neu. Wer Schreibzugriff hat, kann einfach über die eigenen Spuren hinweg einen neuen Snapshot anlegen – der Snapshot ist bewusst für den Agenten beschreibbar.
  • Bösartiger Inhalt in einer unveränderten Datei? Nicht abgedeckt. Das ist die Aufgabe von Content-Scanning.
  • Es ist ein Inventar-Integritätswerkzeug, kein Antivirus. Dateien über 512KB und Symlinks sind blinde Flecken – gezählt, aber nicht verfolgt.

Behandle es also als Anlass für eine Routineprüfung, nicht als Metalldetektor.

Eine Routine, die tatsächlich trägt

  1. Snapshot direkt nach der Installation von Skills. Eine Baseline, die du eine Woche später ziehst, ist eine Baseline der Änderungen von jemand anderem.
  2. Nach jedem Skill-Upgrade oder Upstream-Pull prüfen, den Diff ansehen, dann neu snapshotten.
  3. Wenn ein Befund kommt, in dieser Reihenfolge vorgehen: den Diff lesen und bestätigen, dass er nicht von dir stammt; fragen, worauf der Skill zugreifen kann (Dateien? Netzwerk? Env-Variablen?); im Zweifel deaktivieren und das Verzeichnis wegschieben; wenn er Zugriff auf Zugangsdaten gehabt haben könnte, diese Schlüssel rotieren, wie im Playbook zur Credential-Hygiene beschrieben.
  4. In Setups mit mehreren Profilen leitet das Plugin Skill- und Zustandsverzeichnisse aus get_hermes_home() ab, sodass auch Nicht-Standard-Profile abgedeckt sind – aber jedes Profil führt seinen eigenen Snapshot.

Für das weitere Ökosystem lohnt ein Blick darauf, wie der Plugin-Katalog funktioniert, und auf die Referenz zu hermes plugins. Derselbe Autor liefert außerdem einen Prozess-Janitor und ein Security-Ledger; die gemeinsame Idee ist, Rechenschaft darüber abzulegen, was ein Agent zurücklässt.