Ihr KI-Assistent beantwortet Fragen, findet Dokumente und bereitet Kundennachrichten vor. Diese Fähigkeiten werfen eine konkrete Geschäftsfrage auf: Welche Informationen könnte er der falschen Person zeigen? Ein Agent mit Zugriff auf E-Mails, CRM und interne Wissensbestände braucht eine gründlichere Prüfung als ein Chatbot mit öffentlichen FAQ. KI-Agenten-Sicherheit beginnt bei den Datenwegen: Wo gelangen Informationen hinein, wer darf sie anfordern und wohin können sie weitergegeben werden? Prüfen Sie diese Grenzen mit nachvollziehbaren Ergebnissen, bevor Sie eine Automatisierung ausweiten.
Beginnen Sie bei den erreichbaren Daten
Erfassen Sie alle verbundenen Systeme und die Datensätze, die jede Verbindung bereitstellt. Dazu gehören Kundenkontaktdaten, individuell verhandelte Preise, Verträge, Supportgespräche, Mitarbeiterinformationen und Zugangsdaten. Trennen Sie öffentliche Inhalte, interne Arbeitsunterlagen und geschützte Kundendaten. Ein Ordner namens privat belegt keinen Zugriffsschutz. Entscheidend sind das verwendete Verbindungskonto, dessen Berechtigungen und die Frage, ob die Anwendung diese Rechte bei jeder Anfrage tatsächlich durchsetzt.
OWASP führt die Offenlegung sensibler Informationen als Risiko von LLM-Anwendungen auf. Übersetzen Sie diese Kategorie in konkrete Fragen für Ihren Betrieb: Könnte ein Kunde das Angebot eines anderen Kunden erhalten? Könnte ein Mitarbeiter Geschäftsführungsunterlagen abrufen? Könnte eine Antwort Zugangsdaten aus einer internen Fehlernotiz wiedergeben? Halten Sie das erwartete Ergebnis jeweils vor der Prüfung fest.
Behandeln Sie eingelesene Inhalte als Daten
Prompt Injection kann in Dokumenten, E-Mails oder Webseiten stecken, die ein Agent verarbeitet. Ein vereinfachtes Supportbeispiel: Eine Kundennachricht enthält neben der eigentlichen Anfrage eine Anweisung, interne Informationen auszugeben. Der Nachrichtentext soll dem Assistenten helfen, das Anliegen zu verstehen. Er darf dadurch weder Berechtigungen verändern noch eine Freigabe zum Versenden vertraulicher Daten ersetzen.
Prüfen Sie deshalb die Grenze zwischen verbindlichen Anweisungen und eingelesenen Quellen. Nutzen Sie harmlose, kontrollierte Beispiele in einer eigenen oder ausdrücklich freigegebenen Testumgebung. Erfundenen Kundendatensätzen und unkritischen Markierungen geben Sie Vorrang vor echten Geheimnissen. Wenn das Modell eine verdächtige Anweisung ablehnt, ist das ein hilfreicher Befund. Es beweist jedoch noch nicht, dass sämtliche anderen Wege zu denselben Daten geschlossen sind.
Prüfen Sie Rechte bereits beim Abruf
Ein System mit Retrieval Augmented Generation, kurz RAG, durchsucht zunächst einen Dokumentenbestand und formuliert anschließend eine Antwort. Prüfen Sie, ob der Dokumentenabruf die Rechte des anfragenden Nutzers berücksichtigt. Eine nachträgliche Antwortfilterung bietet eine schwächere Grenze, wenn geschützte Inhalte bereits im Arbeitskontext des Agenten liegen. Der relevante Prüfpunkt liegt also vor der Formulierung der Antwort.
Legen Sie zwei Testnutzer mit unterschiedlichen Rechten an und stellen Sie vergleichbare Fragen. Kontrollieren Sie die gefundenen Dokumentkennungen, die Antwort und sämtliche Quellen- oder Downloadlinks. Prüfen Sie auch Zusammenfassungen und Anschlussfragen, nicht nur direkte Dateianfragen. Speichert der Agent einen Gesprächsverlauf, wiederholen Sie die Prüfung nach einem Nutzer- oder Sitzungswechsel. Frühere Abrufe dürfen einem anderen Nutzer keinen zusätzlichen Zugang eröffnen.
Begrenzen Sie Werkzeuge und Versandziele
OWASPs Hinweise zu übermäßiger Handlungsfreiheit behandeln unnötige Funktionen, Rechte und Autonomie. Vergleichen Sie jedes aktivierte Werkzeug mit seiner eigentlichen Aufgabe. Ein Assistent zum Entwerfen von Nachrichten braucht nicht automatisch Versandrechte. Eine Dokumentensuche benötigt nicht automatisch eine Löschfunktion. Entfernen Sie ungenutzte Fähigkeiten und trennen Sie lesenden Zugriff von Aktionen, die Kundendaten oder Geschäftsprozesse verändern.
Definieren Sie zulässige Empfänger und Ziele für E-Mails, Uploads, Webhooks und API-Aufrufe außerhalb der Modellanweisungen. Für folgenreiche Aktionen ist eine passende menschliche Freigabe sinnvoll. Prüfen Sie beim Model Context Protocol, kurz MCP, jeden angeschlossenen Server und seine Werkzeuge einzeln. Der Protokollname sagt nichts über deren Rechte aus. Dokumentieren Sie außerdem, wer neue Verbindungen genehmigt und wer sie sofort abschalten kann.
Beziehen Sie Protokolle und Fehlerfälle ein
Untersuchen Sie auch, was nach einer Antwort passiert. Sensible Informationen können in Anwendungsprotokollen, Fehlermeldungen, Gesprächsexporten und externen Überwachungsdiensten landen. Legen Sie fest, welche Angaben der Betrieb wirklich benötigt, und entfernen oder maskieren Sie die übrigen. Protokolle brauchen eigene Zugriffsregeln und festgelegte Aufbewahrungszeiten. Eine Information kann im Chatfenster fehlen und trotzdem in einem nachgelagerten System gespeichert werden.
Führen Sie ein überschaubares Prüfregister mit Szenario, Testkonto, gewünschter Aktion, erwartetem Ergebnis, tatsächlichem Ergebnis und Korrektur. Berücksichtigen Sie normale Aufgaben, abgelehnte Zugriffe, Verbindungsfehler und versuchte Umleitungen. Wiederholen Sie nach jeder Korrektur den ursprünglich fehlgeschlagenen Fall sowie eine benachbarte legitime Aufgabe. So prüfen Sie sowohl die neue Grenze als auch den weiterhin funktionierenden Arbeitsablauf.
Verlangen Sie einen Bericht mit klaren Maßnahmen
Ein Audit für KI-Agenten sollte Umfang und Grenzen nennen, reproduzierbare Nachweise liefern und jedem Befund eine verantwortliche Person zuordnen. Ein brauchbarer Bericht erklärt, welche Informationen gefährdet sind, über welchen Weg sie erreichbar wurden und welche technische Kontrolle diesen Weg schließt. Ein einzelner Punktwert hilft Ihrem Team dabei wenig. Auch eine bestandene Prüfung ersetzt keine erneute Bewertung nach neuen Verbindungen, Rollen oder Funktionen.
Notieren Sie für jede Korrektur außerdem einen Termin und den Nachweis, mit dem Sie ihren Erfolg beurteilen. Falls mehrere Teams beteiligt sind, benennen Sie eine Person, die offene Punkte zusammenführt. Ein gefundener Fehler bleibt ein offener Befund, bis seine Behebung geprüft wurde. Vermerken Sie Ausnahmen mit Begründung und Ablaufdatum, damit vorübergehende Zugriffsrechte nicht unbeabsichtigt dauerhaft bestehen bleiben. Planen Sie die Kontrolle außerdem nach Änderungen an Datenquellen oder Werkzeugen fest ein. Eine neue Verbindung kann den geprüften Umfang erweitern, auch wenn sich die Oberfläche kaum verändert. Halten Sie daher fest, welche Version bewertet wurde und welche Konfiguration tatsächlich betrieben wird. So kann Ihr Team spätere Änderungen gezielt mit den dokumentierten Grenzen vergleichen.
Besprechen Sie Ihre Datenquellen und Agentenfunktionen über unseren Service für KI-Agenten-Sicherheit. Für die öffentliche Website erklärt unser Beitrag über KI-Supercrawler und sensible Daten die ergänzenden Schutzmaßnahmen. Weitere praktische Beiträge finden Sie bei Blackcarrot Tech auf Facebook. Beginnen Sie mit einem klar abgegrenzten Arbeitsablauf und einem Bericht, dessen Verbesserungen Ihr Team tatsächlich überprüfen und nachverfolgen kann.