// Cybersicherheit 20.09.2026 · 18:33 Uhr 12 Min. Lesezeit

KI-Anwendungen absichern: Risiken durch Prompt Injection, RAG und KI-Agenten gezielt prüfen

Mindverse News

KI-gestützt erstellt 6 Quellen Arbeitsweise

KI-Anwendungen absichern: Risiken durch Prompt Injection, RAG und KI-Agenten gezielt prüfen — Symbolbild

Das Wichtigste in Kürze

Ein für Oktober 2026 angekündigter iX-Workshop widmet sich der praktischen Absicherung generativer KI-Anwendungen.
Im Mittelpunkt stehen Angriffe auf Prompt-Schnittstellen, manipulierte Inhalte in RAG-Systemen und übermäßig weitreichende Berechtigungen von KI-Agenten.
Als Übungsobjekt dient ein absichtlich verwundbarer Bank-Chatbot, an dem Teilnehmende Angriffsszenarien analysieren und Schutzmaßnahmen umsetzen.
Der Ansatz verbindet Threat Modeling, kontrollierte Tool-Nutzung, Rechtebegrenzung, Validierung, Guardrails und menschliche Freigaben.
Rund 70 Prozent der Workshopzeit sind laut Veranstalter für praktische Übungen, Live-Angriffe und Härtungsaufgaben vorgesehen.
Das Format richtet sich vor allem an Entwickler, Architekten, AI Engineers, DevSecOps- und Security-Teams sowie technische Verantwortliche.

// Inhalt · 12 Abschnitte

Warum KI-Anwendungen neue Sicherheitskonzepte benötigen
Der angekündigte Workshop im Überblick
Prompt Injection: Wenn Anweisungen zum Angriffspunkt werden
RAG-Systeme: Das Wissensfundament als mögliche Angriffsfläche
KI-Agenten und das Prinzip der geringsten Rechte
Schutzmechanismen im Zusammenspiel
Threat Modeling als Ausgangspunkt
Red Team und Blue Team als Lernmodell
Was Unternehmen aus dem Ansatz ableiten können
Die Rolle von Training und interdisziplinärer Zusammenarbeit
Einordnung für den Einsatz generativer KI im Unternehmen
Fazit
Quellen

Warum KI-Anwendungen neue Sicherheitskonzepte benötigen

Generative KI wird in Unternehmen zunehmend nicht mehr nur für Textentwürfe, Zusammenfassungen oder Recherche eingesetzt. Sprachmodelle greifen auf interne Wissensbestände zu, verarbeiten vertrauliche Informationen und lösen über angebundene Werkzeuge Aktionen aus. Dadurch verändern sich die Anforderungen an die IT-Sicherheit: Eine Anwendung muss nicht mehr ausschließlich gegen klassische Angriffe auf Netzwerk, Betriebssystem oder Weboberfläche geschützt werden. Auch Anweisungen, Wissensquellen, Modellkontext und autonome Handlungsspielräume werden zu sicherheitsrelevanten Komponenten.

Ein für den Herbst 2026 angekündigter iX-Workshop setzt genau an dieser Schnittstelle an. Das Format soll zeigen, wie Unternehmen KI-Anwendungen aus der Perspektive eines Angreifers untersuchen und anschließend gezielt absichern können. Statt die Risiken nur theoretisch zu behandeln, arbeiten die Teilnehmenden mit einem absichtlich verwundbaren Bank-Chatbot. Sie sollen Schwachstellen identifizieren, deren mögliche Auswirkungen bewerten und anschließend Schutzmaßnahmen implementieren.

Der Schwerpunkt liegt damit auf einem iterativen Vorgehen: angreifen, analysieren, nachbessern und erneut testen. Für Unternehmen ist dieser Ansatz insbesondere deshalb relevant, weil KI-Systeme häufig aus mehreren Schichten bestehen. Zum Modell kommen beispielsweise Datenbanken, Suchkomponenten, Benutzer- und Rollenverwaltung, externe APIs sowie Werkzeuge für Aktionen hinzu. Eine Schwachstelle kann daher nicht nur im Sprachmodell selbst liegen, sondern auch in der Art, wie die Anwendung Informationen erhält oder Entscheidungen in technische Befehle übersetzt.

Der angekündigte Workshop im Überblick

Nach den vorliegenden Angaben findet der Online-Workshop vom 26. bis 28. Oktober 2026 jeweils zwischen 9 und 17 Uhr statt. Veranstalter ist das Umfeld der iX-Workshops von heise. Als Trainer wird Gregor Biswanger genannt, der unter anderem als Microsoft MVP für Azure AI und Web-App-Entwicklung ausgewiesen wird.

Das Lernformat ist auf eine technische Zielgruppe zugeschnitten. Angesprochen werden Softwareentwickler, Softwarearchitekten, AI Engineers, DevSecOps- und Security Engineers sowie technische Leads. Im Fokus stehen Teams, die Large Language Models, Retrieval-Augmented-Generation-Anwendungen, Copilots oder KI-Agenten entwickeln, integrieren oder betreiben.

Der praktische Anteil soll laut Workshopbeschreibung ungefähr 70 Prozent der Gesamtzeit ausmachen. Die Übungen finden in einer vorbereiteten Browserumgebung statt. Dadurch lässt sich ein kontrolliertes Szenario bereitstellen, in dem Angriffstechniken nachvollzogen werden können, ohne produktive Unternehmenssysteme zu gefährden. Für die Übertragung auf reale Umgebungen bleibt dennoch entscheidend, dass Teilnehmerinnen und Teilnehmer die Unterschiede zwischen einer Trainingsumgebung und ihrer eigenen Systemarchitektur berücksichtigen.

Als Ergebnis sollen unter anderem ein Threat Model, wiederverwendbare Sicherheitstestfälle und eine Checkliste für die Absicherung eigener KI-Anwendungen entstehen. In einer abschließenden Red-Team-/Blue-Team-Übung wird geprüft, ob die zuvor eingeführten Schutzmechanismen einem erneuten Angriff standhalten.

Prompt Injection: Wenn Anweisungen zum Angriffspunkt werden

Eine der zentralen Gefahren für sprachmodellbasierte Anwendungen ist die sogenannte Prompt Injection. Dabei wird versucht, die Prioritäten oder das Verhalten eines Modells durch speziell formulierte Eingaben zu beeinflussen. Der Angriff kann direkt über eine Benutzereingabe erfolgen. Er kann aber auch indirekt über Inhalte eingeschleust werden, die das System aus Dokumenten, Webseiten, E-Mails oder Wissensdatenbanken abruft.

Das Problem entsteht unter anderem dadurch, dass ein Sprachmodell unterschiedliche Textarten nicht automatisch zuverlässig als getrennte Sicherheitsklassen behandelt. Eine Anweisung des Systemdesigns, eine Anfrage des Nutzers und ein aus einer Datenquelle gelesener Satz können für das Modell alle als Kontext erscheinen. Ohne zusätzliche Kontrollen besteht die Gefahr, dass manipulierte Inhalte als Handlungsanweisung interpretiert werden.

In einem Bank-Chatbot könnte ein solches Szenario beispielsweise dazu führen, dass interne Informationen offengelegt, Richtlinien umgangen oder unerwünschte Folgeaktionen vorbereitet werden. Die tatsächliche Auswirkung hängt davon ab, welche Daten der Chatbot erreichen kann und welche Werkzeuge ihm zur Verfügung stehen. Ein Modell ohne Systemzugriff und ohne Aktionsrechte stellt ein anderes Risiko dar als ein Agent, der Kontodaten abfragen, Überweisungen vorbereiten oder Kundendaten verändern kann.

Warum klassische Eingabefilter allein nicht ausreichen

Einzelne Filter für verdächtige Begriffe oder bestimmte Formulierungen können einen Teil offensichtlicher Angriffe abfangen. Sie bilden jedoch keine vollständige Sicherheitsarchitektur. Angreifer können Formulierungen verändern, Inhalte verschleiern oder die schädliche Anweisung in scheinbar legitime Dokumente einbetten.

Wirksamer ist ein mehrschichtiger Ansatz. Dazu gehören eine klare Trennung von Instruktionen und Daten, eine Begrenzung des Modellkontexts, eine Prüfung der Quelle sowie technische Kontrollen außerhalb des Sprachmodells. Aktionen mit hohem Schadenspotenzial sollten nicht allein von der Textausgabe eines Modells abhängen. Sie benötigen zusätzliche Autorisierungsregeln, Protokollierung und gegebenenfalls eine menschliche Freigabe.

Der Workshop ordnet Prompt Injection deshalb nicht als isoliertes Prompting-Problem ein, sondern als Bestandteil des gesamten Anwendungsdesigns. Diese Perspektive ist für Unternehmen wesentlich: Selbst ein leistungsfähiges Modell kann keine fehlenden Zugriffskontrollen ersetzen.

RAG-Systeme: Das Wissensfundament als mögliche Angriffsfläche

Viele Unternehmensanwendungen kombinieren ein Sprachmodell mit einer Such- oder Wissenskomponente. Bei Retrieval Augmented Generation, kurz RAG, werden relevante Dokumente abgerufen und dem Modell als zusätzlicher Kontext übergeben. Auf diese Weise können Anwendungen mit internen Richtlinien, Produktinformationen, Vertragsunterlagen oder technischen Dokumentationen arbeiten, ohne das Modell für jede Änderung neu zu trainieren.

Die Architektur bringt jedoch eigene Risiken mit sich. Werden Dokumente manipuliert, unzureichend klassifiziert oder mit falschen Berechtigungen gespeichert, kann das System problematische Informationen abrufen und in seine Antwort einbeziehen. Der Angriff richtet sich dann nicht unmittelbar gegen das Modell, sondern gegen die Daten- und Retrieval-Schicht.

Manipulierte RAG-Inhalte können unterschiedliche Ziele verfolgen. Sie können Antworten in eine bestimmte Richtung lenken, interne Regeln überschreiben, vertrauliche Informationen aus anderen Kontexten anfordern oder den Agenten zu einer Aktion auffordern. Auch ein scheinbar harmloser Text in einem Dokument kann problematisch werden, wenn die Anwendung den Inhalt ungeprüft als vertrauenswürdigen Kontext behandelt.

Welche Kontrollen für RAG-Anwendungen relevant sind

Für die Absicherung von RAG-Systemen müssen Unternehmen mehrere Ebenen betrachten. Dazu gehören die Herkunft und Integrität von Dokumenten, die Rechteverwaltung für Wissensbestände sowie die Frage, welche Inhalte ein bestimmter Nutzer überhaupt abrufen darf. Eine technische Suche darf keine Berechtigungslogik umgehen, nur weil ein Sprachmodell die Anfrage formuliert.

Zusätzlich sollten Dokumente und Suchergebnisse auf unerwartete Instruktionen, unzulässige Inhalte und widersprüchliche Metadaten geprüft werden. Die Anwendung sollte nachvollziehbar protokollieren, welche Quellen zu einer Antwort geführt haben. Das erleichtert die Untersuchung von Fehlverhalten und ermöglicht es, problematische Dokumente gezielt aus dem Bestand zu entfernen.

Eine weitere Maßnahme besteht darin, die Rolle des abgerufenen Inhalts eindeutig festzulegen. Dokumente können als Informationsquelle dienen, sollten aber nicht automatisch die Systemregeln oder Berechtigungen der Anwendung verändern dürfen. Diese Trennung muss sowohl auf Anwendungsebene als auch im technischen Kontrollfluss berücksichtigt werden.

KI-Agenten und das Prinzip der geringsten Rechte

Besonders anspruchsvoll wird die Absicherung, wenn ein Sprachmodell nicht nur Antworten erzeugt, sondern selbstständig Werkzeuge aufrufen kann. Solche KI-Agenten können beispielsweise Datenbanken durchsuchen, Tickets erstellen, Dateien bearbeiten oder externe Dienste ansprechen. Damit steigt der potenzielle Nutzen, aber auch das Risiko einer Fehlentscheidung oder einer erfolgreichen Manipulation.

Das zentrale Sicherheitsprinzip ist die Beschränkung der Rechte auf das notwendige Minimum. Ein Agent sollte nur die Werkzeuge und Daten erreichen können, die er für seine konkrete Aufgabe benötigt. Er sollte nicht mit umfassenden administrativen Berechtigungen ausgestattet werden, wenn eine eng begrenzte Leseberechtigung genügt.

Im Workshop wird dieser Aspekt anhand der Berechtigungen des Bank-Chatbots untersucht. Dabei geht es nicht nur darum, welche Tools grundsätzlich vorhanden sind. Relevant ist auch, unter welchen Bedingungen sie aufgerufen werden dürfen, welche Parameter zulässig sind und ob riskante Aktionen bestätigt werden müssen.

Kontrollierte Tool-Aufrufe statt uneingeschränkter Autonomie

Ein sicherer Werkzeugaufruf sollte mehrere Prüfungen durchlaufen. Dazu zählen die Identität und Rolle des Nutzers, der Zweck der Anfrage, die erlaubten Parameter und die möglichen Folgen der Aktion. Besonders sensible Vorgänge sollten in einzelne, überprüfbare Schritte aufgeteilt werden.

Bei einer Finanzanwendung könnte ein Agent beispielsweise Informationen zu einem Konto anzeigen, aber keine Zahlung ohne zusätzliche Bestätigung auslösen. Auch eine vorbereitete Aktion sollte klar von ihrer tatsächlichen Ausführung getrennt werden. Das schafft Kontrollpunkte, an denen Regeln greifen und Menschen eingreifen können.

Die Begrenzung von Werkzeugen ist zudem eine organisatorische Aufgabe. Unternehmen müssen festlegen, welche Prozesse automatisiert werden dürfen und wo verbindliche Freigaben erforderlich sind. Diese Entscheidungen lassen sich nicht allein durch technische Komponenten treffen. Sie hängen auch von regulatorischen Vorgaben, Geschäftsrisiken und der Kritikalität der jeweiligen Anwendung ab.

Schutzmechanismen im Zusammenspiel

Die Workshopbeschreibung nennt mehrere Schutzmaßnahmen, die miteinander kombiniert werden sollen. Dazu gehören Least Privilege, kontrollierte Tool-Aufrufe, die Prüfung von Ein- und Ausgaben, Guardrails sowie Human-in-the-Loop-Verfahren. Keine dieser Maßnahmen beseitigt sämtliche Risiken. Ihre Stärke liegt in der Kombination.

Least Privilege: Die Anwendung erhält nur die Daten- und Systemrechte, die für den vorgesehenen Zweck erforderlich sind.
Kontrollierte Werkzeugnutzung: Jeder Aufruf eines Tools wird auf Berechtigung, Kontext und Parameter geprüft.
Input-Validierung: Eingaben werden auf Format, Inhalt, Umfang und mögliche Missbrauchsmuster untersucht.
Output-Validierung: Antworten und erzeugte Befehle werden kontrolliert, bevor sie an Nutzer oder nachgelagerte Systeme weitergegeben werden.
Guardrails: Technische und logische Leitplanken begrenzen zulässige Themen, Aktionen und Datenflüsse.
Human-in-the-Loop: Menschen geben kritische Aktionen frei oder prüfen Ergebnisse, bevor diese wirksam werden.
Protokollierung: Eingaben, Modellentscheidungen, Quellen, Tool-Aufrufe und Freigaben werden nachvollziehbar dokumentiert.

Die Bedeutung dieser Kombination zeigt sich an einem typischen Fehlerbild: Ein Modell kann zwar eine gefährliche Antwort erzeugen, doch ohne Zugriff auf sensible Daten und ohne Möglichkeit, externe Aktionen auszuführen, bleibt der Schaden begrenzt. Umgekehrt kann ein relativ unspektakulärer Modellfehler gravierende Folgen haben, wenn die Anwendung die Ausgabe ungeprüft als Befehl an ein produktives System weitergibt.

Threat Modeling als Ausgangspunkt

Vor der Implementierung von Schutzmaßnahmen steht die strukturierte Analyse der Anwendung. Ein Threat Model beschreibt, welche Komponenten existieren, welche Daten verarbeitet werden, welche Akteure beteiligt sind und welche Angriffswege realistisch erscheinen. Für KI-Anwendungen muss diese Analyse um modell- und datenbezogene Aspekte ergänzt werden.

Zu den grundlegenden Fragen gehören:

Welche Nutzergruppen greifen auf die Anwendung zu?
Welche vertraulichen oder regulierten Informationen werden verarbeitet?
Welche externen Quellen und Dokumente werden in den Modellkontext übernommen?
Welche Tools kann das System aufrufen?
Welche Aktionen sind nur lesend, welche verändern Daten oder lösen Transaktionen aus?
Wie werden Eingaben, Suchergebnisse und Modellantworten geprüft?
Welche Entscheidungen müssen von einem Menschen bestätigt werden?
Wie werden Sicherheitsereignisse erkannt, aufgezeichnet und untersucht?

Ein Threat Model sollte nicht als einmaliges Dokument betrachtet werden. Jede Änderung am Modell, an der Retrieval-Komponente, an den Datenquellen oder an den Tool-Berechtigungen kann die Risikolage verändern. Auch neue Prompt-Vorlagen oder ein Wechsel des Modellanbieters können Einfluss auf das Verhalten und die Sicherheitsgrenzen der Anwendung haben.

Von der abstrakten Analyse zu testbaren Szenarien

Der praktische Wert eines Threat Models steigt, wenn aus den identifizierten Risiken konkrete Testfälle abgeleitet werden. Ein Testfall sollte beschreiben, welche Eingabe oder Datenmanipulation geprüft wird, welches Verhalten erwartet wird und ab welchem Ergebnis der Test als nicht bestanden gilt.

Für eine RAG-Anwendung kann beispielsweise getestet werden, ob ein Dokument mit eingebetteten Anweisungen die Systemregeln beeinflusst. Für einen Agenten lässt sich prüfen, ob ein Nutzer ohne ausreichende Berechtigung einen schreibenden Tool-Aufruf auslösen kann. Für die Ausgabekontrolle kann untersucht werden, ob sensible Daten in Antworten erscheinen, obwohl sie im jeweiligen Kontext nicht freigegeben sind.

Wiederholbare Tests sind besonders wichtig, weil Schutzmaßnahmen häufig unbeabsichtigte Nebenwirkungen haben. Eine strengere Filterung kann legitime Anfragen blockieren, während eine zu großzügige Freigabe Sicherheitslücken offenlässt. Unternehmen benötigen daher sowohl Sicherheitskennzahlen als auch Kriterien für Verfügbarkeit, Genauigkeit und Nutzerfreundlichkeit.

Red Team und Blue Team als Lernmodell

Die abschließende Red-Team-/Blue-Team-Challenge des Workshops greift ein etabliertes Vorgehen aus der IT-Sicherheit auf. Das Red Team versucht, Schutzmechanismen zu umgehen oder definierte Schwachstellen auszunutzen. Das Blue Team analysiert die Angriffe, verbessert die Konfiguration und bewertet, ob die getroffenen Maßnahmen wirksam sind.

Übertragen auf KI-Anwendungen bedeutet das, dass nicht nur klassische technische Exploits geprüft werden. Auch missverständliche Anweisungen, manipulierte Wissensquellen, missbrauchte Rollen und unerwartete Verkettungen von Tool-Aufrufen können Gegenstand der Tests sein.

Ein solcher Perspektivwechsel hilft, die Differenz zwischen beabsichtigtem und tatsächlichem Systemverhalten sichtbar zu machen. Entwicklerteams testen häufig anhand positiver Beispiele: Das System soll eine Frage beantworten, ein Dokument zusammenfassen oder einen Prozess starten. Sicherheitstests gehen weiter. Sie prüfen, was passiert, wenn Nutzer Regeln umgehen, Datenquellen manipuliert sind oder mehrere harmlose Funktionen in einer unerwarteten Kombination verwendet werden.

Was Unternehmen aus dem Ansatz ableiten können

Die im Workshop behandelten Themen lassen sich in einen allgemeinen Entwicklungs- und Betriebsprozess für KI-Anwendungen übertragen. Für Unternehmen entsteht daraus eine Reihe von Prüfbereichen, die bereits vor dem produktiven Einsatz berücksichtigt werden sollten.

Architektur dokumentieren: Erfassen Sie Modell, Datenquellen, Suchkomponenten, Schnittstellen, Werkzeuge und Berechtigungen in einer übersichtlichen Systemdarstellung.
Datenflüsse nachvollziehen: Prüfen Sie, welche Informationen den Modellkontext erreichen, wo sie gespeichert werden und an welche Systeme Antworten weitergegeben werden.
Rechte begrenzen: Vergeben Sie für Modelle, Agenten und technische Dienste nur die minimal erforderlichen Berechtigungen.
Kritische Aktionen absichern: Trennen Sie das Erstellen einer Handlungsempfehlung von ihrer tatsächlichen Ausführung und verlangen Sie bei Bedarf eine Freigabe.
Quellen kontrollieren: Validieren Sie Herkunft, Aktualität, Integrität und Zugriffsrechte von Dokumenten, die in RAG-Systeme einfließen.
Angriffstests etablieren: Entwickeln Sie wiederholbare Tests für Prompt Injection, Datenabfluss, manipulierte Inhalte und missbräuchliche Tool-Aufrufe.
Monitoring einrichten: Erfassen Sie ungewöhnliche Anfragen, wiederholte Fehlversuche, unerwartete Tool-Aufrufe und Abweichungen vom normalen Nutzungsverhalten.
Prozesse für Vorfälle definieren: Legen Sie fest, wie Zugriffe gesperrt, Datenquellen isoliert und betroffene Nutzer oder Verantwortliche informiert werden.

Für B2B-Anwendungen kommt ein weiterer Faktor hinzu: Die Sicherheitsarchitektur muss mit vertraglichen und regulatorischen Anforderungen vereinbar sein. Unternehmen benötigen Klarheit darüber, welche Daten verarbeitet werden, welche Anbieter beteiligt sind und wie lange Protokolle oder Inhalte gespeichert werden. Ein technisch abgesicherter Agent kann dennoch ungeeignet sein, wenn seine Datenflüsse nicht zu den internen Vorgaben oder den Anforderungen eines Kunden passen.

Die Rolle von Training und interdisziplinärer Zusammenarbeit

Die Absicherung von KI-Anwendungen ist nicht ausschließlich Aufgabe einzelner Security-Spezialisten. Entwickler müssen verstehen, wie Prompt Injection und fehlerhafte Tool-Integration entstehen. Architekten müssen Datenflüsse und Vertrauensgrenzen definieren. Betriebsteams benötigen Überwachungs- und Reaktionsprozesse. Fachabteilungen müssen beurteilen, welche Aktionen geschäftlich kritisch sind und welche Fehlertoleranz vertretbar ist.

Praxisorientierte Trainings können diese Perspektiven zusammenführen. Ein realistisches Szenario erleichtert es, abstrakte Risiken mit konkreten Systementscheidungen zu verbinden. Wenn Teilnehmende einen Angriff zunächst selbst durchführen und anschließend die Gegenmaßnahmen umsetzen, wird sichtbar, welche Kontrollen an welcher Stelle wirken und wo zusätzliche Schutzschichten erforderlich sind.

Für Unternehmen ist dabei die Übertragbarkeit entscheidend. Ein Trainings-Chatbot kann nicht alle Besonderheiten einer produktiven Anwendung abbilden. Die gewonnenen Testfälle, Checklisten und Modellierungsansätze müssen deshalb auf die eigene Architektur angepasst werden. Dazu gehören unter anderem die verwendeten Modelle, Cloud-Dienste, Identitätssysteme, Datenklassifikationen und Geschäftsprozesse.

Einordnung für den Einsatz generativer KI im Unternehmen

Die Ankündigung des Workshops fällt in eine Phase, in der viele Unternehmen generative KI von Pilotprojekten in reguläre Geschäftsprozesse überführen. Mit dieser Entwicklung verschiebt sich die Sicherheitsfrage. Es geht nicht mehr nur darum, ob ein Modell überzeugende Texte erzeugt. Entscheidend ist, ob eine komplette Anwendung verlässlich mit Daten, Berechtigungen und Aktionen umgeht.

Besonders relevant ist die Grenze zwischen Assistenz und Automatisierung. Ein System, das lediglich Vorschläge erstellt, benötigt andere Sicherheitskontrollen als ein Agent, der selbstständig Geschäftsprozesse ausführt. Je größer der Handlungsspielraum, desto wichtiger werden Rechtebegrenzung, Nachvollziehbarkeit und menschliche Kontrollpunkte.

Auch die Qualität der Antworten darf nicht mit Sicherheit verwechselt werden. Ein Modell kann sprachlich präzise und fachlich plausibel wirken, während es dennoch eine nicht autorisierte Information verwendet oder eine riskante Aktion vorbereitet. Sicherheitsprüfungen müssen daher Verhalten, Datenzugriff und Systemwirkung gemeinsam betrachten.

Fazit

Der angekündigte iX-Workshop stellt die offensive Prüfung von KI-Anwendungen in den Mittelpunkt. Anhand eines verwundbaren Bank-Chatbots sollen Teilnehmende nachvollziehen, wie Prompt Injection, manipulierte RAG-Inhalte und zu weit gefasste Agentenrechte zu Sicherheitsproblemen führen können. Anschließend werden die Systeme mit technischen und organisatorischen Maßnahmen schrittweise gehärtet.

Der Ansatz folgt einem Grundprinzip moderner Anwendungssicherheit: Schutzmaßnahmen sollten nicht erst nach einem Vorfall entstehen, sondern bereits während der Architektur- und Entwicklungsphase überprüft werden. Für Unternehmen bedeutet das, KI-Anwendungen als komplexe Systeme mit eigenen Vertrauensgrenzen, Datenflüssen und Berechtigungsmodellen zu behandeln.

Für die Praxis sind insbesondere wiederholbare Tests, Least-Privilege-Konzepte, kontrollierte Tool-Aufrufe, abgesicherte Wissensquellen und definierte menschliche Freigaben relevant. Anbieter wie Mindverse, die KI-Text, Content, Bilder und Recherche in integrierten Arbeitsumgebungen zusammenführen, stehen dabei vor einer ähnlichen Aufgabe wie andere KI-Plattformen: Komfort und Automatisierung müssen mit Transparenz, Zugriffskontrolle und überprüfbaren Sicherheitsprozessen verbunden werden.

Der Workshop liefert dafür ein praxisnahes Trainingsmodell. Ob die erarbeiteten Maßnahmen im jeweiligen Unternehmen wirksam sind, hängt letztlich von der konkreten Architektur, den verarbeiteten Daten, den eingeräumten Rechten und der kontinuierlichen Überprüfung im Betrieb ab.