KI schreibt mittlerweile einen Großteil der Software in Produktion. Laut Aikidos Bericht „State of AI in Security and Development 2026“ sind 24 % des Produktionscodes KI-generiert. Allerdings haben 69 % der Unternehmen Schwachstellen in KI-generiertem Code entdeckt und 20 % meldeten infolgedessen einen schwerwiegenden Vorfall.
Ein Großteil der Sicherheitsdiskussionen rund um LLMs konzentriert sich auf die Implementierung von Guardrails für die Modelle. Doch der Anwendungsebene wird weitaus weniger Aufmerksamkeit geschenkt, obwohl viele dieser Vorfälle dort ihren Ursprung haben und Guardrails nicht helfen können. Im Januar 2025 führte eine kritische Fehlkonfiguration in KI-generiertem Code dazu, dass über 170 von Lovable entwickelte Apps E-Mails, API-Schlüssel, Zahlungsdetails und persönliche Daten preisgaben. Keine vor einem Modell platzierte Guardrail hätte dies erkannt.
Dieser Beitrag erläutert, was LLM-Anwendungssicherheit tatsächlich umfasst, warum sie notwendig ist, wie man ein geeignetes Tool auswählt und welche Plattformen die beste Abdeckung bieten.
{{cta}}
TL;DR
Aikido Security ist die stärkste Option für Teams, die eine LLM-Anwendungssicherheit auf Enterprise-Niveau über den gesamten KI-Entwicklungslebenszyklus hinweg wünschen. Es scannt KI-generierten Code in der IDE, blockiert bösartige und halluzinierte Pakete zum Installationszeitpunkt, schützt die Entwicklerumgebung vor Bedrohungen wie bösartigen MCP-Servern und verfolgt, welche KI-Modelle Ihre Anwendung in Produktion aufruft.
Was ist LLM-Anwendungssicherheit?
In diesem Artikel konzentrieren wir uns auf die LLM-Sicherheit von der Anwendungsseite, was bedeutet, den Code, die Abhängigkeiten und die Infrastruktur rund um ein LLM zu sichern. Dies unterscheidet sich von der Modellsicherheit, die das Verhalten des LLM zur Laufzeit abdeckt und durch Guardrails und Red-Teaming-Tools wie Lakera Guard, Prisma AIRS, NeMo Guardrails und Garak gehandhabt wird. Keines davon ist allein ausreichend.
Aikidos PromptPwnd-Forschung zeigte, warum die Anwendungsseite Aufmerksamkeit verdient. Nicht vertrauenswürdige Eingaben wurden in Prompts für Gemini CLI und andere Agenten injiziert, die in GitHub Actions-Workflows ausgeführt wurden, und diese Agenten nutzten ihre privilegierten Tokens, um Secrets preiszugeben. Mindestens fünf Fortune-500-Unternehmen waren betroffen.
Das Modell war der Einstiegspunkt für den Angreifer, aber die Schwachstelle lag in der Workflow-Datei, die von Anwendungssicherheitstools überprüft werden kann. SAST-Regeln können nicht vertrauenswürdige Eingaben, die in Prompts fließen, und privilegierte Tokens, die Agenten ausgesetzt sind, kennzeichnen, was genau das ist, was Aikidos Opengrep-Regeln erkennen und was Google innerhalb von vier Tagen nach der Offenlegung behoben hat.
Die OWASP Top 10 for LLM Applications 2025 ist der Referenzrahmen für diesen Bereich, und mehrere ihrer Kategorien sind auf der Anwendungsschicht angesiedelt, darunter Lieferkette (LLM03), Fehlerhafte Ausgabebehandlung (LLM05), Übermäßige Autonomie (LLM06) und Fehlinformationen (LLM09). Die Taxonomie wurde jedoch für Laufzeit-LLM-Anwendungen konzipiert und erfasst nur teilweise die Risiken der KI-gestützten Entwicklung.
Diese Schwachstellen treten bereits in der realen Welt auf. Unter LLM09 testeten Forschende bei USENIX 2025 16 Modelle anhand von 2,23 Millionen Code-Samples und fanden heraus, dass 19,7 % mindestens einen halluzinierten Paketnamen enthielten. Als identische Prompts erneut ausgeführt wurden, erschienen 43 % der halluzinierten Pakete in jeder von 10 Abfragen wieder. Angreifer registrieren jetzt im Voraus gefälschte Namen und verwandeln Modell-Eigenheiten in Lieferkettenangriffe.
Das Abdecken dieser Kategorien erfordert mehrere unterschiedliche Fähigkeiten. SAST und Secret Scanning auf Anwendungscode erkennen festcodierte Anmeldeinformationen und unbereinigte Eingaben, die in Prompts fließen. SCA kennzeichnet bekannte anfällige AI-Framework-Versionen, während die Erkennung von Lieferketten-Malware bösartige und halluzinierte Pakete erfasst. Der Schutz der Entwickelnden-Umgebung erkennt bösartige MCP-Server, die als Pakete verteilt werden, und kompromittierte Erweiterungen, bevor sie installiert werden. Und die LLM-Nutzungsverfolgung überwacht, welche Modelle Ihre Anwendung tatsächlich aufruft, und deckt so nicht autorisierte KI-Integrationen auf.
Warum Sie LLM-Sicherheitstools benötigen
Die KI-Entwicklung hat neue Schwachstellen eingeführt, die Sicherheitsteams beheben müssen.
- KI-generierter Code wird unüberprüft ausgeliefert: Da ein Viertel des Produktionscodes mittlerweile KI-generiert ist, hat die Überprüfung nicht mit der Ausgabe Schritt gehalten.
- LLMs erben die Schwachstellen des Codes, in dem sie ausgeführt werden: Es ist nicht nur der von KI geschriebene Code, der zählt. Jeder Code, den ein LLM liest, ausführt oder dem es Kontext entnimmt, wird Teil seiner Angriffsfläche, was genau PromptPwnd ausnutzbar machte.
- Slopsquatted-Pakete: Angreifer registrieren die Paketnamen, die KI-Assistenten halluzinieren, und verwandeln eine Modelleigenheit in einen Lieferkettenangriff.
- Shadow AI: Teams rufen Modelle auf, die niemand inventarisiert hat, und senden Daten an Anbieter, die niemand genehmigt hat.
- Der Compliance-Druck beginnt, LLM-Sicherheit zu fordern: Der EU AI Act ist das deutlichste Beispiel, und die OWASP LLM Top 10 wird zum De-facto-Referenzrahmen bei Sicherheitsüberprüfungen.
Wie man ein LLM-Sicherheitstool wählt
Abdeckung des gesamten AI SDLC
Eine Plattform, die KI-generierten Code, die Lieferkette, die ihn speist, und die Entwickelnden-Umgebung, die ihn produziert, abdeckt. Punktuelle Tools decken nur einen Ausschnitt ab, und das Zusammenfügen verschiedener Anbieter bedeutet mehrere Dashboards und doppelte Befunde.
Prüft es KI-generierten Code in der IDE?
Von einem Assistenten geschriebener Code sollte zum Zeitpunkt der Erstellung gescannt werden, nicht erst in CI entdeckt werden, nachdem er bereits in einem Pull Request ist. Die IDE ist die erste Verteidigungslinie gegen Schwachstellen in KI-generiertem Code, da hier ein Mensch jede Zeile aktiv betrachtet.
Signal-Rausch-Verhältnis
KI hat das Volumen von Code und Befunden gleichermaßen aufgebläht. Ein Tool, das seine eigene Ausgabe nicht triagieren kann, wird zu einem weiteren Backlog.
LLM-Nutzungsverfolgung
Transparenz darüber, welche Modelle die Anwendung aufruft, damit Shadow AI aufgedeckt wird, bevor ein Auditor oder ein Angreifer sie zuerst findet.
Die besten LLM-Sicherheitstools für KI-Anwendungen
Aikido Security
Aikido Security deckt den gesamten Lebenszyklus von KI-Anwendungen ab. Das beginnt in der IDE, wo KI-generierter Code entsteht, und erstreckt sich bis zur Produktionsumgebung, wo er ausgeführt wird.
Auf der Code-Ebene verbindet das MCP-Plugin von Aikido die Security-Engine von Aikido direkt mit KI-Coding-Tools und führt automatisch SAST und Secrets detection für generierten Code innerhalb der IDE aus. Schwachstellen werden zum Zeitpunkt ihrer Entstehung erkannt, anstatt in einem Pull Request oder, schlimmer noch, in der Produktion aufzutauchen. Safe Chain läuft parallel dazu, blockiert bösartige und halluzinierte npm-Pakete zum Installationszeitpunkt und unterbricht den Slopsquatting-Angriffspfad, bevor ein Paket jemals in Ihrem Dependency Tree landet (eine direkte Entsprechung zu OWASP LLM09).
Auf der Umgebungsebene überwacht Device Protection die Maschinen, auf denen KI-gestützte Entwicklung stattfindet. KI-Coding-Tools verbinden sich mit MCP-Servern, installieren Erweiterungen und laden Pakete herunter, und jeder dieser Vorgänge ist ein Kanal, den ein Angreifer ausnutzen kann. Device Protection erkennt bösartige MCP-Server und kompromittierte Erweiterungen, bevor sie installiert werden.
DSPM befasst sich damit, wo KI-Anwendungsdaten landen. Sensible Kundendaten fließen in Speicher, die traditionelle Tools nicht erfassen, einschließlich Vektordatenbanken und Prompt-Logs, oft ohne vorherige Redaktion. DSPM findet diese Daten ungeschützt, sodass PII sich nicht unbemerkt in der Infrastruktur ansammelt, in die Ihre KI-Funktionen schreiben.
Und in der Produktion bietet Zen In-App LLM Usage Tracking, das genau zeigt, welche KI-Modelle Ihre Anwendung in Echtzeit aufruft, verfolgt, wohin Daten bis auf Regionsebene gehen, und erzwingt die Einhaltung der KI-Nutzungs-Compliance, sodass nicht autorisierte Integrationen sofort sichtbar werden.
Hinter all dem übernimmt AutoTriage die Deduplizierung, Erreichbarkeitsfilterung und Cross-Scanner-Korrelation, die die durch KI erhöhten Fundmengen im Unternehmensmaßstab handhabbar hält.
Und RBAC, SSO und Audit Trails liegen jeder Ebene zugrunde, sodass die Anforderungen an die Unternehmens-Governance erfüllt werden.
Ideal für: Unternehmensteams, die KI-Anwendungssicherheit über den gesamten Entwicklungslebenszyklus hinweg wünschen, mit den von der Governance geforderten RBAC-, SSO- und Audit-Trails.
{{walkthrough}}
Snyk
Die Plattform von Snyk umfasst SAST, SCA, Container- und IaC-Scanning, wobei die DeepCode AI-Engine die Erkennung und KI-generierte Code-Analyse in der IDE antreibt. Im vergangenen Jahr hat sich Snyk als „AI Security Platform“ neu positioniert und Evo AI-SPM für agentisches AI Posture Management, Agent Security zur Steuerung von KI-Agenten über den gesamten Lebenszyklus und Agent Fix für die autonome Behebung in der IDE eingeführt.
Der verlässliche Wert ist immer noch Snyks traditionelle AppSec-Engine, da die meisten dieser KI-Produkte weniger als ein Jahr alt sind und daher noch nicht im Umfang von Snyks traditionellen SAST- und SCA-Engines praxiserprobt wurden. Die üblichen Kompromisse bei Snyk bleiben ebenfalls unverändert. Snyks Fundmenge ist eine häufige Beschwerde, und sein Preismodell funktioniert besser für große Organisationen als für kleine Teams.
Ideal für: Teams, die eine etablierte Plattform mit breiter Sprachunterstützung wünschen und bereit sind, in Snyks wachsende AI Posture Tooling zu investieren. Teams sollten jedoch Zeit für das Tuning einplanen, um die Fundmenge überschaubar zu halten, und mit Enterprise-Preisen rechnen, die nicht für kleinere Organisationen geeignet sind.
Semgrep
Semgreps Stärke sind anpassbare Regeln. Teams können ihre eigene Erkennungslogik für LLM-spezifische Code-Muster schreiben. Semgrep Multimodal, veröffentlicht im März 2026, kombiniert Semgreps deterministische Regel-Engine mit LLM-Reasoning, um den Triage-Aufwand zu reduzieren und Schritt-für-Schritt-Anleitungen zur Behebung in Pull Requests zu generieren. Semgrep Guardian, eingeführt im Mai 2026, ist ein Echtzeit-Sicherheitsscan für KI-generierten Code, der in Claude Code, Cursor, Windsurf, Kiro und anderen agentischen Coding-Tools läuft. Es wird mit drei kuratierten Regelpaketen ausgeliefert, die speziell auf KI-Risiken abzielen.
Der Kompromiss ist der Umfang. Semgrep ist eine Code-Security-Plattform, daher müssen der Schutz der Lieferkette über das Scannen von Paket-Schwachstellen hinaus, die Verteidigung der Entwicklerumgebung, DSPM und das LLM Usage Tracking in der Produktion alle von anderer Stelle kommen. Die regelbasierte Grundlage ist ebenfalls noch ein Faktor. Die Abdeckung hängt davon ab, welche Regelpakete Sie aktivieren und wie Sie sie abstimmen, obwohl die KI-spezifischen Pakete, die Semgrep jetzt ausliefert, viel mehr dieser Arbeit sofort erledigen als früher.
Ideal für: Security Engineering Teams, die ihre eigenen Erkennungsregeln schreiben und abstimmen möchten und sich mit einer code-fokussierten Plattform anstelle einer Full-Stack-Security-Suite wohlfühlen. Sie benötigen jedoch weiterhin eine separate Abdeckung für den Schutz der Lieferkette, Bedrohungen in der Entwicklerumgebung und die Sichtbarkeit der LLM-Nutzung in der Produktion.
Endor Labs
Endor Labs ist eine einheitliche Plattform, die SCA, SAST, Secrets detection, Container-Scanning und Erkennung von schädlichen Software-Paketen über ihre Package Firewall abdeckt. Auf der KI-Seite entdeckt Endor KI-Modelle, die in Ihre Codebasis gezogen werden, generiert AI-BOMs und bietet eine Risikobewertung für Modelle aus öffentlichen Repositories wie Hugging Face. Ihr AURI MCP-Server lässt sich direkt in Cursor, Claude Code, Copilot und andere KI-Coding-Assistenten integrieren, um Code in Echtzeit zu scannen, während er geschrieben wird.
Endor deckt jedoch die Entwicklerumgebung nicht über IDE-Plugins hinaus ab (kein Schutz vor bösartigen MCP-Servern als installierte Bedrohungen), läuft nicht in der Produktion (kein LLM Usage Tracking, kein Laufzeitanwendungsschutz) und bietet kein DSPM.
Am besten geeignet für: Teams, deren primäres KI-Risiko die Open-Source-Lieferkette ist. Wenn Ihre Risiken jedoch KI-generierten Code in der IDE, bösartige MCP-Server auf Entwickelnden-Maschinen oder unautorisierte Modellaufrufe in der Produktion umfassen, benötigen Sie zusätzlich etwas anderes.
Wiz
Wiz betrachtet KI-Sicherheit aus der Cloud heraus. Sein AI-SPM entdeckt KI-Dienste, -Modelle und Trainingsinfrastruktur in Cloud-Umgebungen und kennzeichnet Fehlkonfigurationen und Expositionen. Wiz DSPM erweitert diese Erkennung auf Vektorspeicher und Prompt-Logs, wo sich sensible KI-nahe Daten ansammeln. Wiz Code, eingeführt zur Erweiterung des Entwickelnden-Workflows, deckt SAST, SCA, Secrets detection und IaC-Scan mit IDE-Plugins für VS Code, JetBrains und Lovable ab. Seit dem Abschluss der Google-Akquisition im März 2026 operiert Wiz weiterhin unter seiner eigenen Marke innerhalb von Google Cloud.
Wo die Abdeckung von Wiz schwächer wird, sind die frühesten Punkte der KI-Entwicklungspipeline. Es gibt keine Blockierung bösartiger Pakete zur Installationszeit (Wiz identifiziert sie nachträglich, anstatt sie vor der Installation abzufangen), keinen Schutz für die Entwickelnden-Umgebung vor bösartigen MCP-Servern und kein LLM-Nutzungs-Tracking auf Anfrageebene innerhalb der Anwendung.
Am besten geeignet für: Sicherheitsteams, deren KI-Sicherheitsfrage die Cloud-weite Transparenz ist. Wenn Ihr Ziel jedoch darin besteht, KI-bezogene Schwachstellen zu stoppen, bevor sie die Produktion erreichen (bösartige Pakete vor der Installation blockieren, MCP-Server-Bedrohungen auf Entwickelnden-Maschinen abfangen, Modellaufrufe in der Produktion verfolgen), liegen die Stärken von Wiz weiter stromabwärts, als Sie es wünschen würden.
