In vielen Unternehmen läuft generative KI inzwischen im Hintergrund mit — als Chatbot, als Wissensassistent, im Code-Editor und immer öfter als Agent, der eigenständig Systeme anspricht und Daten abruft. Mit jeder dieser Integrationen wächst eine Angriffsfläche, die vorhandene Sicherheitswerkzeuge allein nicht ausreichend abdecken. Firewall, Authentifizierung und Eingabefilter bleiben notwendig — für LLM-, RAG- und agentenbasierte Systeme genügen sie allein aber nicht. Denn ein Sprachmodell verhält sich nicht wie klassischer deterministischer Anwendungscode: Es interpretiert Sprache, Kontext und Anweisungen probabilistisch. KI-Sicherheit ist damit zu einem eigenen Feld geworden, mit Fehlerklassen, die in klassischen Bedrohungsmodellen gar nicht erst auftauchen.
KI-Sicherheit im Unternehmen bedeutet, LLMs, RAG-Systeme, KI-Agenten, Datenflüsse, Modellzugriffe und automatisierte Aktionen über den gesamten Lebenszyklus hinweg abzusichern — nicht nur den Modell-Endpunkt.
Wie weit der Begriff trägt, zeigt sich schnell. KI-Sicherheit umfasst weit mehr als ein abgesichertes Modell-Hosting: Sie reicht vom Training und der Einbettung der Daten über die Datenanbindung bis zu den Aktionen, die ein Agent für einen Menschen ausführt — und auf dieser Strecke greifen gewohnte Kontrollen nur lückenhaft.
Warum klassische Sicherheitskonzepte bei LLMs an Grenzen stoßen
Entscheidend ist, worauf ein Angriff zielt. SQL-Injection oder eine schlecht gebaute Schnittstelle sitzen im Code. Prompt-Injection sitzt in der Sprache. Das Modell trennt nicht sauber zwischen der Anweisung des Betreibers und einer Anweisung, die irgendwo im verarbeiteten Text auftaucht.
Richtig unangenehm wird die indirekte Spielart. Die direkte Variante muss jemand selbst eintippen; die indirekte kommt huckepack, versteckt in einer E-Mail, einem PDF, einem Ticket oder einer Webseite, die das System sowieso liest. In den gängigen LLM-Sicherheitsmodellen gilt sie nicht als eigene Klasse, sondern als Ausprägung der Prompt-Injection.
Sensitive Information Disclosure beschreibt Inhalte aus dem Kontext, aus Trainingsdaten oder aus angebundenen Systemen, die beim Fragenden nie hätten landen dürfen. Treffen eine manipulierte Eingabe und zu großzügige Datenrechte aufeinander, wird aus der Antwortmaschine ein Abfluss.
Risiken entlang der gesamten KI-Pipeline
Die Schwachstellen ziehen sich durch die ganze Pipeline, von den Daten bis zur Laufzeit. Data & Model Poisoning setzt früh an: Wer Trainings-, Fine-Tuning- oder Einbettungsdaten manipuliert, kann ein Verhalten ins Modell schreiben, das von klassischen Funktionstests oder oberflächlichen Evaluierungen leicht übersehen wird.
Bei RAG-Systemen wandert das Risiko in den Vektorindex. Einmal eingebettet, liegen Dokument-Chunks häufig im selben semantischen Suchraum, und die Rechte aus dem Ursprungssystem werden im Vektorindex oder im Retrieval-Layer oft nicht sauber abgebildet oder durchgesetzt. Reicht man die Berechtigungen nicht bis in den Retrieval-Schritt durch, fördert eine harmlose Frage plötzlich Material zutage, das gut geschützt schien. Belastbar wird das erst mit einer Autorisierung zur Abfragezeit: Zugriffslisten zwischen Quellsystem und Index synchron halten, Metadatenfilter und eine harte Mandantentrennung erzwingen und festhalten, welche Chunks an wen ausgeliefert wurden.
Und dann ist da die Lieferkette. Ein zugekauftes oder nachtrainiertes Modell bringt nicht nur Code mit, sondern Gewichte und Datenannahmen, deren Herkunft sich kaum nachvollziehen lässt. Wer die Herkunft seiner Modelle und Abhängigkeiten nicht kennt und sie nicht inventarisiert, lässt eine Grundlage aus, die in der Praxis oft fehlt.
Zwei weitere Probleme sind organisatorischer Natur. Shadow-AI zuerst, also KI-Werkzeuge ohne Freigabe und ohne Aufsicht; technisch keine Schwachstelle, aber ein blinder Fleck, der mehrere der Risiken verstärkt. Das zweite: Agenten mit zu vielen Rechten. Wer mehr darf, als seine Aufgabe verlangt, koppelt die sprachliche Manipulation an echte Handlungsmacht; im OWASP-Sprech heißt das Excessive-Agency. Für diese Risikoprofile hat das OWASP GenAI Security Project inzwischen eigene Materialien zu agentischen Anwendungen veröffentlicht. Aus einem präparierten Dokument wird mit einem solchen Agenten eine ausgeführte Operation. Dass autonome KI damit insider-ähnliche Risiken erzeugen kann, ist keine Zuspitzung, sondern liegt in der Logik dieser Rechtevergabe — und in einer Governance-Lücke, die in vielen Unternehmen noch klafft.
Technische Schutzmechanismen mit dem größten Hebel
Die Gegenmaßnahmen lassen sich entlang typischer Kontrollbereiche ordnen: Identitäten und Berechtigungen, Eingabe- und Ausgabevalidierung, Laufzeitüberwachung, Logging und Governance. Diese Einteilung ist keine wörtliche Vorgabe eines einzelnen Standards, entspricht aber der Logik aktueller KI-Sicherheitsleitlinien.
Vieles beginnt bei den Rechten. Das Prinzip der minimalen Berechtigung gilt für Modelle und Agenten genauso wie für Benutzerkonten, wird dort aber regelmäßig ignoriert. Konkret: Werkzeuge über Allow-Lists freigeben statt pauschal, kurzlebige Tokens statt Dauerschlüssel, je Agent ein eigenes Service-Konto mit eng gefasstem Scope. Irreversible Schritte gehören hinter eine menschliche Freigabe, schreibende, löschende oder zahlungswirksame Funktionen hinter harte Limits.
Eine Prompt-Validierung am Eingang hilft, ist aber keine Mauer; Sprache lässt sich nicht vollständig filtern. Mehr Verlass bietet die Ausgabeseite. Eine Modellantwort gehört wie nicht vertrauenswürdiger Input behandelt, bevor sie weiterfließt — mit Schema-Validierung, erlaubten Wertebereichen und konsequentem Escaping; alles, was Code oder Befehle erzeugt, läuft in einer Sandbox. Für Aktionen mit Nebenwirkungen tritt ein Freigabe-Workflow dazwischen. Improper-Output-Handling, das Fehlen genau dieser Prüfungen, ist der Moment, in dem aus Text eine Handlung wird.
Bleibt die Nachvollziehbarkeit. Logging und Auditierbarkeit sind die forensische Grundlage — vorausgesetzt, das Protokoll hält das Wesentliche fest: Modellversion und Version des System-Prompts, genutzte Werkzeuge, abgerufene Chunks, den Berechtigungskontext und die Rolle des Nutzers, getroffene Policy-Entscheidungen und ausgeführte Aktionen. Ein laufendes Output-Monitoring schlägt daneben im Betrieb an, bevor eine auffällige Antwort Schaden anrichtet.
Governance und Standards als Rückgrat
Aus Einzelmaßnahmen wird erst mit einem gemeinsamen Bezugsrahmen ein Programm. Die OWASP-Liste liefert das Vokabular: Eine Anwendung lässt sich Punkt für Punkt durchgehen, von Prompt-Injection über Sensitive Information Disclosure bis Supply-Chain und Excessive-Agency. Architekturentscheidungen nimmt sie nicht ab, sorgt aber dafür, dass keine Risikoklasse durchrutscht.
Die organisatorische Klammer kommt vom NIST-AI-Risk-Management-Framework, das als freiwilliger Rahmen für den Umgang mit KI-Risiken gedacht ist. Es sortiert die Arbeit in vier Funktionen: Govern, Map, Measure und Manage. Govern bildet die organisatorische Grundlage; Map, Measure und Manage laufen als wiederkehrende Schleife über den Lebenszyklus. Eine Zertifizierung ist das nicht, sondern ein Vokabular, an dem sich Architektur, Tests und Zuständigkeiten ausrichten lassen.
Solche Rahmenwerke lassen sich als bloße Häkchenliste missbrauchen — oder als roter Faden nutzen, der Technik und Verantwortung verbindet. KI-Sicherheit entsteht ohnehin nicht aus einem einzelnen Guardrail und nicht aus einer Richtlinie, sondern aus mehreren Schichten, von denen jede ausfallen darf, ohne dass gleich alles kippt. Und sie braucht jemanden, dem sie gehört: Solange niemand benannt ist — der CISO, ein AI-Security-Lead, ein Team aus Security und Plattform — bleibt jeder Rahmen Theorie. Praktisch heißt das: erst sehen, was an KI im Haus ist, dann Rechte zusammenstreichen, mitschreiben, was geschieht, und das Ganze an einem schlanken Rahmen ausrichten, den jemand tatsächlich benutzt.
