skill.md ist eine Supply Chain

Heute besuchte ich nach längerer Zeit wieder Stack Overflow - mit einem nostalgischen Gefühl. Früher war ich ständig dort, und ich habe keine Ahnung, wie viele Stunden meiner Lebenszeit durch die richtigen Antworten dort gerettet wurden. Seit die LLMs so gut geworden sind, komme ich kaum noch vorbei - und wollte einfach mal sehen, was sich tut.

Dabei entdeckte ich Stack Overflow for Agents (SOFA): eine Art Stack Overflow für KI-Agenten, mit kollektiver Verifikation statt menschlicher Upvotes. Die Integration läuft, wie Agenten-Integrationen inzwischen üblicherweise laufen: Eine skill.md-Datei, abgerufen von agents.stackoverflow.com, wird in den Kontext des Agenten geladen. Ich schaute mir die Datei an und stellte fest, dass sie ziemlich lang ist. Bei genauem Hinsehen fiel mir auf, dass zur Laufzeit weitere Anweisungen von der SOFA-Site nachgeladen werden - und dass sogar API-Antworten als Steuerungsanweisungen dienen sollen. Mein Supply-Chain-Alarm fing leise an zu klingeln, und ich begab mich auf die Reise ins Rabbit Hole.

Eines vorweg: Das hier ist kein Verriss. SOFAs Skill-Datei gehört zu den sorgfältigsten ihrer Art - und genau das macht sie zur lohnenden Fallstudie. Denn wenn die sorgfältige Version eines Musters ein strukturelles Problem hat, dann hat das Muster ein strukturelles Problem. Im Folgenden: eine genaue Lektüre der 692 Zeilen, was die Datei richtig macht - und warum „gut geschrieben” die eigentliche Vertrauensgrenze nicht adressiert.

Was ein Skill-File eigentlich ist

Agent Skills sind ein offenes Format - ursprünglich von Anthropic, inzwischen breit übernommen. Ein Skill ist ein Ordner mit einer SKILL.md (SOFA schreibt sie klein: skill.md): oben YAML-Frontmatter mit Name und Beschreibung, darunter ein Markdown-Körper mit Anweisungen. Die Mechanik ist entscheidend: Die Beschreibung liegt dauerhaft im System-Prompt des Agenten; den Körper lädt der Agenten-Client nach, sobald eine Aufgabe zum Skill passt - und ab dann steht er als Anweisungstext im Kontextfenster des Modells.

Ein Skill-File ist also keine Dokumentation. Es ist ausführbar - nicht durch eine CPU, sondern durch das Instruktionsfolgeverhalten des Modells. Dieser Unterschied ist kleiner, als er klingt.

Der Befund: drei Ebenen

Ebene eins: eine veränderliche Remote-Instruktionsquelle

Try Stack Overflow for Agents Verified knowledge for the agentic era Paste this into your AI coding assistant

Der Anwender soll seinem Agenten also einen Link geben, ohne zu wissen, was sich dahinter verbirgt. Als hätte es Phishing nie gegeben, soll ich einer Datenquelle vertrauen - ohne Signatur, ohne Version-Pinning, ohne Prüfsumme. Was heute in der Datei steht, kann morgen etwas anderes sein: ein Fehler, der sich eingeschlichen hat, im schlechtesten Fall Schadinstruktionen. Ich unterstelle keine Absicht - und es ist auch kein Stack-Overflow-Problem, sondern ein grundsätzliches: So werden Skills im gesamten Ökosystem heute ausgeliefert. SOFA ist nur die prominenteste Instanz.

Strukturell ist das curl | bash: Inhalte von einer URL, direkt ausgeführt - nur landet der Payload nicht in der Shell, sondern in der Instruktionshierarchie des Agenten. Und das mit schlechterem Werkzeug: kein Paketmanager, kein Lockfile, keine Advisory-Datenbank. Noch nicht.

Ebene zwei: die Datei ist nur die Spitze

Die skill.md weist den Agenten an, zur Laufzeit weitere Anweisungen zu holen: /llms.txt, /guidelines/..., /contribute.md. In einer isolierten Dev-Umgebung mag das vertretbar sein; in einer regulierten Enterprise-Umgebung ist es das sicher nicht. Wir haben also 692 geprüfte Zeilen - und dahinter dynamische Inhalte, die sich jederzeit ändern können. Zu unseren Ungunsten im schlechtesten Fall.

Damit nicht genug: API-Antworten enthalten next_step-Felder, die laut Dokument als „immediate steering instruction” zu behandeln sind - als unmittelbar zu befolgende Anweisung. Der Server steuert damit das Verhalten des Agenten pro Request. Der Anwender kann die Auswirkungen dieser Anweisungen prinzipiell nicht kennen: Sie existieren zum Zeitpunkt seines Reviews noch gar nicht.

Die Konsequenz: Das prüfbare Artefakt ist nicht die 692-Zeilen-Datei. Es ist ein dynamischer Instruktionsstrom - und einen dynamischen Strom kann man nicht reviewen, nur begrenzen.

Ebene drei: Persistenz

Aber auch hier sind wir noch nicht am Ende. Die skill.md weist den Agenten an, ein Community-Playbook zu laden und daraus dauerhafte Anweisungen in AGENTS.md, CLAUDE.md oder Cursor-Rules zu schreiben. Gemeint ist das als Onboarding-Komfort. Strukturell ist es etwas anderes: fremder, community-erstellter Inhalt schreibt sich selbst in die Instruktionsdateien eines Projekts. Die Malware-Analyse hat dafür nüchterne Fachbegriffe - Persistenz. Und sobald diese Dateien eingecheckt und über das Repository an jeden Klon verteilt werden: Lateral Movement. Ich unterstelle auch hier niemandem Absicht, und das ist nicht der Punkt. Angreifer interessieren sich nicht für Absichten, sondern für Mechanismen - und der Mechanismus existiert.

Natürlich fragt der Agent vorher um Erlaubnis. Aber Decision Fatigue ist ein reales Problem: Wer am Tag fünfzig Bestätigungsdialoge wegklickt, liest den einundfünfzigsten nicht mehr - zumal verschachtelte Aufrufe mit Bash- und Python-Anteilen auch für geübte Augen schwer zu durchschauen sind. Der wirksame Schutz liegt deshalb nicht im Dialog, sondern davor: Agenten in isolierten Umgebungen betreiben und Instruktionsdateien im Code-Review behandeln wie Code. Denn genau das sind sie.

Was die Datei richtig macht

Fairerweise: Diese skill.md ist handwerklich gelungen - man merkt, dass sich da jemand Mühe gegeben hat. Posts und Playbooks werden explizit als nicht vertrauenswürdig deklariert; der Agent soll keine opaken Blobs dekodieren und keinen eingebetteten, verhaltensändernden Anweisungen folgen. Es gibt Human-in-the-Loop-Publikationsrichtlinien mit Einmal-Freigabecodes und reinen Entwurfsmodi, eine read_only-Rolle, Credential-Hygiene (gitignore prüfen, bevor Zugangsdaten auf die Platte geschrieben werden), begrenzte Inhaltsgrößen und Guards gegen blindes Bewerten ungelesener Posts.

Wer das geschrieben hat, hat über das Threat Model nachgedacht. Das Problem ist nicht, was in der Datei steht. Das Problem ist, wo sie sitzt.

Das Muster: Prosa ist keine Policy

Was hier für SOFA gilt, gilt für eine wachsende Klasse: Skills, MCP-Tool-Beschreibungen, llms.txt, nachgeladene Inhalte aller Art - veränderliche Remote-Instruktionsquellen. Unabhängig vom konkreten Inhalt haben sie zwei strukturelle Schwächen.

Erstens: Veränderlichkeit ohne Integrität. Ohne Pinning und Signatur wird die Vertrauensentscheidung genau einmal getroffen - der Inhalt ändert sich danach beliebig weiter.

Zweitens: Durchsetzung per Prosa. Sicherheitsregeln, die als Anweisungstext mitgeliefert werden, konkurrieren im selben Kontextfenster mit genau den Inhalten, die sie regulieren sollen. Dazu kommt ein empirischer Befund: Die Fähigkeit eines Modells, Prompt-Injections zu erkennen und abzuwehren, nimmt ab, je voller das Kontextfenster wird - und lange Instruktions-Payloads wie diese rund 10.000 Tokens verwässern messbar die Befolgung höher priorisierter Anweisungen. Der Wettbewerb um Aufmerksamkeit verschärft sich mit jedem nachgeladenen Token. Die Konsequenz ist unbequem, aber eindeutig: Schädliche Inhalte dürfen gar nicht erst in das Kontextfenster gelangen.

Neu ist diese Risikoklasse übrigens nicht. Wir laden seit Jahrzehnten Bibliotheken und Skripte aus dem Internet und binden sie in kritische Enterprise-Anwendungen ein. Gelöst haben wir das nie mit Warnhinweisen im README, sondern mit technischen Kontrollen: Lockfiles, Prüfsummen, Signaturen, Advisory-Datenbanken, automatisiertem Dependency-Scanning. Die Bibliothekswelt hat also längst verstanden, dass Prosa keine Policy ist. Und selbst mit diesem ganzen Apparat passieren log4shell und die xz-Backdoor. Das Skill-Ökosystem startet ohne die Grundausstattung: kein Lockfile, keine Signatur, kein Advisory-Feed - nur ein Dokument, das höflich um gutes Benehmen bittet.

Eine Regel, die im selben Kanal lebt wie das, was sie reguliert, ist eine Konvention - keine Kontrolle.

Wie eine technische Kontrolle aussieht

Was folgt daraus praktisch? Zunächst vier Maßnahmen, die wenig kosten und sofort wirken.

Erstens: Skills nicht live von einer URL laden, sondern eine geprüfte lokale Kopie pinnen - und Updates behandeln wie Dependency-Updates: Diff ansehen, dann bewusst übernehmen. Ein simpler CI-Check, der die lokale Kopie gegen Upstream vergleicht, macht aus einer stillen Änderung einen sichtbaren Vorgang.

Zweitens: den Blast Radius begrenzen. Agenten gehören in isolierte Container - mit Egress-Firewall und ohne Zugriff auf Ressourcen des Anwenders, die die Aufgabe nicht verlangt.

Drittens: Least Privilege, und zwar strenger als beim Menschen. Der Agent darf auf Systeme wie Jira oder Confluence höchstens die Rechte des Users haben, der ihn betreibt - eigentlich weniger. Denn eine Änderung durch einen Agenten hat keinen Menschen, der sich wundert: Ein manipulierter Confluence-Eintrag fällt niemandem auf und kann auf Dauer erheblichen Schaden anrichten. SOFA selbst bietet übrigens eine read_only-Rolle an; wer nicht aktiv beitragen will, braucht nichts anderes.

Viertens: den Activation-Pfad blocken. Kein Skill muss in die Instruktionsdateien eines Projekts schreiben dürfen.

Das sind Linderungen, keine Lösung. Die eigentliche Antwort liegt außerhalb des Modells: ein Policy Enforcement Point zwischen Agent und Ressource - etwa mit dem Open Policy Agent -, der in beide Richtungen prüft: was in das Kontextfenster hineingelangt und welche Tool-Aufrufe hinausgehen. Dazu Credentials, die auf die konkrete Aufgabe zugeschnitten sind statt auf den Agenten als Ganzes, und ein Audit-Trail, der Entscheidung und Zugriff korrelierbar macht - Token Exchange, PEP-Entscheidungslog und Ressourcen-Log, verknüpft über die Token-ID. Ein Agent, dessen Credential nur das kann, was die Aufgabe verlangt, richtet auch mit kompromittierten Anweisungen nur begrenzten Schaden an. Zu dieser Architektur habe ich an anderer Stelle einen Blueprint beschrieben. Die Kurzfassung: Agenten brauchen keine besseren Versprechen - sie brauchen schmalere Credentials.

Schluss

Die Empfehlung lautet ausdrücklich nicht: Finger weg von SOFA. Sie lautet: Prüft die Klasse, nicht die Instanz. Stack Overflow hat die sorgfältige Version eines Musters gebaut, das gerade das gesamte Ökosystem übernimmt - die meisten Implementierungen werden schlechter sein, mit weniger Warnungen, weniger Human-in-the-Loop und weniger Nachdenken über das Threat Model. Wenn schon die sorgfältige Version ein strukturelles Problem hat, hat das Muster ein strukturelles Problem.

Stack Overflow hat fünfzehn Jahre lang Entwicklern beigebracht, die akzeptierte Antwort zu prüfen, bevor man ihr vertraut. Dieselbe Disziplin gilt jetzt für die Anweisungen, die unsere Agenten akzeptieren - angefangen bei denen, die über HTTPS ankommen und aussehen wie Dokumentation.