Wie sichern Unternehmen eigene KI-Chatbots und KI-Agenten gegen Missbrauch ab?
Kurz gesagt
Das Sprachmodell darf nicht die letzte Sicherheitsinstanz sein. Berechtigungen, Freigaben, Transaktionsgrenzen und Tool-Zugriffe müssen außerhalb des Modells durch klassische Systemkontrollen durchgesetzt werden. Wie streng diese Kontrollen ausfallen müssen, hängt vom Systemtyp ab: Ein öffentlicher Chatbot ohne Werkzeuge braucht andere Absicherung als ein Agent mit Zugriff auf CRM, E-Mail oder Zahlungen. Regelmäßiges Red Teaming und ein Kill Switch gehören in jedes Sicherheitskonzept.
Die zentrale Architekturfrage
Die wichtigste Frage lautet nicht „Welches Modell ist am sichersten?“, sondern: Welche nicht vertrauenswürdigen Eingaben sieht das System, auf welche Geheimnisse kann es zugreifen, und welche Aktionen darf es auslösen? OWASP bezeichnet zu weitreichende Funktionalität, Berechtigungen oder Autonomie eines Agenten als „Excessive Agency“ und widmet dem Thema eine eigene Risikoliste für agentische Anwendungen.
Mindestkontrollen für Agenten
Eine belastbare Sicherheitsarchitektur für KI-Agenten sollte mindestens enthalten:
- Getrennte Lese- und Schreibrechte statt pauschaler Vollzugriffe
- Minimale OAuth-/API-Scopes für jede Anbindung
- Allowlisting von Tools und Zielen statt offener Werkzeugnutzung
- Betrags- und Transaktionslimits für alles, was Geld oder Verträge betrifft
- Human Approval vor irreversiblen Aktionen wie Überweisungen oder Datenlöschung
- Keine Geheimnisse im Modellkontext, wenn vermeidbar
- Sandboxed Execution für Code- oder Systemzugriffe
- Vollständige Audit-Logs aller Tool-Aktionen
- Rate Limits und ein funktionierender Kill Switch
Risiko nach Systemtyp
Das Schadenspotenzial unterscheidet sich stark je nach Aufgabe des Systems:
- Ein interner Textassistent ohne Werkzeuge hat niedriges bis mittleres Risiko und braucht in der Regel eine normale Fachprüfung.
- Ein öffentlicher Chatbot ohne Werkzeuge, aber mit hohem Publikumsverkehr, braucht Governance und Kontrollen gegen nicht vertrauenswürdige Inhalte.
- Ein RAG-Assistent mit internen Dokumenten braucht Zugriffskontrolle vor dem Retrieval sowie eine Freigabepflicht für die Ingestion neuer Dokumente.
- Ein E-Mail-Agent mit Lese- oder Schreibrechten braucht Sandboxing und Review, weil eingehende Nachrichten grundsätzlich als nicht vertrauenswürdig gelten müssen.
- Ein Agent mit CRM-Schreibrechten, Rechnungsfunktion oder Zahlungs-/Bankzugriff gilt als sehr hohes Risiko und sollte keine autonome Freigabe für kritische Aktionen erhalten.
Für Rechnungs- und Zahlungsprozesse gilt zusätzlich: Bankverbindungsänderungen gehören konsequent aus dem Agentenpfad entfernt und werden separat mit Vier-Augen-Prinzip geprüft.
RAG-Wissensbasis als Angriffsfläche
Retrieval-Augmented Generation reduziert nicht automatisch Halluzinationen und schafft eine neue Vertrauensschicht: die Wissensbasis selbst. Ein manipuliertes Dokument, das in die Wissensbasis gelangt, kann Retrieval und Modellverhalten beeinflussen, sobald es abgerufen wird. Wirksame Kontrollen sind Provenance der Dokumente, getrennte Schreibrechte, Freigabepflicht bei der Ingestion, Mandantentrennung, Berechtigungsprüfung vor dem Retrieval und Tests mit absichtlich manipulierten Dokumenten. Persistentes Agenten-Memory braucht zusätzlich eigene Schreib-, Review- und Löschregeln, weil eine einmal eingeschleuste Fehlinformation sonst wiederholt wirksam werden kann.
Red Teaming und laufende Prüfung
Sicherheit ist kein einmaliger Test. Red Teaming sollte mindestens direkte und indirekte Prompt Injection, Jailbreaks, RAG- und Memory-Poisoning, Datenexfiltration, Tool-Missbrauch, Privilege Escalation, unsichere Output-Verarbeitung und das Fail-safe-Verhalten des Systems prüfen. Nach jeder Modell-, Tool- oder Rechteänderung sollte erneut getestet werden, weil sich sowohl Angriffstechniken als auch die zugrunde liegenden Modelle laufend weiterentwickeln.