JFrog ergänzt Intent-Scanning für KI-Agenten-Skills, Plugins und APM-Pakete
Herkömmliche AppSec-Werkzeuge wie SCA und SAST können laut JFrog Bedrohungen in KI-Assets wie Agenten-Skills, Plugins und APM-Paketen übersehen, weil diese nicht nur Code, sondern Anweisungen enthalten. Das Unternehmen beschreibt, wie JFrog AI Security die dahinterliegende Absicht prüft und Richtlinien durchsetzt, sobald ein Agent diese Assets nutzt.
- JFrog zufolge können SCA und SAST Bedrohungen in Agenten-Skills, Plugins und APM-Paketen übersehen, weil diese nicht nur Code, sondern Anweisungen enthalten.
- Eine von JFrog zitierte Studie vom Juli 2026 testete 1.613 bösartige Skills gegen acht Scanner; die stärkste Evasion-Technik umging jeden Scanner in mehr als 90 % der Fälle.
- JFrog AI Security kombiniert das Abhängigkeits-Scanning von Xray mit einem KI-gestützten Scanner, der Anweisungen liest und Assets als Not Malicious, Suspicious oder Malicious einstuft.
- Die Richtlinien umfassen versionsbezogene Allow-Lists, Blockaden nach Schweregrad und befristete Waivers und werden von JFrog Agent Guard durchgesetzt, sobald der Agent das Asset nutzt.
Warum SCA und SAST KI-Assets übersehen können
Laut JFrog prüfen gängige Werkzeuge für Anwendungssicherheit Drittanbieter-Komponenten auf bekannte Schwachstellen (SCA), analysieren Quellcode auf Fehler (SAST) und suchen nach offengelegten Zugangsdaten (Secret-Scanner). Eine SKILL.md-Datei, die in einen Coding-Agenten gelegt wird, ein Plugin aus einem Marketplace oder ein APM-Manifest dürften diese Tools womöglich nicht erfassen.
Die drei Asset-Typen erklärt das Unternehmen wie folgt:
- Agenten-Skill: ein gebündeltes Set von Anweisungen, meist eine SKILL.md-Datei mit einigen Skripten, das ein Coding-Agent in seinen Kontext lädt. Es bestimmt, wie der Agent Aufgaben wie das Triagieren eines Vorfalls oder das Review eines Pull Requests angeht.
- Agenten-Plugin: ein Paket aus Skills, MCP-Servern und weiteren Komponenten, das über den eigenen Marketplace eines Coding-Agenten verteilt wird.
- APM-Paket: Der Agent Package Manager ist ein aufkommender offener Standard, der Skills, Prompts und MCP-Server als versionierte Abhängigkeiten in einer einzigen Manifest-Datei bündelt.
JFrog argumentiert, dass es bei solchen Assets weder einen Abhängigkeitsbaum für SCA noch einen Codepfad für SAST gibt. Die Anweisungen selbst würden so zum blinden Fleck.
Was Forschung und Bedrohungsklassen zeigen
JFrog verweist auf eine Forschungsarbeit vom Juli 2026, in der ein Team ein Evasion-Framework baute. Es schrieb verdächtige Tokens, Befehle und Pfade zu Zugangsdaten eines bösartigen Skills um und verbarg die eigentliche Nutzlast, bis der Agent sie ausführte. Getestet wurde es gegen 1.613 reale, in freier Wildbahn gefundene bösartige Skills mit acht Scannern. Laut dem Beitrag umging die stärkste Technik jeden getesteten Scanner in mehr als 90 % der Fälle.
Die getarnten Skills funktionierten demnach weiterhin in produktiven Agenten, darunter Claude Code und Codex, ohne messbaren Rückgang der Erfolgsquote bei Aufgaben. Selbst wenn statische Scanner sie freigaben, könnten solche Skills laut JFrog Diebstahl von Zugangsdaten, Abfluss von Quellcode und die Installation von Backdoors ermöglichen.
Der Beitrag nennt vier absichtsbasierte Bedrohungsklassen: Prompt Injection, versteckte Anweisungen, verschleierte Nutzlasten und Exfiltration von Zugangsdaten. Als Beispiel führt JFrog eine einzelne Zeile an, die einen Agenten anweist, ~/.aws/credentials zu lesen und den Inhalt in seine Zusammenfassung aufzunehmen. Dafür gebe es keine CVE, so JFrog, weil der Text gültiges Markdown sei. Der Agent verfüge bereits über die Zugangsdaten des Entwicklers, und das Verhalten könne sich auf jedem Rechner von Teammitgliedern wiederholen, die die Datei geklont haben.
So scannt und erzwingt JFrog AI Security
JFrog beschreibt drei Schritte von der Erkennung zur Prävention: sowohl nach Codeproblemen als auch nach Absichten scannen, das Urteil in eine Richtlinie überführen und diese auf Agentenebene bei jedem Aufruf des Assets durchsetzen, nicht nur beim Download. Das Unternehmen weist darauf hin, dass ein im März freigegebener Skill im April einen neuen Befund erhalten könnte und dass eine reine Kontrolle am Eingang ihn auf Rechnern, auf denen er bereits liegt, weiterlaufen ließe.
Im Workflow von JFrog veröffentlicht ein Entwickler einen Skill in das Skills-Repository eines Projekts in JFrog Artifactory, was zwei Scans auslöst. JFrog Xray prüft, was das Bundle enthält, etwa Abhängigkeiten und bekannte CVEs. Der KI-gestützte Scanner von JFrog AI Security liest die Anweisungen selbst. Die Ergebnisse lauten „Not Malicious“, „Suspicious“ oder „Malicious“.
Die Projektrichtlinie steuert den Skill anschließend:
- Allow-Lists gelten pro Version, die Freigabe einer Version genehmigt also nicht die nächste.
- Die Durchsetzung lässt sich nach Schweregrad festlegen, etwa indem jeder Skill mit einem Befund der Stufe Critical blockiert wird.
- Berechtigte Ausnahmen lassen sich über befristete Waivers mit festem Ablaufdatum regeln.
JFrog Agent Guard setzt die Richtlinie am Harness durch, also dort, wo ein Agent auf das Asset zugreift. Derselbe Ansatz aus deterministischer und semantischer Prüfung erstreckt sich in der JFrog Platform auch auf Plugins und APM-Pakete.
Was das für Teams bedeutet
Laut JFrog werden Skills, Plugins und APM-Pakete in der JFrog Platform neben Docker-Images und npm-Paketen gespeichert, mit demselben Berechtigungsmodell und demselben Audit-Trail, die Sicherheitsteams bereits nutzen. Für Organisationen, in denen Entwickler Agenten-Skills informell teilen, etwa über Slack, lautet das Argument: KI-Assets lassen sich innerhalb der bestehenden Software-Lieferkette steuern statt in einer separaten Konsole.
Das Unternehmen verweist auf seine Dokumentation zum Scannen von KI-Assets, um das Scanning in einer bestehenden JFrog-Installation zu aktivieren, und bietet eine Demo von JFrog AI Security an. Außerdem weist es darauf hin, dass die Produktfunktionen je nach Edition und Bereitstellungsmodell variieren und dass der Beitrag kein Sicherheitsergebnis garantiert.
