Eine Skill-Datei. Eine Regeldatei. Eine MCP-Serverkonfiguration. Drei Zeilen Klartext. commitSie sehen aus wie Dokumentation, sind wie Dokumentation geprüft und nicht wie Code. Und doch kann jede von ihnen im Stillen die Anweisungen an Ihren KI-Assistenten und dessen Zugriffsrechte verändern. Das ist die unbequeme Wahrheit hinter der KI-Sicherheit. im Jahr 2026 angegebenDie Branche verbrachte zwei Jahre damit, sich über den Inhalt KI-generierten Codes Gedanken zu machen. Das größere Problem erwies sich jedoch als die KI-Lieferkette selbst: die Modelle, Agenten, MCP-Server und Konfigurationsdateien, die nun neben dem Quellcode und den Open-Source-Abhängigkeiten liegen – größtenteils uninventarisiert und ungeprüft. Genau deshalb hat sich die Sicherheit der KI-Lieferkette zu einer eigenen Disziplin entwickelt, und deshalb ist die Wahl des richtigen KI-Sicherheitsunternehmens genauso wichtig wie die Wahl des richtigen Scanners.
Die Angriffsfläche, für die niemand eingeplant hatte
Früher gab es bei Software nur wenige Angriffspunkte für einen Angreifer: den Code, die Abhängigkeiten, die pipeline. AI hat zwei weitere hinzugefügt, und beide fließen direkt in die KI-Lieferkette ein.
Das Modell und der Agent. Werkzeugvergiftung, Eingabeaufforderungen, Agentenautonomie, die über die beabsichtigten Grenzen hinausgeht. Eine versteckte Anweisung in der Beschreibung eines MCP-Servers kann unbemerkt die Aktionen eines Kopiloten umleiten, ohne dass der Entwickler es bemerkt.
Die eigene Umgebung des Entwicklers. IDEs, KI-Copiloten, MCP-Server, Agenten-CLIs. Unsichtbar für ältere AppSec-Scanner, die nicht wissen, was ein Modell ist, und unsichtbar für EDR, das das Betriebssystem überwacht und keine Ahnung hat, was eine Abhängigkeit oder ein MCP-Aufruf ist.
Nichts davon ist rein theoretisch. In den letzten achtzehn Monaten:
- Eine versteckte Unicode-„Regeldatei-Hintertür“ ermöglichte es Angreifern, unsichtbare Anweisungen in die Konfigurationsdateien einzuschleusen, die Copilot und Cursor lasen, und so unbemerkt den vom Assistenten generierten Code zu manipulieren. GitHub fügte 2025 eine Warnung dazu hinzu.
- Eine Schwachstelle in der Befehlsinjektion einer beliebten MCP-Bridge (CVSS 9.6) wurde über 400,000 Mal heruntergeladen, bevor sie behoben wurde. Dies war der erste dokumentierte Fall einer vollständigen Remote-Codeausführung, die allein durch die Verbindung mit einem nicht vertrauenswürdigen MCP-Server ausgelöst wurde.
- Ein sich selbst verbreitender npm-Wurm machte die Entwickler selbst zum Verbreitungsmechanismus, und dieses Muster wiederholte sich in den folgenden Monaten in großem Umfang in anderen Ökosystemen – ein Lehrbuchbeispiel für ein Versagen der KI-Lieferkette im Bereich der Sicherheit.
- Forscher stellten fest, dass ein beträchtlicher Anteil der von LLMs empfohlenen Pakete gar nicht existiert, sondern dass es sich um „slopsquatted“ Namen handelt, die ein Angreifer registriert, bevor ein echter Entwickler das Modell überhaupt auffordert, sie zu importieren.
Googles eigene Forschung zur Absicherung der Lieferkette von KI-Software kommt aus einem anderen Blickwinkel zu einem ähnlichen Schluss: Modelle, die 2023 und 2024 im Umlauf waren, wirkten zwar legitim, enthielten aber Code, der nach dem Download Daten exfiltrieren oder eine Hintertür einbauen konnte. Die Lösung bestand weniger in einer neuen Werkzeugkategorie als vielmehr in der Anwendung von Lieferkettenrichtlinien wie Herkunftsnachweis und Signatur auf Artefakte, die zuvor niemand verfolgt hatte. Das ist das Sicherheitsproblem der KI-Lieferkette in einem Satz: Die Artefakte sind neu, die notwendigen Richtlinien jedoch nicht.
Warum Ihre bisherigen Werkzeuge an ihre Grenzen stoßen
SAST liest Code. SCA Es liest eine Liste von Abhängigkeiten. Keiner der beiden weiß, was ein Modell ist, was ein MCP-Server offenlegt oder welche Anweisungen eine Skill-Datei einem Agenten gibt. Genau in dieser Lücke greifen Angriffe im Zeitalter der KI an – im Spannungsfeld zwischen „gescanntem Code“ und „stillschweigend implementierter KI“.
Das Ergebnis ist eine Kategorie von Schatten-KI Nr. CISIch kann derzeit folgende Fragen beantworten: Welche Modelle verwenden wir? Welche Agenten haben Zugriff auf welche Systeme? Und mit welchem MCP-Server hat sich letzten Dienstag jemand ohne Benachrichtigung verbunden? Diese Fragen präzise zu beantworten, ist die Aufgabe der KI-gestützten Lieferkettensicherheit, und genau deshalb stoßen generische AppSec-Tools hier immer wieder an ihre Grenzen.
Was KI-Sicherheit tatsächlich bedeutet
Xygeni ist das KI-Sicherheitsunternehmen, das dies als drei miteinander verbundene Bewegungen behandelt. SDLC: entdecken, erkennen und durchsetzen.
Entdecken Sie: Erfahren Sie, welche KI Sie tatsächlich haben
Die kontinuierliche, automatische Suche in Ihren Repositories deckt alle KI-Ressourcen auf: Modelle, Frameworks, Datensätze, Inferenzendpunkte, Agenten, MCP-Server, Fähigkeiten, Eingabeaufforderungen, guardrailsund die KI-Codierungswerkzeuge, die Ihre Entwickler tatsächlich verwenden. Keine Umfragen. Keine Selbstauskünfte. Wenn es Spuren in einem Repository hinterlässt, taucht es im Inventar auf – die erste und grundlegendste Voraussetzung für echte KI-Lieferkettensicherheit.
Der KI-Graph bildet dann ab, wie diese Ressourcen miteinander verbunden sind: welches Modell ein Datensatz speist, welcher Agent welches Tool aufruft, welcher MCP-Server welchem Assistenten zugrunde liegt. Eine einzelne Ressource allein liefert wenig Informationen. Der Graph zeigt Ihnen, wo sich das Risiko konzentriert.
Aus derselben Entdeckung generiert Xygeni ein KI-BOMEin revisionssicheres, maschinenlesbares Verzeichnis aller KI-bezogenen Elemente Ihrer Software. Wenn eine Aufsichtsbehörde, ein Prüfer oder ein Kunde fragt, welche KI Sie einsetzen, genügt ein einfacher Download statt dreiwöchiger Hektik.
Erkennen: die Risiken, die herkömmliche Scanner nicht erkennen können
Ein spezieller KI-Scanner sucht nach Fehlermodi, die spezifisch für KI-Systeme sind: Eingabeaufforderungen, Werkzeugeinschleusung und Aufruf nicht vertrauenswürdiger Werkzeuge, Datenlecks durch Datenabruf, Umgehung von Systemeingabeaufforderungen und übermäßige Eigenverantwortung. Jeder Befund wird dem entsprechenden Fehlermodus zugeordnet. OWASP Top 10 für LLM-Bewerbungen und verweist auf die genaue Datei und Zeile, die die Sicherheitslücke verursacht, und nicht auf eine vage Warnung wie „Überprüfen Sie Ihre KI-Nutzung“.
Dieselbe Erkennungsebene behandelt Skill-Dateien, Regeldateien und MCP-Konfigurationen als die Sicherheitsartefakte, die sie sind, und nicht als harmlose Dokumentation. Sie kennzeichnet schädliche oder manipulierte Skills, überprüft MCP-Serverkonfigurationen auf Tool-Poisoning und deckt die Eingabeaufforderungen auf, die Ihre KI-Workloads tatsächlich steuern.
Priorisieren: Der Trichter, der Störfaktoren herausfiltert, nicht Abkürzungen.
Jeder gefundene Fehler wird schrittweise gefiltert: Zuerst wird geprüft, was im Anwendungscode erreichbar ist, dann, was tatsächlich ausnutzbar ist, und schließlich, was sich im Code befindet, an dem Ihr Team aktiv arbeitet. Die Entwickler erhalten nur die Liste derjenigen, die tatsächlich eine Produktionsumgebung gefährden, inklusive Framework-Referenz, dem Zeitraum der potenziellen Sicherheitslücke und Hinweisen zur Risikominderung.
Durchsetzen: Stoppen Sie es, bevor es startet.
Shield Die Richtliniendurchsetzung wird direkt auf dem Endgerät des Entwicklers umgesetzt: Unautorisierte und schädliche Installationen, nicht genehmigte Modelle und nicht autorisierte MCP-Server werden blockiert, bevor irgendetwas ausgeführt wird. Dahinter steckt Xygenis Technologie. Malware-Frühwarnung (MEW)Dadurch werden schädliche Pakete erkannt, bevor eine Signatur existiert. Die reputationsbasierten Tools vertrauen dieser Schicht weiterhin, da das Paket noch nicht gemeldet wurde. Es handelt sich um die Durchsetzungskomponente der KI-gestützten Lieferkettensicherheit: Erkennung und Aufdeckung zeigen an, was nicht stimmt. Shield Das ist es, was es tatsächlich stoppt.
Ihre KI-Exposition beschränkt sich nicht nur auf Ihren KI-Code.
Ein vollständiges Bild der KI-gestützten Lieferkettensicherheit erfordert mehr als ein Modellinventar, und es geht selten nur um die auffälligen Dinge:
- Nachweise des KI-Anbieters in Eingabeaufforderungsdateien, Agentenkonfigurationen oder pipeline Protokolldateien sind Geheimnisse wie alle anderen auch, und die Geheimniserkennung von Xygeni fängt sie ab, bevor sie in ein öffentliches Register gelangen.
- Anfällige KI- und ML-Abhängigkeiten Sie enthalten gewöhnliche CVEs, die durch dieselbe Software-Kompositionsanalyse aufgedeckt werden, die bereits den Rest Ihres Stacks abdeckt. Studien von Drittanbietern zur KI-Einführung haben gezeigt, wie stark der moderne KI-Stack aus extern bezogenen Paketen und versteckten Komponenten besteht – genau dem Bereich, für dessen Abdeckung die Software-Kompositionsanalyse entwickelt wurde.
- Schädliche Pakete schneller veröffentlicht als jede Empfehlung pipeline Sie können katalogisiert werden, wenn sie vor der Unterzeichnung erfasst werden, die gleiche MEW-Fähigkeit schützt den Rest Ihrer Lieferkette.
Die Agentenschicht: DevAI und CoreAI
Discovery und Detection erfassen, was sich bereits in Ihren Repositories befindet. DevAI Es arbeitet dort, wo das Risiko entsteht: innerhalb der IDE, als kontinuierliche, proaktive Schicht, die von Menschen und KI generierten Code während des Schreibvorgangs scannt – ganz ohne Aufforderung. Es erklärt den gesamten Exploit-Pfad hinter einem gefundenen Fehler und schlägt MCP-validierte Korrekturen vor, die Entwickler bedenkenlos anwenden können, ohne den Build zu beeinträchtigen.
CoreAI sitzt über den einzelnen Scannern als Intelligenzschicht: Sie korreliert Code, Abhängigkeiten, pipelineund ordnet Positionsdaten einem Risikomodell zu, beantwortet Fragen in natürlicher Sprache und erstellt die für die Führungsebene geeigneten Berichte, die ein Sicherheitsverantwortlicher benötigt, um zu zeigen, dass Governance tatsächlich stattfindet und nicht nur behauptet wird.
Erweitern Sie Ihre bestehenden KI-Sicherheitslösungen. Entfernen Sie nichts.
Der häufigste Einwand gegen eine neue Sicherheitskategorie lautet: „Wir haben bereits genügend Tools.“ Als KI-Sicherheitsunternehmen verlangt Xygeni von Ihnen keine Systemersetzungen: Die gleiche Triage, Erklärung und Priorisierung, die wir für unsere eigenen Ergebnisse anwenden, gilt gleichermaßen für die Ergebnisse Ihrer bestehenden Systeme. SAST, SCAund Scanner von Drittanbietern. Ihre bestehende Infrastruktur wird zur Ressource, nicht zum Opfer, und die Sicherheit Ihrer KI-gestützten Lieferkette verbessert sich, ohne dass ein kompletter Systemaustausch erforderlich ist.
Warum das jetzt und nicht später wichtig ist
Die Regulierungsbehörden verfolgen aus verschiedenen Richtungen dasselbe Ziel: Der EU-KI-Act, NIS2 und Spaniens ENS drängen alle auf die Erfassung und Rückverfolgbarkeit von KI-Systemen – genau die Nachweise, die eine KI-Stückliste erbringen soll. Die Richtung ist klar, auch wenn die genauen Mechanismen zur Einhaltung der Vorschriften noch ausgearbeitet werden: Man kann keine KI bescheinigen, die man nie erfasst hat, und man kann keine Sicherheit für die KI-Lieferkette gewährleisten, wenn diese selbst intransparent ist.
Auswahl eines KI-Sicherheitsunternehmens
Nicht jedes KI-Sicherheitsunternehmen legt seine Grenzen an derselben Stelle. Manche beschränken sich auf das Scannen Ihres eigenen KI-generierten Codes. Andere enden am Endpunkt. Die Sicherheitsfrage der KI-Lieferkette ist jedoch komplexer als die einzelnen Bereiche: Sie umfasst das Modell, den Agenten, den MCP-Server, die Skill-Datei und die zugrunde liegenden Abhängigkeiten. Diese vollständige Lebenszyklusansicht – von der Erkennung bis zur Durchsetzung – in einer zentralen Konsole zusammen mit Ihren übrigen AppSec-Ergebnissen ist entscheidend bei der Auswahl eines KI-Sicherheitsunternehmens und nicht nur eines einzelnen Tools.
Die Dateien, die niemand überprüft, wurden zum Einfallstor. KI-Sicherheit ist die Disziplin der Überprüfung dieser Dateien, und KI-Lieferkettensicherheit ist das, was diese Disziplin durchgängig wirksam macht, auf derselben Plattform, auf der Sie bereits alles andere überprüfen.
Finden Sie heraus, was Ihre KI tatsächlich tun darf. Kostenlos starten or Demo anfordern.
FAQ
Verlässt der Code von Xygeni jemals meine Infrastruktur?
Nein. Scans werden in Ihrer eigenen Umgebung ausgeführt, und der Quellcode wird niemals auf die Server von Xygeni hochgeladen. Das KI-Inventar und die KI-Stückliste werden anhand der lokal vom Scanner erfassten Daten erstellt, nicht anhand einer extern gesendeten Kopie.
Worin besteht der Unterschied zwischen AI Security, DevAI und CoreAI?
AI Security entdeckt und erkennt Sicherheitslücken: Es erstellt das KI-Inventar (AI-BOM) und findet Risiken wie Prompt-Injection oder manipulierte Skill-Dateien. DevAI arbeitet direkt in der IDE, während Entwickler Code schreiben, und schlägt dabei Korrekturen vor. CoreAI ist eine übergeordnete Plattform, die die Ergebnisse plattformweit korreliert und Fragen zu Ihrem Sicherheitsstatus in natürlicher Sprache beantwortet.
Mit welchen KI-Sicherheitsframeworks ist Xygeni kompatibel?
Die Ergebnisse entsprechen den OWASP Top 10 für LLM-Anwendungen, den OWASP Top 10 für MCP und den OWASP Top 10 für agentische Fähigkeiten sowie NIST SP 800-218A und CISDie A/G7-Leitlinien zu KI-Stücklisten. Diese Zuordnung ermöglicht es, die KI-Stückliste als Nachweis der Konformität und nicht nur als Inventarliste zu verwenden.
Wird dadurch jede KI-Bibliothek oder jedes Modell als Risiko eingestuft?
Nein. Der Priorisierungsprozess beschränkt die Ergebnisse auf das, was im Anwendungscode erreichbar, tatsächlich ausnutzbar und in aktiver Entwicklung ist, sodass die Liste, die ein Entwickler sieht, kurz ist und nicht eine Auflistung aller erkannten KI-Assets.
