Ein Skill ist Code, und Code braucht einen Kontrollpunkt

Ein Skill ist Code, und Code braucht einen Kontrollpunkt

NVIDIA hat diese Woche ein Tool namens SkillSpector als Open Source veröffentlicht. Seine Aufgabe ist eng und längst überfällig: Skills von KI-Agenten auf Sicherheitsprobleme zu prüfen, bevor ein Agent sie lädt. Das Projekt bringt die Erkennung von 64 Schwachstellenmustern mit, eine Zahl, bei der es sich lohnt, kurz innezuhalten, denn sie bedeutet, dass sich jemand hingesetzt und die Wege aufgelistet hat, auf denen ein Skill schiefgehen kann.

Parallel dazu veröffentlichte Cloudflare einen Sicherheitsaudit-Skill, der mehrphasige Audits gegen eine Codebasis ausführt und maschinenlesbare Befunde ausgibt, und GitHub beschrieb einen kontextbewussten Klassifikator zur Erkennung von Geheimnissen, der die gewichtete Akzeptanz echter Befunde um 11,5 Prozent erhöhte und gleichzeitig die mediane Scanzeit um 86 Prozent senkte. Drei verschiedene Teams, drei verschiedene Blickwinkel, dieselbe Schlussfolgerung: Die Ebene, auf der Agenten ihre Anweisungen erhalten, ist Infrastruktur geworden, und Infrastruktur wird auditiert.

Was ein Skill eigentlich ist

Das Wort "Skill" lässt das Ganze weicher klingen, als es ist. Ein Skill ist keine Einstellung. Er ist ein Bündel von Anweisungen und sehr oft Skripten, Vorlagen und Tool-Definitionen, die ein Agent liest und mit den ihm gewährten Berechtigungen befolgt.

Der letzte Teilsatz ist das Sicherheitsmodell in einem Satz. Ein Skill braucht keinen Exploit, denn er bricht nicht ein. Er wird hereingebeten, bekommt die Schlüssel gereicht und wird um Hilfe gebeten. Sind seine Anweisungen bösartig oder bloß schlampig, wird der Agent sie ausführen, als wären sie deine eigene Absicht, denn soweit er das beurteilen kann, sind sie es.

Das ist dasselbe Problem, mit dem Paketmanager vor Jahrzehnten konfrontiert waren, und es wurde auf dieselbe Weise gelöst: indem man annimmt, dass die Lieferkette feindlich ist, und Kontrollpunkte darin einbaut. Das Agenten-Ökosystem steht in diesem Prozess noch am Anfang, weshalb ein Projekt wie SkillSpector weit mehr zählt, als seine Sternenzahl vermuten lässt.

Warum 64 Muster die interessante Zahl ist

Eine Liste von 64 Schwachstellenmustern ist eine Taxonomie, und Taxonomien sind die Art, wie ein Feld reift. Bevor man eine hat, ist jeder Vorfall eine Überraschung. Danach werden Vorfälle zu Fällen bekannter Klassen, was bedeutet, dass man sie testen, verfolgen und schließlich wegkonstruieren kann.

Einige dieser Klassen sind aus gewöhnlicher Software vertraut: unsichere Shell-Befehle, nicht validierte Eingaben, Anmeldedaten, die in Dateien geschrieben werden, die sie niemals enthalten sollten. Andere sind spezifisch für diese neue Ebene. Anweisungen, die den Spielraum des Agenten erweitern, ohne es zu sagen. Prompts, die nicht vertrauenswürdige Inhalte hereinholen und sie als Befehl behandeln. Tool-Beschreibungen, die falsch darstellen, was ein Tool tut, sodass der Agent es aus dem falschen Grund aufruft. Skills, die andere Skills zu einem Pfad verketten, den niemand beabsichtigt hat.

In der letzten Kategorie liegt die eigentliche Schwierigkeit. Ein Skill ist genau im Verhältnis dazu gefährlich, wie weit er reichen kann, und moderne Agenten können viel erreichen: das Dateisystem, das Netzwerk, andere Agenten, die Tools, die ein anderer Skill registriert hat. Der Wirkungsradius eines schlechten Skills ist nicht der Skill. Es ist alles, was der Agent berühren kann, ein bewegliches Ziel, das davon abhängt, welche anderen Skills zuerst geladen wurden.

Das Problem vergifteten Kontexts

Das Unbehagliche an der Agentensicherheit ist, dass die Grenze zwischen Daten und Anweisung von nichts durchgesetzt wird. Ein Modell liest Text. Es weiß nicht von Natur aus, welche Sätze Fakten zum Abwägen und welche Befehle zum Befolgen sind.

Ein Skill, der eine Webseite abruft, einen Issue-Tracker liest oder eine E-Mail zusammenfasst, setzt den Agenten also Text aus, der Anweisungen enthalten kann. Wenn das Modell ihnen folgt, gibt es keinen Exploit im traditionellen Sinn. Es gibt nur ein System, das getan hat, was ihm etwas gesagt hat, dem es nicht hätte vertrauen dürfen.

Deshalb muss das Scannen zur Ladezeit geschehen und nicht zur Vorfallszeit. Sobald ein Skill in einem Agenten mit weitreichenden Berechtigungen läuft, ist die interessante Frage bereits schlecht beantwortet. Der Kontrollpunkt muss zuerst kommen, und er muss automatisch sein, denn die menschliche Prüfung jedes Skills in einer Registry skaliert nicht und wird es nie tun.

Auditierung wird zum Produkt

Die Veröffentlichung von Cloudflare deutet auf einen zweiten Trend hin. Ihr Audit-Skill erzeugt maschinenlesbare Befunde statt einer Liste, die jemand lesen muss. Diese Formulierung leistet echte Arbeit. Befunde, die ein Mensch lesen muss, sind Befunde, die ein Mensch überfliegt. Befunde, die eine Pipeline verarbeiten kann, lassen sich in Tickets, blockierte Merges oder abgelehnte Deployments verwandeln, ohne dass jemand daran denken muss, nachzusehen.

GitHubs Arbeit zur Geheimniserkennung passt ins gleiche Muster. Das Leck von Geheimnissen skaliert mit der Menge produzierten Codes, und die Codeproduktion ist stark gestiegen. Die Antwort war nicht "mehr Prüfer einstellen". Es war ein kontextbewusster Klassifikator, der Rauschen reduziert, damit die Warnungen, die Menschen tatsächlich sehen, eher echt sind. Präzision bestimmt im Sicherheitswerkzeug, ob nach dem dritten Monat noch jemand die Warnungen liest.

Beides ist derselbe Zug auf verschiedenen Ebenen. Statt Menschen zu mehr Wachsamkeit aufzufordern, macht man die automatische Prüfung gut genug, dass menschliche Aufmerksamkeit nur dort verbraucht wird, wo sie zählt. Das ist die einzige Strategie, die den Kontakt mit Volumen übersteht.

Die Governance-Frage darunter

Hier gibt es eine Richtlinienebene, die sich schneller bewegt, als den meisten Teams bewusst ist. Versionskontrollsysteme beginnen, Herkunfts-Metadaten zu tragen. Paket-Registries fügen Attestierung hinzu. Standardisierungsgremien arbeiten daran, wie man synthetische Inhalte kennzeichnet und einen Agenten identifiziert. Die Richtung geht zu einer Welt, in der Herkunft und Integrität eines Artefakts beweisbar sein müssen statt angenommen.

Skills sitzen in dieser Welt unbequem, weil derselbe Skill je nach Kontext nützlich und gefährlich sein kann. Ein Skill, der Dateien ändern kann, ist für einen Coding-Agenten unverzichtbar und für einen Agenten, der auch nicht vertrauenswürdige E-Mails liest, katastrophal. Die Vertrauensentscheidung ist keine Eigenschaft des Skills allein. Sie ist eine Eigenschaft des Skills plus der Umgebung plus der anderen Skills, die er erreichen kann.

Was nahelegt, dass die Scanner irgendwann mehr als Musterabgleich tun müssen. Die wirklich schwierige Version dieses Tools prüft, ob eine vorgeschlagene Kombination von Skills eine Fähigkeit verleiht, die niemand verlangt hat, und warnt vor dem Ausliefern statt danach.

Was Teams jetzt tun sollten, ohne überzureagieren

Panik ist nicht die richtige Antwort, und es als Problem anderer zu behandeln ebenso wenig.

Die praktischen Schritte sind unspektakulär. Behandle Skills von Dritten als nicht vertrauenswürdige Abhängigkeiten, denn genau das sind sie. Versionen anpinnen und Diffs prüfen, wenn sie sich ändern. Agenten in Umgebungen ausführen, in denen der Wirkungsradius begrenzt ist, damit ein schlechter Skill nicht das Netzwerk oder die Produktionsdatenbank erreicht, nur weil der Agent bequem war. Protokollieren, welche Skills geladen wurden und was sie getan haben, denn die erste schwierige Frage nach einem Vorfall ist, was laufen durfte.

Die Branche ist diesen Weg schon gegangen. Paket-Ökosysteme waren unsicher, dann wurden sie mühsam anzugreifen, und die Mühsamkeit ist der Punkt. Agenten-Skills steuern auf dasselbe Gleichgewicht zu, und die diese Woche ausgelieferten Projekte sind der erste ernsthafte Versuch, den Kontrollpunkt zu bauen. Früher dorthin zu kommen als der Vorfall ist billiger als danach, und das Einzige, was nötig ist, um früh dorthin zu kommen, ist die Bereitschaft, dabei langweilig zu sein.