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.