Skills sind Software

Ein KI-Skill wirkt auf den ersten Blick harmlos. Er kann als Markdown-Datei, Sammlung von Regeln oder kleine Anleitung erscheinen: So analysierst du ein Dokument, so baust du eine Präsentation, so prüfst du ein Projekt. Doch ein Skill verändert Verhalten. Er entscheidet, welche Informationen herangezogen werden, welche Werkzeuge erlaubt sind und welche Schritte als normal gelten. Sobald er mit Rechten, Daten oder Automatisierung verbunden wird, muss er wie Software behandelt werden – mit Herkunft, Version, Tests, begrenzten Berechtigungen und einer kontrollierten Freigabe.

Ein Skill ist nicht sein Dateiformat

Ob ein Skill als Textdatei, Konfiguration oder Plugin vorliegt, sagt wenig über seine Wirkung. Entscheidend ist, was ein Agent aufgrund dieser Anweisung tut. Ein Satz kann dazu führen, dass Dateien durchsucht, externe Quellen geöffnet, Befehle ausgeführt oder Ergebnisse veröffentlicht werden. Die Oberfläche bleibt Text, die Folge ist operativ.

Darum reicht eine redaktionelle Prüfung auf Verständlichkeit nicht aus. Ein Skill braucht eine Funktionsbeschreibung: Auslöser, erlaubte Eingaben, erzeugte Outputs, verwendete Werkzeuge, benötigte Rechte und Stoppsignale. Erst diese Sicht macht erkennbar, welche Wirkung tatsächlich installiert wird.

Die nützliche Grundregel lautet: Je näher ein Skill an echten Daten und Veränderungen arbeitet, desto stärker muss er wie ein ausführbares Artefakt geprüft werden. Ein reiner Schreibstil-Hinweis braucht weniger Kontrolle als eine Anleitung, die Dateien verändert oder Nachrichten versendet.

Ausführbares Wissen vergrößert die Angriffsfläche

Ein Skill bündelt Fachwissen und Arbeitsabläufe. Genau das macht ihn wertvoll – und attraktiv für Missbrauch. Wer die Anleitung verändert, kann nicht nur einen Satz verfälschen, sondern viele spätere Ausführungen beeinflussen. Ein kleiner Zusatz kann neue Datenquellen öffnen, Prüfungen überspringen oder Ergebnisse an einen unerwarteten Ort lenken.

Das Risiko steigt mit Wiederverwendung. Ein einmaliger fehlerhafter Prompt betrifft einen Vorgang. Ein kompromittierter Skill kann in vielen Projekten, Sitzungen oder Teams aktiv werden. Seine Reichweite entsteht nicht allein aus Code, sondern aus Vertrauen und Routine.

Sicherheit beginnt deshalb mit einer Bestandsaufnahme. Welche Skills sind aktiv? Woher stammen sie? Wer darf sie ändern? Welche Werkzeuge können sie erreichen? Welche Daten sehen sie? Ohne ein solches Register bleibt ausführbares Wissen unsichtbare Infrastruktur.

Herkunft ist eine technische Eigenschaft

„Aus einer bekannten Quelle“ ist kein ausreichender Vertrauensnachweis. Ein Skill braucht eine nachvollziehbare Herkunftskette: ursprüngliche Quelle, verantwortliche Übernahme, lokale Änderungen, aktuelle Version und Zeitpunkt der letzten Prüfung. Kopien ohne diese Informationen verlieren schnell ihre Identität.

Auch eine vertrauenswürdige Autorin oder ein vertrauenswürdiger Anbieter ersetzt keine Prüfung. Ein Skill kann für eine andere Umgebung geschrieben sein, umfassendere Rechte voraussetzen oder Abhängigkeiten verwenden, die lokal nicht gewünscht sind. Vertrauen ist kontextgebunden: Was in einer isolierten Testumgebung akzeptabel ist, kann in einem produktiven Projekt zu weit reichen.

Bewahre deshalb die unveränderte Ausgangsversion getrennt von der freigegebenen lokalen Fassung. Dokumentiere jede Abweichung. So bleibt prüfbar, was übernommen, entfernt oder verschärft wurde – und spätere Updates überschreiben lokale Sicherheitsentscheidungen nicht unbemerkt.

Anweisungen können selbst zum Einfallstor werden

Prompt-Injection wird häufig nur als Problem fremder Webseiten oder Dokumente verstanden. Doch auch Skill-Dateien können Anweisungen enthalten, die den ursprünglichen Auftrag umdeuten: ignoriere Grenzen, öffne weitere Quellen, gib interne Informationen aus oder führe einen zusätzlichen Schritt aus. Besonders riskant wird es, wenn ein Skill ungeprüfte Inhalte wiederum als Anweisung behandelt.

Ein sicheres Design trennt Steuertext und Arbeitsdaten. Inhalte aus Dokumenten, Webseiten oder Nutzerdateien sind Material, keine neuen Systemregeln. Der Skill sollte ausdrücklich festlegen, dass eingebettete Aufforderungen nicht automatisch befolgt werden. Werden externe Anweisungen benötigt, müssen sie in einem begrenzten, sichtbaren Prüfpunkt landen.

Zusätzlich braucht es Ausgabekontrolle. Geheimnisse, Zugangsdaten, interne Pfade und personenbezogene Informationen dürfen nicht allein deshalb in einem Ergebnis erscheinen, weil sie während der Arbeit zugänglich waren. Zugriff ist keine Veröffentlichungsfreigabe.

Minimale Rechte begrenzen auch gute Skills

Ein Skill sollte nur die Fähigkeiten erhalten, die seine konkrete Aufgabe benötigt. Lesen, Schreiben, Ausführen, Senden und Löschen sind unterschiedliche Rechte. Wer sie pauschal bündelt, macht aus einer hilfreichen Fähigkeit einen unnötig großen Wirkungsraum.

Beginne mit einem isolierten Arbeitsbereich, Beispielmaterial und reversiblen Outputs. Ein Skill zur Analyse benötigt in der ersten Fassung vielleicht nur Leserechte. Ein Skill zur Dokumenterstellung darf in einen festgelegten Ordner schreiben, aber nicht veröffentlichen. Jede zusätzliche Berechtigung braucht eine begründete Aufgabe und einen Test.

Auch zeitliche Begrenzung hilft. Rechte können nur für einen Lauf, ein Projekt oder einen geprüften Schritt gelten. Dauerhafte Vollmachten sind bequem, erschweren aber die Frage, welcher Skill wann welche Wirkung auslösen durfte.

Versionen und Abhängigkeiten bilden eine Lieferkette

Skills stehen selten allein. Sie verweisen auf Vorlagen, Skripte, Bibliotheken, Modelle, Werkzeuge oder weitere Skills. Jede Abhängigkeit kann Verhalten verändern. Ein Update an einer Hilfsdatei kann dadurch einen scheinbar unveränderten Skill anders arbeiten lassen.

Ein verlässlicher Skill nennt seine Abhängigkeiten und die getesteten Versionen. Änderungen werden nicht automatisch in produktive Abläufe übernommen. Sie gelangen zunächst in eine kontrollierte Umgebung, durchlaufen Regressionstests und erhalten erst danach eine Freigabe. Automatische Updates ohne sichtbare Prüfung tauschen Bequemlichkeit gegen unbekanntes Verhalten.

Nicht jedes Update ist verdächtig. Aber jedes Update ist eine Änderung des Systems. Wer Versionen fixiert, Änderungsnotizen liest und Freigaben dokumentiert, kann Aktualität nutzen, ohne Reproduzierbarkeit aufzugeben.

Review, Tests und Vorfälle gehören zum Lebenszyklus

Vor der Freigabe braucht ein Skill mindestens vier Prüfungen: fachliche Richtigkeit, Sicherheitsgrenzen, Verhalten an Gegenbeispielen und Nachvollziehbarkeit seiner Outputs. Tests sollten Normalfall, fehlende Grundlage, manipulierte Eingabe und unerlaubte Wirkung enthalten.

Nach der Freigabe bleibt Beobachtung notwendig. Welche Werkzeuge wurden tatsächlich genutzt? Wo hielt der Skill an? Welche Datei änderte er? Welche unerwartete Ausgabe entstand? Eine kompakte Spur hilft, Fehler nicht nur zu bemerken, sondern ihrem Ursprung zuzuordnen.

Tritt ein Vorfall auf, wird der Skill deaktiviert, seine Reichweite geprüft und die letzte vertrauenswürdige Version wiederhergestellt. Anschließend entsteht aus dem Fehler ein neuer Test. So wächst Sicherheit nicht aus der Behauptung, ein Skill sei geprüft, sondern aus einem gepflegten Lebenszyklus.

Der Skill-Vertrauenspass

Ein kompakter Pass hält Wirkung, Herkunft, Rechte und Wiederherstellung eines Skills an einer prüfbaren Stelle zusammen:

# SKILL-VERTRAUENSPASS

**Zweck und Wirkung**
Welche Aufgabe erfüllt der Skill, was kann er verändern?

**Herkunft**
Quelle, verantwortliche Übernahme, lokale Änderungen, Prüftermin.

**Werkzeuge und Rechte**
Was darf er lesen, schreiben, ausführen, senden oder löschen?

**Daten- und Anweisungsgrenze**
Welche Inhalte sind Material und niemals neue Steueranweisungen?

**Abhängigkeiten**
Welche Vorlagen, Skripte, Modelle oder weiteren Skills werden benötigt?

**Version und Updateweg**
Welche Fassung ist freigegeben, wie werden Änderungen getestet?

**Tests**
Normalfall, Gegenbeispiel, manipulierte Eingabe und unerlaubte Wirkung.

**Stopp und Wiederherstellung**
Wann wird deaktiviert, welche Version gilt als vertrauenswürdig?

Ein guter Skill macht Wissen wiederholbar. Ein vertrauenswürdiger Skill macht zusätzlich seine Wirkung, Herkunft und Grenzen überprüfbar. Genau darin liegt der Unterschied zwischen einer nützlichen Textsammlung und einer belastbaren Fähigkeit: Sie kann nicht nur ausgeführt, sondern auch kontrolliert, gestoppt und sicher weiterentwickelt werden.

Übungsblatt: Prüfe einen Skill wie Software

Wähle einen vorhandenen oder geplanten Skill. Bewerte nicht nur seine Formulierung, sondern die gesamte Wirkungskette von Herkunft bis Wiederherstellung.

1. Wirkung inventarisieren. Liste Auslöser, Eingaben, Outputs, Werkzeuge und mögliche Veränderungen auf. Markiere externe und irreversible Wirkungen.

2. Herkunft und Änderungen sichern. Dokumentiere Quelle, übernommene Version und lokale Anpassungen. Trenne Ausgangsversion und freigegebene Fassung.

3. Rechte und Daten begrenzen. Streiche jedes unnötige Recht. Lege fest, welche eingebetteten Inhalte niemals als Steueranweisung gelten.

4. Vier Tests ausführen. Teste Normalfall, fehlende Grundlage, manipulierte Eingabe und den Versuch einer unerlaubten Wirkung.

5. Update und Vorfall planen. Definiere Freigabeweg, Rückkehrversion, Deaktivierungssignal und die Spur, die nach jedem Lauf erhalten bleibt.