Bösartige AI Skills erhöhen das Sicherheitsrisiko für Unternehmen
Google News hat einen deutlichen Konflikt rund um Enterprise AI sichtbar gemacht: Agenten gewinnen durch Skills nützliche Fähigkeiten, während Angreifer genau diese Erweiterungen ausnutzen. Aktuelle Forschung des Sicherheitsanbieters ESET identifizierte unter fast 900.000 analysierten Skills mehr als 3.000 bösartige Exemplare. Damit wird aus einer praktischen Agentenfunktion ein Problem der Softwarelieferkette.
Die Sorge reicht über einen einzelnen Marktplatz oder eine Malware-Kampagne hinaus. AI Skills können Anweisungen, Skripte, externe Dokumentation und Zugriff auf sensible Systeme kombinieren. Ein kompromittierter Skill kann daher sowohl die Entscheidungen eines Agenten als auch die von ihm gesteuerten Werkzeuge beeinflussen.
Unternehmen stehen nun vor einem Zielkonflikt zwischen Autonomie und Kontrolle. Offene Ökosysteme beschleunigen Experimente, doch ihre Vertrauenssignale sind weiterhin schwächer als bei etablierten Softwarepaketen. Forschende haben bereits gezeigt, dass Repository-Popularität, Marktplatzfreigaben und statisches Scanning gleichzeitig versagen können.
Was Google News über bösartige AI Skills ans Licht brachte
Die entscheidende Veränderung ist das Ausmaß, nicht das erste Auftreten einer bösartigen Erweiterung.
ESETs Forschung für das erste Halbjahr 2026 umfasste Bedrohungsaktivitäten, die von Dezember 2025 bis Mai 2026 beobachtet wurden. Das Unternehmen erklärte, es habe fast 900.000 AI Skills analysiert und zehntausende verdächtige Beispiele gefunden. Mehr als 3.000 wurden als bösartig eingestuft.
Ein AI Skill ist ein wiederverwendbares Paket, das einem Agenten vorgibt, wie er eine Aufgabe erledigt, Werkzeuge nutzt und zugehörige Informationen verarbeitet. Manche Skills enthalten kaum mehr als Anweisungen. Andere verbinden den Agenten mit Skripten, Diensten, Dateien, Kommandozeilenwerkzeugen oder sich verändernden Webressourcen.
Die analysierte Population wuchs im Untersuchungszeitraum stark. Berichten auf Grundlage der Ergebnisse zufolge scannte ESET im März rund 60.000 einzigartige Skills und im Mai fast 900.000. Die Zahl verdächtiger Funde stieg in diesem Zeitraum von etwa 10.000 auf mehr als 25.000.
Die Zahl bösartiger Funde stieg von rund 600 auf mehr als 3.000. Diese Werte belegen nicht, dass jedes Repository dieselbe Infektionsrate aufweist. Sie zeigen jedoch, dass Sicherheitsteams eine wachsende Menge von Verhaltensweisen externer Agenten bewerten müssen.
ESETs öffentliche Zusammenfassung des Bedrohungsberichts beschreibt Skills als kleine funktionale Komponenten, die von Agenten verwendet werden. Das Unternehmen fand bösartige und verdächtige Instanzen in den untersuchten Repositories.
Die Forschenden beobachteten Fähigkeiten im Zusammenhang mit Befehlsausführung, Code-Injection, Dateizugriff, dem Laden von Zugangsdaten, Verschleierung und externen Downloads. Diese Funktionen sind nicht automatisch bösartig. Gefährlich werden sie, wenn der angegebene Zweck eines Skills sie nicht rechtfertigt.
Ein legitimer Entwickler-Skill könnte Shell-Zugriff benötigen, um eine Anwendung zu erstellen. Ein Dokumentenassistent könnte die Berechtigung brauchen, ausgewählte Dateien zu lesen. Die Sicherheitsfrage lautet, ob diese Berechtigungen begrenzt, sichtbar und mit einem genehmigten Geschäftszweck verbunden bleiben.
Traditionelle Malware kommt häufig als ausführbare Datei, Anhang oder kompromittiertes Paket. Bösartige AI Skills fügen ein weiteres Verteilungsformat hinzu. Schädliche Anweisungen können in gewöhnlicher Sprache erscheinen, die ein Agent als operative Anleitung behandelt.
Dieses Design erschwert die Erkennung. Bei der Prüfung enthält ein Skill möglicherweise keine erkennbare bösartige Binärdatei. Stattdessen kann er den Agenten auf eine externe Seite verweisen, später neue Anweisungen abrufen oder bereits vorhandene legitime Werkzeuge missbrauchen.
Der Google-News-Beitrag ist relevant, weil er diese einzelnen Erkenntnisse zu einer Geschichte über Unternehmensrisiken verbindet. Die Bedrohung ist nicht mehr auf experimentelle persönliche Agenten beschränkt. Skills gelangen in Workflows von Ingenieuren, Marketern, Analysten, Designern und Vertriebsteams.
Diese Nutzer könnten Erweiterungen installieren, ohne dies als Softwarebereitstellung zu behandeln. Eine kurze Textdatei wirkt weniger gefährlich als ein Anwendungsinstaller. Doch der Agent, der diese Datei liest, verfügt möglicherweise bereits über Zugriff auf E-Mail, Cloud-Speicher, Quellcode oder internes Wissen.
Die Lücke zwischen Erscheinungsbild und Befugnissen schafft die zentrale Spannung. Skills wirken oft wie Dokumentation, können jedoch als ausführbare Workflow-Logik fungieren. Unternehmen können sie nicht sicher als harmlose Prompts verwalten.
Warum die Sicherheit von AI-Agenten nun der Absicherung der Lieferkette ähnelt
Ein Skill wird zu einer Unternehmensabhängigkeit, wenn sich ein Agent darauf verlässt, innerhalb von Unternehmenssystemen zu handeln.
Sicherheit in der Softwarelieferkette verfolgt, wo Komponenten herkommen, wer sie pflegt, welche Versionen bereitgestellt werden und wie Updates in die Produktion gelangen. Bösartige AI Skills erfordern viele der gleichen Kontrollen. Sie bringen außerdem Verhaltensrisiken mit, für deren Interpretation herkömmliches Package-Scanning nicht entwickelt wurde.
Ein Skill kann mehrere vertrauenswürdige Werkzeuge koordinieren, ohne eine Software-Schwachstelle auszunutzen. Er könnte einem Agenten anweisen, Zugangsdaten zu finden, eine Datei umzuwandeln und das Ergebnis anschließend an anderer Stelle zu senden. Jeder einzelne Tool-Aufruf kann für sich betrachtet legitim erscheinen.
Das Risiko wächst mit den Befugnissen des Agenten. Ein Assistent, der nur Texte entwirft, stellt ein geringeres Risiko dar als ein Assistent mit Verbindung zu einer Shell, einem Browser, einem Code-Repository und einem Cloud-Konto. Unternehmensagenten nähern sich zunehmend dem zweiten Modell an.
Dadurch entsteht ein Multiplikatoreffekt. Der Skill liefert Anweisungen, während der Agent Berechtigungen, Schlussfolgerungsfähigkeit und Ausführung bereitstellt. Ein Angreifer muss nicht jede Fähigkeit in die bösartige Erweiterung einbauen.
Der OpenClaw-Marktplatz ClawHub wurde zu einer frühen Fallstudie. Forschende dokumentierten bösartige Skills, die auf Zugangsdaten und Kryptowährungswerte zielten. Einige lieferten etablierte Malware aus, andere manipulierten agentengesteuerte Transaktionen.
Unit 42 von Palo Alto Networks untersuchte Marktplatzaktivitäten zwischen Februar und Mai 2026. Seine Analyse der Lieferkette identifizierte fünf nicht blockierte bösartige Skills, nachdem neue Prüfmaßnahmen eingeführt worden waren.
Zwei lieferten macOS-Infostealer aus, die mit Command-and-Control-Infrastruktur verbunden waren. Ein weiterer nutzte aufgeblähte Dateien, um Scanner-Schwellenwerte zu umgehen. Zusätzliche Skills zielten durch Verhaltensweisen, die speziell für autonome Agenten gelten, auf finanzielle Manipulation.
Unit 42 meldete die fünf Skills an ClawHub. Der Marktplatz entfernte sie und sperrte die zugehörigen Konten. Die Reaktion verringerte die unmittelbare Gefährdung, beseitigte jedoch nicht das zugrunde liegende Verteilungsproblem.
Frühere Entdeckungen hatten ClawHub bereits dazu veranlasst, VirusTotal und ClawScan zu integrieren. Diese Dienste ergänzten proaktives Screening und Codeanalyse. OpenClaw kündigte außerdem eine Zusammenarbeit mit Nvidia bei der Skill-Analyse und Dokumentation an.
Die Abfolge ist aufschlussreich. Ein Marktplatz ergänzte Abwehrmaßnahmen, nachdem bösartige Kampagnen aufgetaucht waren, dennoch fanden Forschende weiterhin ausweichende Skills. Dies ähnelt dem langjährigen Wettlauf bei Browser-Erweiterungen, Paketregistern und mobilen Anwendungen.
Agent Skills bringen eine weitere Komplikation mit sich, weil ihr wirksamer Inhalt über das heruntergeladene Artefakt hinausreichen kann. Ein lokaler Skill kann den Agenten anweisen, Online-Dokumentation zu lesen. Diese externe Seite kann sich ändern, ohne dass der geprüfte Skill verändert wird.
Sicherheitsteams können sich daher nicht allein auf ein Urteil zum Installationszeitpunkt verlassen. Ein sicheres Ergebnis beschreibt, was ein Scanner zu einem bestimmten Zeitpunkt beobachtet hat. Es garantiert nicht, dass jede Abhängigkeit unverändert bleibt.
Auch die Bestandsaufnahme im Unternehmen wird schwieriger, wenn Mitarbeiter Skills direkt hinzufügen können. Ein Unternehmen kann eine Agentenplattform genehmigen, ohne zu wissen, welche Community-Erweiterungen Nutzer anschließend installieren. Dadurch entsteht Shadow-AI-Verhalten innerhalb eines offiziell genehmigten Produkts.
Diese Unterscheidung ist für die Incident Response wichtig. Untersuchende müssen wissen, welcher Skill ausgeführt wurde, welche Anweisungen er geladen hat, welche Werkzeuge er aufgerufen hat und auf welche Informationen er zugegriffen hat. Gewöhnliche Anwendungsprotokolle erfassen diese vollständige Kette möglicherweise nicht.
Organisationen führen bereits für ausgewählte Systeme Software-Stücklisten. Agentenbereitstellungen benötigen einen verwandten Nachweis, der Modelle, Werkzeuge, Skills, externe Anweisungsquellen, Berechtigungen und Versionen abdeckt. Ohne diese Übersicht können Incident-Response-Teams die Gefährdung nicht zuverlässig bestimmen.
Ein durchsuchbarer interner Nachweis kann auch Untersuchungen unterstützen, nachdem eine riskante Erweiterung entdeckt wurde. Teams, die lokale technische Belege über eine Engineering-Wissensbasis organisieren, können Prüfentscheidungen, Zuständigkeiten und den Kontext von Gegenmaßnahmen bewahren.
Dieser Nachweis ersetzt keine Laufzeitsicherheit. Er hilft dabei festzustellen, wer eine Abhängigkeit genehmigt hat und warum. Die übergeordnete Anforderung bleibt die kontinuierliche Kontrolle darüber, was Agenten lesen, aufrufen und übertragen können.
Der zentrale Zielkonflikt lautet: Agentenautonomie versus Unternehmenskontrolle
Skills machen Agenten leistungsfähiger, indem sie wiederholte Überwachung verringern, und geben dadurch auch bösartigen Anweisungen Raum zum Handeln.
Ein Unternehmensagent wird nützlich, wenn er mehrstufige Arbeit erledigen kann. Er könnte Anforderungen sammeln, Dateien prüfen, einen Dienst abfragen, ein Artefakt erzeugen und das Ergebnis bereitstellen. Eine Genehmigung nach jeder kleinen Aktion einzufordern, würde einen Großteil dieses Nutzens zunichtemachen.
Umfassende Autonomie löst das Usability-Problem, vergrößert jedoch den potenziellen Schadensradius. Eine kompromittierte Erweiterung kann dieselben Verbindungen wiederverwenden, die den Agenten produktiv machen. Der Angreifer erlangt indirekt Zugriff über den autorisierten Workflow des Agenten.
Dies ist nicht einfach ein Wettbewerb zwischen offenen und geschlossenen Plattformen. Ein kuratierter Katalog kann weiterhin eine kompromittierte Komponente verteilen. Ein privater Skill kann weiterhin gefährlich werden, nachdem sich sein Repository, das Konto seines Maintainers oder eine externe Abhängigkeit verändert.
Offene Marktplätze erhöhen die Gefährdung, weil Veröffentlichung und Installation mit geringem Aufwand verbunden sein können. Sie ermöglichen aber auch Forschung, Entfernung und Community-Überprüfung. Jeden Agenten auf intern entwickelte Skills zu beschränken, würde einige Risiken senken, jedoch neue Wartungsaufwände schaffen.
Entscheidend ist, ob Befugnisse dem Prinzip der minimalen Rechte folgen. Ein Landing-Page-Skill sollte keinen uneingeschränkten Zugriff auf SSH-Schlüssel oder Cloud-Zugangsdaten benötigen. Ein Zusammenfassungs-Skill sollte nicht stillschweigend heruntergeladene Shell-Skripte ausführen.
Dieses Prinzip klingt vertraut, weil es vertraut ist. Das Prinzip der minimalen Rechte prägt Identitäts- und Anwendungssicherheit seit Jahrzehnten. Agentische Systeme erschweren die Durchsetzung, weil ein Agent mehrere einzeln erlaubte Aktionen zu einer unsicheren Abfolge zusammensetzen kann.
Skills arbeiten außerdem auf einer semantischen Ebene. Ihre Anweisungen beschreiben Ziele und Verfahren in natürlicher Sprache. Traditionelle Sicherheitskontrollen sind hervorragend darin, bekannte Code-Muster, Datei-Hashes und Netzwerkindikatoren zu erkennen.
Weniger wirksam sind sie, wenn das gefährliche Verhalten als plausibel wirkende operative Anleitung ausgedrückt wird. Eine Anweisung könnte den Agenten auffordern, eine Voraussetzung zu beschaffen, ein Konto zu validieren oder eine Konfiguration zu synchronisieren. Die schädliche Absicht wird erst aus dem Kontext ersichtlich.
OWASPs Leitfaden zu agentischen Skills trennt diese Verhaltensebene von der Ebene der Tool-Anbindung. Tools definieren verfügbare Aktionen, während Skills diese Aktionen zu Workflows orchestrieren.
OWASP nennt bösartige Skills, Kompromittierung der Lieferkette, übermäßige Berechtigungen, nicht vertrauenswürdige externe Anweisungen, schwache Isolierung und Update-Drift als zentrale Risiken. Diese Liste zeigt, warum ein einzelner Scanner oder eine Richtlinie das gesamte Problem nicht abdecken kann.
Eine sichere Architektur benötigt mehrere Grenzen. Der Marketplace muss die Herkunft nachvollziehbar machen. Die Agentenplattform muss Berechtigungen durchsetzen. Laufzeitkontrollen müssen Aktionen überwachen, während die Organisation Inventar und Verantwortlichkeiten pflegen muss.
Menschliche Freigaben bleiben sinnvoll, wenn sie an tatsächlichen Risiken ansetzen. Das Speichern eines gewöhnlichen Entwurfs in einem internen Ordner kann automatisch erfolgen. Das Hochladen vertraulicher Dateien oder Änderungen an der Produktionsinfrastruktur sollten eine stärkere Autorisierung erfordern.
Die Herausforderung besteht darin, bedeutungslose Aufforderungen zu vermeiden. Nutzer genehmigen routinemäßig Anfragen, die sie nicht verstehen – insbesondere wenn Unterbrechungen häufig werden. Ein Freigabedialog kann weder übermäßige Standardberechtigungen noch unsichtbare Änderungen an Abhängigkeiten ausgleichen.
Unternehmenskunden sollten außerdem den Nutzen eines Skills von seiner Vertrauenswürdigkeit unterscheiden. Beliebtheit zeigt Verbreitung, nicht Sicherheit. Eine hohe Zahl an Sternen kann soziale Bestätigung liefern, sagt jedoch nichts über das aktuelle Verhalten externer Anweisungen aus.
Dieselbe Vorsicht gilt für Marketplace-Abzeichen. Eine Freigabe kann bestätigen, dass eine Einreichung eine Prüfung bestanden hat. Sie belegt nicht, dass verknüpfte Ressourcen, Repository-Inhaberschaft oder nachgelagerte Pakete stabil bleiben.
Dieser Zielkonflikt wird die Akzeptanz in Unternehmen prägen. Sicherheitsteams, die jede Erweiterung blockieren, drängen Experimente in unverwaltete Umgebungen. Teams, die uneingeschränkte Installationen erlauben, schaffen einen wachsenden Abhängigkeitsgraphen, den sie nicht prüfen können.
Der praktikable Mittelweg ist gesteuerte Autonomie. Nutzer können auf freigegebene Fähigkeiten zugreifen, während risikoreiche Aktionen isoliert und beobachtbar bleiben. Skills erhalten Berechtigungen, die ihrem Zweck entsprechen – nicht jede Berechtigung, die dem Host-Agenten zur Verfügung steht.
Gesteuerte Autonomie erfordert zudem Widerrufsmöglichkeiten. Wird ein Skill unsicher, müssen Administratoren jede Installation finden, ihn deaktivieren, offengelegte Zugangsdaten ungültig machen und zugehörige Aktivitäten überprüfen können. Ein bloßes Entfernen aus dem Marketplace reicht nicht aus.
Statische Scanner verlieren das Vertrauen-Rennen
Die deutlichste Warnung kam von einem harmlos wirkenden Research-Skill, der Berichten zufolge mehr als 26.000 Agenten erreichte, nachdem er verfügbare Scanner passiert hatte.
Forscher von AIR Security entwickelten einen Skill namens brand-landingpage. Er sollte nichttechnischen Nutzern offenbar dabei helfen, mit Googles Design-Tool Stitch eine Landingpage zu erstellen. Der Skill bot echte Funktionalität, was das Angebot glaubwürdig machte.
Die Forscher reichten ihn bei einer beliebten Open-Source-Sammlung mit 156 Skills und etwa 36.000 GitHub-Sternen ein. Nach mehreren Tagen wurde der Beitrag angenommen. Anschließend bewarb AIR den Skill über eine Instagram-Anzeige, die sich an Marketing-, Design- und Vertriebsmitarbeiter richtete.
Der verpackte Skill enthielt zunächst keine offensichtliche schädliche Nutzlast. Stattdessen verwies er Agenten auf Installationsdokumentation auf einer von den Forschern kontrollierten Domain. Diese Domain leitete Besucher anfangs zum legitimen Stitch-Dienst weiter.
AIR änderte später die externen Anweisungen. Die überarbeitete Seite forderte Agenten auf, ein Skript herunterzuladen und auszuführen. Für das Experiment sammelte die Nutzlast E-Mail-Adressen, damit betroffene Nutzer benachrichtigt werden konnten.
Die Forscher erklärten, dass keine Agenten geschädigt wurden. Sie sagten außerdem, die Technik hätte private Unterhaltungen und verbundene interne Systeme erreichen können. Diese weitergehenden Auswirkungen waren mögliche Folgen, keine dokumentierten Schäden des Experiments.
Laut dem Bericht von AIR über den kontrollierten Skill-Test stuften Scanner von Cisco, Nvidia und skills.sh die Einreichung als sicher ein. Das Ergebnis zeigte eine strukturelle Grenze statischer Prüfungen auf.
Ein Scanner kann die aktuellen Dateien eines Skills prüfen und dennoch künftig extern gehostete Inhalte übersehen. Externe Dokumentation fungiert als veränderliche Abhängigkeit. Ihr Eigentümer kann die Anweisungen ändern, nachdem Marketplace und Nutzer Vertrauen aufgebaut haben.
Diese Methode ähnelt verzögerten bösartigen Updates in etablierten Software-Ökosystemen. Der Unterschied liegt in der Auslieferung: Angreifer können gewöhnliche Sprache verändern, die der Agent später als maßgebliche prozedurale Anleitung interpretiert.
Statische Analyse bleibt wertvoll. Sie kann bekannten Schadcode, verschleierte Befehle, verdächtige URLs, übermäßige Berechtigungen und gefährliche Paketabhängigkeiten erkennen. Der Fehler besteht darin, einen einzigen sauberen Scan als dauerhafte Vertrauensentscheidung zu behandeln.
Verhaltenstests fügen eine weitere Ebene hinzu. Eine Sandbox kann den Skill in einer eingeschränkten Agentenumgebung ausführen und versuchte Dateizugriffe, Downloads, Befehle und Netzwerkkommunikation beobachten. Dieser Ansatz kann Verhalten aufdecken, das sich hinter plausibel klingendem Text verbirgt.
Doch auch Sandboxing hat Grenzen. Ein Angreifer kann die Aktivierung verzögern, auf Umgebungssignale reagieren oder bekannten Analysesystemen harmlose Anweisungen liefern. Ein Test kann zudem nicht jede Interaktion zwischen einem Skill und den internen Tools eines Unternehmens vorhersehen.
Kontinuierliche Überwachung ist daher nach der Installation entscheidend. Sicherheitssysteme müssen erkennen, wenn ein Skill eine neue Domain kontaktiert, umfassendere Daten anfordert, sein Ausführungsmuster verändert oder Tools außerhalb seines erwarteten Zwecks aufruft.
Das Anheften von Inhalten kann das Abdriften externer Anweisungen verringern. Ein Unternehmen kann die geprüfte Version der Dokumentation bewahren oder kryptografische Hashes für heruntergeladene Komponenten verlangen. Der Agent sollte nicht automatisch allem vertrauen, was eine veränderliche URL später ausliefert.
Netzwerkkontrollen bieten einen weiteren Kontrollpunkt. Skills, die keinen Internetzugang benötigen, sollten keinen erhalten. Andere können auf genehmigte Domains, Methoden und Ziele beschränkt werden.
Die Transparenz zur Laufzeit muss über Netzwerkverkehr hinausgehen. Verteidiger benötigen eine Spur, die Nutzeranfrage, ausgewählten Skill, abgerufene Anweisungen, Modellentscheidungen, Tool-Aufrufe und die daraus resultierende Datenbewegung verbindet. Andernfalls verliert jede Aktion ihren Verhaltenskontext.
Das AIR-Experiment beweist nicht, dass jeder beliebte Skill unsicher ist. Es zeigt, dass gängige Vertrauenssignale zu einer falschen Schlussfolgerung führen können. Reputation, Marketplace-Akzeptanz und Scans unterstützten sämtlich dasselbe böswillig gestaltete Artefakt.
Diese skeptische Perspektive sollten Unternehmensverantwortliche beibehalten. Sicherheitsanbieter führen KI-spezifische Scanner ein, doch kein Scanner kann für veränderliche Workflows dauerhafte Sicherheit garantieren. Produktversprechen sollten anhand von Live-Umgehungstests und transparenten Fehlerraten bewertet werden.
Berichterstattung in Google News kann Aufmerksamkeit schaffen, doch Aufmerksamkeit stellt keine technische Kontrolle her. Käufer benötigen Belege dafür, dass Agentenplattformen Aktionen auch nach bestandener Skill-Prüfung begrenzen können. Prävention und Eindämmung müssen zusammenwirken.
Wer unter dem wachsenden Risiko unter Druck gerät
Agentenplattformen, Sicherheitsanbieter und Unternehmenskunden tragen nun gemeinsam Verantwortung für eine Abhängigkeit, die keiner von ihnen allein steuern kann.
Marketplace-Betreiber stehen unter dem unmittelbarsten Druck. Sie müssen schnelles Community-Wachstum gegen Verifizierung der Herausgeber, Prüfung von Artefakten, Update-Kontrollen und Incident Response abwägen. Höhere Hürden für Einreichungen können das Wachstum bremsen, doch schwache Kontrollen beschädigen das Vertrauen.
Entwickler von Agentenplattformen kontrollieren die Ausführungsumgebung. Sie entscheiden, ob Skills mit Host-Berechtigungen, in Containern oder über eingeschränkte Tools laufen. Ihre Architektur bestimmt, wie weit eine bösartige Anweisung reichen kann.
Sicherheitsanbieter stehen vor einer anderen Prüfung. Sie müssen schädliches Verhalten erkennen, das sich durch Code, natürliche Sprache, veränderliche Websites und legitime Administrationstools ausdrückt. Bestehende Endpoint- und Netzwerksignale bleiben wertvoll, doch semantischer Kontext wird unverzichtbar.
Unternehmenssicherheitsteams können das gesamte Problem nicht auslagern. Sie entscheiden, welche Plattformen in die Organisation gelangen und welche Verbindungen diese Plattformen erhalten. Sie bestimmen zudem, ob Mitarbeitende Community-Skills ohne Prüfung installieren dürfen.
Entwickler bleiben eine Hochrisikogruppe, weil Coding-Agenten oft Zugriff auf Shell und Repositories besitzen. Ein bösartiger Skill könnte auf Quellcode, Paket-Zugangsdaten, Signaturschlüssel, Cloud-Tokens oder Deployment-Konfigurationen zielen.
Nichttechnische Nutzer sind einer anderen Gefährdung ausgesetzt. Ein Marketing- oder Vertriebsskill kann auf E-Mails, Kundendatensätze, Marken-Assets, Besprechungsnotizen und Content-Systeme zugreifen. Seine freundliche Oberfläche kann die Autorität des zugrunde liegenden Agenten verschleiern.
Beschaffungsteams benötigen daher Fragen, die über Modellgenauigkeit hinausgehen. Sie sollten fragen, wie die Plattform installierte Skills entdeckt, Versionen erfasst, externe Anweisungen handhabt und Nutzerumgebungen voneinander trennt.
Sie müssen außerdem Widerrufsmöglichkeiten verstehen. Können Administratoren einen Skill auf jedem Endpoint deaktivieren? Können sie feststellen, welche Zugangsdaten während seines Installationszeitraums verfügbar waren?
Compliance-Teams werden sich für Nachweise interessieren. Überträgt ein Agent Kundeninformationen über einen nicht genehmigten Skill, muss die Organisation rekonstruieren können, was passiert ist. Ein allgemeines Chatbot-Transkript erklärt möglicherweise nicht jeden nachgelagerten Tool-Aufruf.
Incident-Response-Teams stehen vor ähnlichen Anforderungen. Sie benötigen unveränderliche Protokolle und eine verlässliche Zeitleiste. Außerdem müssen sie wissen, ob ein entfernter Skill an anderer Stelle Persistenz erzeugt hat, etwa durch einen geplanten Prozess oder eine geänderte Konfiguration.
Die Erkenntnisse von Unit 42 veranschaulichen dieses Problem. Forscher beobachteten Persistenzmechanismen im Zusammenhang mit böswilligen Marketplace-Aktivitäten. Das Entfernen des sichtbaren Eintrags neutralisierte nicht automatisch jede bereitgestellte Nutzlast oder jeden Befehlskanal.
Unternehmen sollten Agenten-Zugangsdaten nach einer bestätigten böswilligen Installation als potenziell kompromittiert behandeln. Das bedeutet, relevante Tokens zu widerrufen, Authentifizierungsaktivitäten zu überprüfen, geänderte Dateien zu kontrollieren und ausgehende Verbindungen zu untersuchen.
Das Risiko ist nicht über alle Deployments hinweg gleich verteilt. Ein isolierter Research-Agent mit synthetischen Daten hat begrenzte Folgen. Ein autonomer Agent, der mit Produktionssystemen verbunden ist, schafft ein wesentlich größeres Kontrollproblem.
Diese Unterscheidung sollte die Richtlinien leiten. Organisationen können Agenten und Skills nach zugänglichen Daten, verfügbaren Tools, Autonomie, Netzwerkreichweite und Geschäftsauswirkungen klassifizieren. Kombinationen mit höherem Risiko erhalten strengere Prüfung und Überwachung.
Der Druck erreicht auch Programme für KI-Governance. Viele Programme konzentrieren sich auf Modellauswahl, Datenschutzbedingungen, Genauigkeit der Ausgaben und akzeptable Nutzung. Bösartige KI-Skills führen operative Abhängigkeiten ein, die eher Anwendungssicherheit als Modell-Governance ähneln.
Governance-Gremien benötigen technische Verantwortlichkeit, nicht nur schriftliche Grundsätze. Jemand muss Skill-Quellen freigeben, Inventar pflegen, Berechtigungsgrenzen festlegen und reagieren, wenn sich eine vertrauenswürdige Abhängigkeit ändert.
Der erfolgreiche Ansatz wird sich nicht auf eine einzelne Abteilung stützen. Platform Engineering kann Deployment-Kontrollen durchsetzen. Die Sicherheit kann Verhalten überwachen, während Geschäftsverantwortliche akzeptable Aufgaben und Datenzugriffe definieren.
Ohne diese Koordination schaffen Organisationen zwei unbefriedigende Wege. Freigegebene Agenten bleiben zu eingeschränkt, um hilfreich zu sein, während Mitarbeitende weniger kontrollierte Alternativen installieren. Beide Ergebnisse schwächen die Unternehmensaufsicht.
Drei Signale werden zeigen, ob die Abwehr aufholt
Die nächste Phase wird anhand von Marketplace-Kontrollen, Laufzeitnachweisen aus Unternehmen und unabhängigen Erkennungstests gemessen.
Das erste Signal ist, ob große Skill-Registries überprüfbare Herkunft und unveränderliche Versionierung einführen. Ein Marketplace sollte den Herausgeber identifizieren, geprüfte Artefakte bewahren und jede Änderung offenlegen. Auch externe Anweisungen benötigen Inventar- und Integritätskontrollen.
Wenn Registries diese Maßnahmen breit umsetzen, werden Angreifer beim Ersetzen vertrauenswürdiger Inhalte auf mehr Reibung stoßen. Das würde die Annahme stärken, dass offene Skill-Ökosysteme reifen können, ohne Community-Beiträge aufzugeben.
Wenn Registries weiterhin auf Beliebtheit und einmalige Scans setzen, wird die aktuelle Risikobewertung überzeugender. Mit mehr verzögerten Nutzlasten und Übernahmen von Abhängigkeiten ist zu rechnen, wenn wertvolle Skills Nutzer gewinnen.
Das zweite Signal ist, ob Enterprise-Agent-Plattformen durchsetzbare Berechtigungen auf Skill-Ebene bereitstellen. Administratoren benötigen klare Grenzen für Dateien, Tools, Zugangsdaten, Befehle und Netzwerkziele. Diese Grenzen müssen dem Skill über jede Bereitstellung hinweg folgen.
Ebenso wichtig sind klare Laufzeitspuren. Ein Sicherheitsanalyst sollte eine Aktion mit dem Skill und den externen Anweisungen verknüpfen können, die sie ausgelöst haben. Protokolle sollten lokale Manipulationen überstehen und unternehmensweite Suchen unterstützen.
Wenn Plattformen diese Kontrollen bieten, lässt sich ein bösartiger Skill leichter eindämmen. Er könnte zwar weiterhin in die Umgebung gelangen, doch seine Fähigkeit, auf unabhängige Ressourcen zuzugreifen, würde eingeschränkt. Das würde die schwerwiegendsten Enterprise-Szenarien abschwächen.
Wenn Plattformen jeden Skill der vollständigen Autorität des Agenten aussetzen, bleibt das Risiko am Endpunkt konzentriert. Eine übersehene Erweiterung kann dann Zugriff auf viele voneinander unabhängige Systeme erben.
Das dritte Signal sind unabhängige Tests gegen veränderliche und verzögerte Angriffe. Scanner-Bewertungen sollten Änderungen externer Anweisungen, Weiterleitungen über vertrauenswürdige Domains, ruhende Payloads, Übernahmen von Repositories und legitime Tools umfassen, die in unsicheren Abfolgen eingesetzt werden.
Das Experiment mit 26.000 Agenten lieferte einen solchen Test. Künftige Bewertungen benötigen wiederholbare Methoden, transparente Stichproben und Offenlegungen, die mutmaßliches Verhalten von bestätigter Malware trennen.
Eine konsistente Erkennung durch unabhängige Tools würde darauf hindeuten, dass der Markt gemeinsame Sicherheitsgrundlagen entwickelt. Große Abweichungen würden zeigen, dass Anbieter bösartiges Verhalten weiterhin unterschiedlich definieren.
Organisationen sollten nicht auf perfekte Standards warten. Sie können damit beginnen, installierte Skills zu inventarisieren und jeden einzelnen einem Verantwortlichen, einer Quelle, einer Version, Berechtigungen und externen Abhängigkeiten zuzuordnen.
Sie können Agenten mit weitreichenden Berechtigungen isolieren, den Netzwerkzugang beschränken und für sensible Aktionen Genehmigungen verlangen. Außerdem können sie Skills erneut prüfen, wenn sich Abhängigkeiten ändern – nicht nur bei der ersten Installation durch Nutzer.
Teams sollten entfernte oder neu markierte Skills als Auslöser für Sicherheitsvorfälle behandeln. Die Reaktion sollte Zugangsdaten, Persistenz, Datenzugriffe und ausgehende Kommunikation untersuchen. Das Löschen des lokalen Skills ist nur der erste Schritt.
Die Aufmerksamkeit von Google News für bösartige AI-Skills sollte zu einer praktischen Frage führen: Kann Ihre Organisation erklären, was jeder Enterprise-Agent tun darf? Wenn die Antwort unvollständig ist, beginnen Sie mit den Agenten, die mit Code, Cloud-Systemen, Kundendaten und interner Kommunikation verbunden sind. Ordnen Sie ihre Skills zu, beschränken Sie unnötige Berechtigungen und bewahren Sie die Belege, die zur Untersuchung ihrer Aktionen erforderlich sind. Die Sicherheit von AI-Agenten wird nicht davon abhängen, einen perfekten Scanner zu finden. Sie wird davon abhängen, vertrauenswürdige Distribution, begrenzte Berechtigungen, kontinuierliche Beobachtung und schnelle Sperrung zu kombinieren, bevor eine scheinbar nützliche Erweiterung zu einem Sicherheitsvorfall im Unternehmen wird.
