LLM-Sicherheit bedeutet längst nicht mehr nur, unsichere Prompts zu blockieren. Wenn ein LLM Teil eines agentischen Workflows wird, kann es Dokumente abrufen, APIs aufrufen, Datensätze aktualisieren oder Geschäftsprozesse auslösen. Dadurch verschiebt sich das Sicherheitsmodell von „den Chat schützen“ zu „das Handlungssystem rund um das Modell schützen“.
Wenn Ihr Team eine breitere agentische KI in der Produktion plant, sollte LLM-Sicherheit als Release-Gate behandelt werden, nicht als abschließende Checkliste. Für EU/US-Teams bedeutet das, vor dem Launch über Prompt Injection, sicheren Tool-Zugriff, Datenresidenz, Auditierbarkeit, menschliche Aufsicht, Tests und Produktions-Monitoring nachzudenken.
Das Risiko ist nicht mehr theoretisch. Der 2025 AI Index von Stanford HAI meldete 233 KI-bezogene Vorfälle im Jahr 2024, ein Rekordhoch und ein Anstieg um 56,4 % gegenüber 2023. IBMs 2025 Cost of a Data Breach Report stellte außerdem fest, dass 13 % der Organisationen Sicherheitsverletzungen mit KI-Modellen oder -Anwendungen meldeten; unter den kompromittierten Organisationen fehlten 97 % geeignete KI-Zugriffskontrollen.
Dieser Leitfaden erläutert die praktischen Kontrollen, die Teams benötigen, um LLM-gestützte Agenten sicher auszuliefern.
Wichtigste Erkenntnisse
- LLM-Sicherheit umfasst Prompts, Tools, Daten, Logs, Menschen, Anbieter und Monitoring.
- Agentische KI erhöht das Sicherheitsrisiko, weil sie Aktionen ausführen kann und nicht nur Text generiert.
- Prompt Injection braucht mehrschichtige Abwehrmaßnahmen, nicht allein einen stärkeren System-Prompt.
- Sicheres Tool Calling hängt von Zugriff nach dem Need-to-know-Prinzip, Validierung, Sandboxing und Audit-Logs ab.
- Datenresidenz muss für EU/US-Bereitstellungen in die Architektur eingeplant werden.
- HITL-Kontrollen sollten risikobasiert, auditierbar und operativ realistisch sein.
- Tests und Monitoring müssen nach dem Produktions-Release fortgesetzt werden.
Was LLM-Sicherheit für agentische KI bedeutet
LLM-Sicherheit ist umfassender als Prompt-Sicherheit
LLM-Sicherheit ist die Praxis, LLM-gestützte Systeme vor Datenlecks, Prompt Injection, unbefugter Tool-Nutzung, unsicheren Ausgaben und Compliance-Verstößen zu schützen.
Bei einem einfachen Chatbot konzentriert sich Sicherheit möglicherweise vor allem auf Prompts, Ausgaben und Nutzerdaten. Bei einem agentischen KI-System ist der Umfang größer. Das System kann Folgendes umfassen:
- Ein Modell oder mehrere Modelle
- System-Prompts und Policies
- RAG-Pipelines und Vektordatenbanken
- APIs und Business-Tools
- Speicher oder Sitzungskontext
- Logs und Monitoring-Systeme
- Workflows für menschliche Freigaben
- Drittanbieter für Modelle oder Infrastruktur
Eine sichere LLM-Anwendung ist nicht nur ein sicherer Prompt. Sie ist eine sichere Architektur rund um das Modell.
Warum agentische Systeme das Risikoniveau erhöhen
Agentische KI verändert das Risikoprofil, weil das Modell Aktionen beeinflussen kann. Anstatt nur eine Frage zu beantworten, kann ein Agent:
- Interne Dokumente durchsuchen
- Eine CRM-API aufrufen
- Ein Ticket aktualisieren
- Eine E-Mail auslösen
- Code generieren
- Kundendatensätze analysieren
- Daten zwischen Tools weitergeben
- Workflow-Schritte empfehlen oder ausführen
Das bedeutet, dass eine schlechte Anweisung, ein unsicheres Retrieval-Ergebnis, übermäßige Berechtigungen oder eine schwache Validierungsschicht echte operative Auswirkungen haben können. Der Fehlermodus lautet nicht mehr nur „die Antwort war falsch“. Er kann zu „die falsche Aktion wurde ausgeführt“ werden.
Sicherheitsziele für produktive LLM-Agenten
Für produktive LLM-Agenten sollten Sicherheitsziele explizit sein. Mindestens sollten Teams darauf abzielen:
- Unbefugten Datenzugriff zu verhindern
- Lecks sensibler Daten zu verhindern
- Unsichere oder unbefugte Tool-Nutzung zu verhindern
- Audit-Logs für wichtige Aktionen zu führen
- Menschliche Freigaben für Hochrisiko-Workflows anzuwenden
- Anormales Verhalten früh zu erkennen
- Incident Response und Rollback zu unterstützen
- Änderungen an Modell, Prompt und Tools nachvollziehbar zu halten
Diese Ziele helfen Sicherheits-, Produkt- und Engineering-Teams zu bewerten, ob ein Agent produktionsreif ist.
Bedrohungsmodell: Wo LLM-Agenten in der Produktion scheitern
Threat Modeling gibt Teams eine praktische Möglichkeit zu verstehen, wie ein LLM-Agent scheitern kann, bevor diese Fehler Kunden, Mitarbeitende oder regulierte Daten betreffen.
IBMs Bericht von 2025 stellte fest, dass 60 % der KI-bezogenen Sicherheitsvorfälle zu kompromittierten Daten führten und 31 % operative Störungen verursachten. Für agentische KI sind diese Zahlen wichtig, weil ein kompromittierter Agent sowohl die Offenlegung von Informationen als auch die Kontinuität von Geschäftsprozessen beeinträchtigen kann.
Vertraulichkeitsrisiken
Vertraulichkeitsrisiken entstehen, wenn sensible Informationen dem falschen Nutzer, Tool, Anbieter, Log oder nachgelagerten System offengelegt werden.
Häufige Beispiele sind:
- PII, die unnötig in Prompts enthalten sind
- Secrets oder Zugangsdaten, die in Logs erscheinen
- RAG-Retrieval, das Dokumente offenlegt, auf die ein Nutzer keinen Zugriff haben sollte
- Modellausgaben, die verborgene Systemanweisungen preisgeben
- Anbietereinstellungen, die sensible Prompts länger als erwartet aufbewahren
- Interne Daten, die ohne klare Freigabe an externe Dienste gesendet werden
Die praktische Kontrolle beginnt mit Datenklassifizierung. Teams müssen wissen, auf welche Daten der Agent zugreifen kann, wo diese Daten verarbeitet werden und wer die Ausgabe sehen kann.
Integritätsrisiken
Integritätsrisiken entstehen, wenn das Verhalten, die Schlussfolgerungen oder die Aktionen des Agenten manipuliert werden.
In LLM-Systemen zeigt sich Integritätsrisiko oft als Prompt Injection. In agentischen Systemen kann es weiter gehen:
- Ein bösartiges Dokument weist den Agenten an, frühere Anweisungen zu ignorieren.
- Eine Tool-Antwort enthält Text, den das Modell als neuen Befehl behandelt.
- Ein Nutzer bringt den Agenten dazu, eine nicht autorisierte Funktion aufzurufen.
- Der Agent ändert einen Datensatz auf Grundlage ungeprüfter Informationen.
- Ein RAG-Ergebnis verändert den Entscheidungsweg des Agenten.
Integritätskontrollen sollten darauf ausgerichtet sein, vertrauenswürdige Anweisungen von nicht vertrauenswürdigen Inhalten zu trennen, Tool-Aufrufe zu validieren und Policy-Prüfungen vor sensiblen Aktionen anzuwenden.
Verfügbarkeits- und Kostenrisiken
LLM-Agenten können auch Verfügbarkeits- und Kostenprobleme verursachen. Zum Beispiel:
- Ein Agent gerät in eine wiederholte Schleife.
- Tool-Aufrufe steigen unerwartet stark an.
- Die Token-Nutzung wächst über das Budget hinaus.
- Ein Modell- oder Anbieterausfall unterbricht einen Workflow.
- Eine fehlerhafte Eingabe verursacht wiederholte Wiederholungsversuche.
- Ein Schritt mit hoher Latenz blockiert einen Geschäftsprozess.
Dies wird manchmal als „Denial of Wallet“ bezeichnet, wenn übermäßige Modellnutzung unerwartete Kosten verursacht. Produktive Agenten brauchen Rate Limits, Timeouts, Retry-Limits, Budgetkontrollen und Warnmeldungen.
Compliance-Risiken
Bei EU/US-Bereitstellungen entstehen Compliance-Risiken häufig durch unklare Datenverarbeitung und schwache Governance.
Beispiele sind:
- Kein dokumentierter Datenfluss
- Unklare Verarbeitungsregion
- Schwache Aufbewahrungseinstellungen für Prompts und Logs
- Kein Audit Trail für Hochrisiko-Aktionen
- Keine menschliche Aufsicht für sensible Workflows
- Keine Prüfung von Anbietern/Subprozessoren
- Kein Incident-Response-Plan für KI-bezogene Fehler
Sicherheits- und Compliance-Teams sollten diese Risiken vor dem Launch prüfen, nicht erst nachdem der Agent bereits in Geschäftsworkflows eingebettet ist.
Kontrollen gegen Prompt Injection und indirekte Injection
Direkte Prompt Injection
Direkte Prompt Injection tritt auf, wenn ein Nutzer absichtlich versucht, die Anweisungen des Modells zu manipulieren. Der Nutzer kann das Modell auffordern, Systemregeln zu ignorieren, verborgenen Kontext offenzulegen, Policies zu umgehen oder Aktionen außerhalb des erlaubten Umfangs auszuführen.
Bei einem einfachen Chatbot kann direkte Injection zu einer unsicheren oder falschen Antwort führen. Bei einem KI-Agenten kann sie zu Tool-Missbrauch, Datenoffenlegung oder unbefugter Workflow-Ausführung führen.
OWASP führt Prompt Injection in seinen OWASP Top 10 for LLM Applications als ein zentrales Risiko für LLM-Anwendungen auf. Deshalb sollten Injection-Tests Teil des Release-Prozesses für jeden LLM-Workflow sein, der sensible Daten oder Geschäftsaktionen verarbeitet.
Indirekte Prompt Injection
Indirekte Prompt Injection tritt auf, wenn bösartige Anweisungen in Inhalten verborgen sind, die der Agent liest. Diese Inhalte können stammen aus:
- Webseiten
- E-Mails
- Hochgeladenen Dateien
- PDFs
- Tickets
- Chat-Transkripten
- RAG-Ergebnissen
- Tool-Antworten
- Geteilten Dokumenten
Dies ist besonders wichtig für agentische KI, weil Agenten häufig externe oder halb vertrauenswürdige Inhalte konsumieren, bevor sie entscheiden, was als Nächstes zu tun ist.
Warum indirekte Injection für Agenten gefährlich ist
Indirekte Injection ist gefährlich, weil die bösartige Anweisung nicht direkt vom Nutzer kommt. Sie erscheint innerhalb von Daten, die der Agent verarbeiten soll.
Ein Agent kann zum Beispiel ein Support-Ticket lesen, das versteckte Anweisungen enthält, interne Richtlinien offenzulegen, ein Prioritätsfeld zu ändern oder ein anderes Tool aufzurufen. Wenn das System abgerufene Inhalte als vertrauenswürdige Anweisung behandelt, kann der Agent ihr folgen.
Das Kernprinzip ist einfach: Externe Inhalte sollten als Daten behandelt werden, nicht als Autorität.
Abwehrkontrollen
Die Minderung von Prompt Injection sollte mehrschichtige Kontrollen nutzen:
- Systemanweisungen von Nutzer- und Tool-Inhalten trennen.
- Abgerufene Dokumente als nicht vertrauenswürdige Daten behandeln.
- Tool-Allowlists statt offenen Tool-Zugriffs verwenden.
- Tool-Argumente serverseitig validieren.
- Strukturierte Ausgaben für Tool-Aufrufe verlangen.
- Policy-Prüfungen vor sensiblen Aktionen ergänzen.
- Berechtigungen des Agenten nach Rolle und Workflow begrenzen.
- Externe Inhalte vor der Nutzung bereinigen oder isolieren.
- Freigabe-Gates für Aktionen mit hoher Auswirkung ergänzen.
- Verdächtige Prompt-Muster und blockierte Versuche überwachen.
Keine einzelne Kontrolle reicht aus. Ein starker System-Prompt hilft, sollte aber nicht die einzige Sicherheitsgrenze sein.
Worauf man sich nicht allein verlassen sollte
Teams sollten vermeiden, sich ausschließlich zu verlassen auf:
- Einen generischen System-Prompt nach dem Muster „brich nicht die Regeln“
- Keyword-Filter
- Manuelle Prüfung ohne Logs
- Eine einzelne Modell-Sicherheitseinstellung
- Vertrauen in alle RAG-Inhalte
- Breite API-Berechtigungen für den Agenten
- Die Annahme, dass Nutzer keine adversarialen Eingaben versuchen
LLM-Sicherheit sollte davon ausgehen, dass Prompts, abgerufene Inhalte und Tool-Ausgaben manipuliert werden können.
Sicheres Tool Calling und Zugriff nach dem Need-to-know-Prinzip
Warum Tool Calling das Sicherheitsmodell verändert
Tool Calling ist einer der größten Unterschiede zwischen einem normalen LLM-Chatbot und einem agentischen KI-System.
Ein Chatbot erzeugt Text. Ein Agent mit Tools kann Nebenwirkungen erzeugen. Er kann eine Datenbank durchsuchen, eine E-Mail senden, ein CRM-Feld aktualisieren, ein Support-Ticket erstellen, ein Skript ausführen oder einen internen Workflow auslösen.
Das bedeutet, dass Modellausgaben zu möglichen Systemaktionen werden. Sicherheitskontrollen müssen die Aktionsschicht schützen, nicht nur die Textebene.
Häufige Tool-Calling-Risiken in der Produktion
Häufige Risiken sind:
- Der Agent ruft ein Tool auf, auf das er keinen Zugriff haben sollte.
- Der Agent sendet sensible Daten an das falsche Tool.
- Der Agent verwendet richtige Tools mit unsicheren Argumenten.
- Der Agent wiederholt Tool-Aufrufe und verursacht Kosten- oder Verfügbarkeitsprobleme.
- Eine Tool-Antwort enthält bösartige Anweisungen.
- Ein Tool hat breitere Berechtigungen, als der Workflow benötigt.
- Secrets werden dem Modell durch Prompts oder Tool-Ausgaben offengelegt.
- Eine Tool-Aktion kann nicht auf einen Nutzer, Agenten oder eine Freigabe zurückgeführt werden.
OWASP hebt auch Excessive Agency als wichtiges Risiko für LLM-Anwendungen hervor, insbesondere für Systeme, die Tools aufrufen oder mit externen Systemen interagieren können. Das Problem liegt häufig in übermäßiger Funktionalität, übermäßigen Berechtigungen oder übermäßiger Autonomie. Das lässt sich direkt auf produktive Agenten mit breitem Tool-Zugriff übertragen.
Zugriff nach dem Need-to-know-Prinzip für LLM-Agenten
Zugriff nach dem Need-to-know-Prinzip bedeutet, dass der Agent nur die Berechtigungen haben sollte, die er für eine bestimmte Aufgabe benötigt.
Ein Agent, der Antworten für den Kundensupport entwirft, benötigt zum Beispiel möglicherweise Lesezugriff auf die Ticket-Historie, aber keine Berechtigung, Rückerstattungen auszustellen, Konten zu löschen oder Abrechnungsdaten zu ändern. Wenn eine Aktion risikoreich ist, sollte der Agent sie entwerfen oder empfehlen, während ein Mensch sie freigibt.
Ein praktisches Modell für Zugriff nach dem Need-to-know-Prinzip sollte definieren:
- Welche Tools der Agent verwenden kann
- Welche Operationen erlaubt sind
- Welche Datenbereiche erlaubt sind
- Welche Nutzer oder Rollen den Workflow auslösen können
- Welche Aktionen eine Freigabe erfordern
- Welche Aktionen vollständig blockiert sind
Jeder Agent sollte nach Möglichkeit eine eigene Service-Identität haben. Vermeiden Sie es, einem Agenten breiten Zugriff über gemeinsame Admin-Zugangsdaten zu geben.
Tool-Allowlists, Scopes und Policy-Prüfungen
Produktive Agenten sollten nicht aus unbegrenzten Tools wählen. Tool-Zugriff sollte per Allowlist eingeschränkt und auf Scopes begrenzt sein.
Nützliche Kontrollen sind:
- Tool-Allowlists nach Agententyp
- API-Scopes nach Workflow
- Rate Limits pro Tool
- Policy-Prüfungen vor der Ausführung
- Trennung der Umgebungen zwischen Entwicklung, Staging und Produktion
- Freigabeprüfungen für sensible Operationen
- Deny-by-default-Verhalten, wenn der Kontext unklar ist
Eine Policy-Schicht kann entscheiden, ob ein Tool-Aufruf erlaubt ist, bevor die Aktion ausgeführt wird. Das ist besonders nützlich für Aktionen mit Kundendaten, finanziellen Auswirkungen, rechtlichen Auswirkungen, Sicherheitsauswirkungen oder externer Kommunikation.
Argumentvalidierung und Ausgabevalidierung
Tool-Aufrufe sollten strukturierte Schemas verwenden. Der Agent sollte keine beliebigen Freitext-Argumente an sensible APIs übergeben.
Zum Beispiel:
- IDs sollten erwarteten Formaten entsprechen.
- Beträge sollten innerhalb genehmigter Grenzen liegen.
- E-Mail-Empfänger sollten erlaubten Domains oder verifizierten Kontakten entsprechen.
- Dateipfade sollten innerhalb erlaubter Speicherorte bleiben.
- Tool-Aufrufe sollten geschlossen fehlschlagen, wenn Pflichtfelder fehlen.
Tool-Ausgaben sollten ebenfalls sorgfältig behandelt werden. Eine Tool-Antwort kann nicht vertrauenswürdigen Text, fehlerhafte Daten oder eingeschleuste Anweisungen enthalten. Das Modell sollte Tool-Ausgaben als Daten verwenden, nicht als neue Autoritätsquelle.
Sandboxing von Hochrisiko-Tools
Einige Tools benötigen Isolation. Beispiele sind:
- Codeausführung
- Web-Browsing
- Dateiverarbeitung
- Dokumentenaufnahme
- Datentransformation
- Workflow-Automatisierung mit externen Nebenwirkungen
Sandboxing hilft, Schäden zu begrenzen, wenn sich der Agent unerwartet verhält. Je nach Anwendungsfall kann Sandboxing Netzwerkbeschränkungen, Dateisystemgrenzen, Ausführungs-Timeouts, Speicherlimits, separate Zugangsdaten und eingeschränkte Umgebungen umfassen.
Secrets Management für Agenten-Workflows
Secrets sollten nicht in Prompts, Modellkontext oder Klartext-Logs platziert werden. Agenten sollten nur über sichere Backend-Dienste auf Secrets zugreifen.
Gute Praktiken sind:
- Secrets in einem Secrets Manager speichern.
- Zugangsdaten aus Prompt-Templates heraushalten.
- Secrets aus Logs redigieren.
- Zugangsdaten regelmäßig rotieren.
- Nach Möglichkeit kurzlebige Tokens verwenden.
- Zugangsdaten nach Umgebung trennen.
- Vermeiden, rohe API-Schlüssel in Modellausgaben oder Tool-Antworten offenzulegen.
Das Modell sollte eine Aktion anfordern, aber das Backend sollte Autorisierung durchsetzen und den sicheren Vorgang ausführen.
Audit-Logging für Tool-Aufrufe
Jeder wichtige Tool-Aufruf sollte protokolliert werden. Logs sollten helfen, folgende Fragen zu beantworten:
- Welcher Nutzer hat den Workflow ausgelöst?
- Welcher Agent hat die Entscheidung getroffen?
- Welches Tool wurde aufgerufen?
- Welche Aktion wurde angefordert?
- Wurde die Aktion freigegeben?
- Was war das Ergebnis?
- Waren sensible Daten beteiligt?
- Wurde die Aktion blockiert, erneut versucht oder zurückgerollt?
Für EU/US-Unternehmensumgebungen ist Auditierbarkeit oft genauso wichtig wie Prävention. Wenn etwas schiefgeht, muss die Organisation rekonstruieren können, was passiert ist.
Datenresidenz und Datenschutz für EU/US-Bereitstellungen
Mit einer Datenkarte beginnen
Datenresidenz beginnt damit, den Datenfluss zu verstehen. Bevor Teams einen Modellanbieter oder eine Architektur auswählen, sollten sie abbilden:
- Welche Daten in den Prompt eingehen
- Welche Daten aus internen Systemen abgerufen werden
- Welche Daten an Modellanbieter gesendet werden
- Welche Daten in einer Vektordatenbank eingebettet werden
- Welche Daten protokolliert werden
- Wie lange Daten aufbewahrt werden
- Welche Region jede Komponente verarbeitet oder speichert
- Welche Anbieter oder Subprozessoren beteiligt sind
Ohne Datenkarte werden Sicherheits- und Compliance-Prüfungen zu Vermutungen.
IBM berichtete außerdem, dass 63 % der von Sicherheitsverletzungen betroffenen Organisationen entweder keine KI-Governance-Policy hatten oder noch an einer arbeiteten. Bei EU/US-Bereitstellungen zeigt sich diese Governance-Lücke häufig als unklare Datenflüsse, schwache Aufbewahrungsentscheidungen, unvollständige Anbieterprüfung oder fehlende Kontrollen rund um Shadow AI.
EU-Überlegungen
Für EU-Bereitstellungen müssen Teams häufig Datenschutzprinzipien wie Datenminimierung, Zweckbindung, Zugriffskontrolle, Aufbewahrung und Prüfung grenzüberschreitender Übermittlungen berücksichtigen. Konkrete Pflichten hängen von Organisation, Anwendungsfall, Datentyp und Rechtsgrundlage ab.
Praktische Architekturfragen sind:
- Können sensible Daten vor der Prompt-Erstellung minimiert werden?
- Kann Inferenz regional festgelegt werden?
- Werden Logs in der richtigen Region gespeichert?
- Gelten Embeddings in diesem Anwendungsfall als sensibel?
- Können Kundendaten vom Anbietertraining ausgeschlossen werden?
- Sind Lösch- und Aufbewahrungseinstellungen konfigurierbar?
Juristische Auslegungen sollten vor Veröffentlichungs- oder Implementierungsentscheidungen von qualifizierten Rechtsberaterinnen und Rechtsberatern geprüft werden.
US-Überlegungen
US-Bereitstellungen können je nach Branche sektorspezifische Erwartungen mit sich bringen. Gesundheitswesen, Finanzwesen, Bildung, öffentlicher Sektor und Enterprise-SaaS-Umgebungen haben häufig strengere Erwartungen an Zugriffskontrollen, Audit-Logs, Aufbewahrung und Vendor Risk Management.
Selbst wenn eine Regulierung LLMs nicht ausdrücklich erwähnt, erwarten Käufer möglicherweise Sicherheitskontrollen, die an Unternehmensframeworks wie SOC 2 oder ISO/IEC 27001 ausgerichtet sind.
Architekturmuster für residenzsensible LLM-Systeme
Häufige Muster sind:
- Regionsspezifische Modell-Endpunkte
- Regionsspezifische Vektorspeicher
- Private Vernetzung, sofern verfügbar
- Vom Kunden verwaltete Verschlüsselungsschlüssel
- Datenmaskierung vor Modellaufrufen
- PII-Erkennung vor der Prompt-Erstellung
- Getrennte EU- und US-Umgebungen
- Kurze Aufbewahrungsfenster für Prompts und Ausgaben
- Logging-Tiers, die operative Metadaten von sensiblen Inhalten trennen
- Zugriffskontrollen für Embeddings und abgerufene Dokumente
Das Ziel ist, unnötige Datenbewegungen zu reduzieren und unvermeidbare Datenbewegungen sichtbar, kontrolliert und dokumentiert zu machen.
Checkliste für Anbieter-Due-Diligence
Vor der Nutzung eines LLM-Anbieters oder KI-Infrastrukturanbieters sollten Teams fragen:
- Wo werden Daten verarbeitet?
- Wo werden Daten gespeichert?
- Werden Kundendaten für Training verwendet?
- Welche Aufbewahrungskontrollen sind verfügbar?
- Welche Subprozessoren sind beteiligt?
- Werden Sicherheitskontrollen für Unternehmen unterstützt?
- Sind Audit-Logs verfügbar?
- Können Daten auf Anfrage gelöscht werden?
- Sind private Vernetzung oder regional festgelegte Optionen verfügbar?
- Was passiert während der Incident Response?
Anbietereinstellungen können die Sicherheitslage eines LLM-Systems wesentlich verändern. Sie sollten vor dem Produktionseinsatz geprüft werden.
HITL-Kontrollen: Menschliche Aufsicht, ohne Geschwindigkeit zu verlieren
HITL sollte risikobasiert sein
Human-in-the-Loop bedeutet nicht, dass jede Agentenaktion eine manuelle Freigabe benötigt. Das würde die meisten Workflows zu langsam machen. Es bedeutet auch nicht, dass jede Aktion automatisiert werden sollte.
Der richtige Ansatz ist risikobasiert. Niedrigrisiko-Aktionen können protokolliert und überwacht werden. Mittelrisiko-Aktionen benötigen möglicherweise Stichproben, regelbasierte Prüfungen oder Freigaben unter bestimmten Bedingungen. Hochrisiko-Aktionen sollten eine ausdrückliche menschliche Prüfung erfordern.
Vorgeschlagene Risikostufen
| Risikostufe | Beispielhafte Agentenaktion | Vorgeschlagene Kontrolle |
|---|---|---|
| Niedrig | Entwurf einer internen Zusammenfassung | Nur protokollieren |
| Mittel | Aktualisierung eines nicht kritischen CRM-Felds | Regelbasierte Validierung oder Stichprobenprüfung |
| Hoch | Versand einer kundenorientierten Nachricht | Menschliche Freigabe erforderlich |
| Kritisch | Zahlungen, Kontolöschung, Aktionen mit rechtlichen oder sicherheitsrelevanten Auswirkungen | Menschliche Freigabe plus sekundäre Kontrolle |
Diese Struktur ermöglicht es Teams, Geschwindigkeit zu bewahren und gleichzeitig Entscheidungen mit hoher Auswirkung zu kontrollieren.
Kontrollen, die HITL auditbereit machen
Ein nützlicher HITL-Workflow sollte erfassen:
- Identität der prüfenden Person
- Freigabe- oder Ablehnungsentscheidung
- Begründung der Entscheidung
- Ursprüngliche Empfehlung des Agenten
- Endgültig ausgeführte Aktion
- Vorher-/Nachher-Zustand, wo relevant
- Zeitstempel
- Eskalationspfad
- Rollback-Option
Ohne diese Aufzeichnungen kann HITL operativ helfen, aber Audit- oder Incident-Prüfungen nicht ausreichend unterstützen.
Wann ein Kill Switch ergänzt werden sollte
Ein Kill Switch ermöglicht es Teams, einen Agenten schnell zu stoppen oder bestimmte Tool-Aktionen zu deaktivieren.
Teams sollten Kill Switches für Fälle in Betracht ziehen wie:
- Unerwartetes Tool-Call-Volumen
- Wiederholte Validierungsfehler
- Verdächtige Injection-Versuche
- Offenlegung sensibler Daten
- Kostenspitzen
- Modell- oder Anbieterausfall
- Wiederholte Entscheidungen mit niedriger Konfidenz
- Anormale Nutzerbeschwerden oder Support-Eskalationen
Ein Kill Switch sollte vor dem Launch getestet werden. Er sollte nicht nur als theoretische Kontrolle existieren.
LLM-Agenten vor der Produktion testen und überwachen
Traditionelle QA reicht nicht aus
Traditionelle QA geht von überwiegend deterministischem Verhalten aus. LLM-Agenten sind anders. Ihre Ausgaben können variieren, ihre Schlussfolgerungswege können sich ändern und ihre Aktionen können von abgerufenen Daten, Tool-Antworten, Nutzerkontext und Modelleinstellungen abhängen.
Das bedeutet, dass Agententests sowohl funktionale als auch sicherheitsbezogene Evaluation umfassen müssen. Ein Workflow kann einen Happy-Path-Test bestehen und dennoch bei adversarialen Eingaben, ungewöhnlichen Dokumenten, fehlerhaften Tool-Antworten oder Fällen an Berechtigungsgrenzen scheitern.
Zentrale Testarten
Ein produktionsreifer Testplan sollte enthalten:
- Tests des Aufgabenerfolgs
- Prompt-Injection-Tests
- Tests für indirekte Injection
- Tests von Tool-Berechtigungen
- Tests der Tool-Argumentvalidierung
- Tests auf Datenlecks
- Tests von RAG-Retrieval-Zugriffen
- Tests von HITL-Workflows
- Regressionstests
- Kosten- und Latenztests
- Tests von Fehlermodi
- Rollback- und Kill-Switch-Tests
Sicherheitstests sollten realistische Geschäftsworkflows umfassen, nicht nur künstliche Prompts.
Einen Evaluierungs-Harness aufbauen
Ein Evaluierungs-Harness hilft Teams, Agenten vor dem Release konsistent zu testen. Er sollte enthalten:
- Einen versionierten Satz von Testfällen
- Erwartete Ergebnisse oder Bewertungskriterien
- Adversariale Beispiele
- Realistische Nutzeraufgaben
- Tool-Nutzungsszenarien
- Prüfungen auf Policy-Verstöße
- Regressionsverfolgung über Modell- oder Prompt-Änderungen hinweg
- Berichte, die von Engineering-, Sicherheits- und Produktteams geprüft werden können
Der Harness sollte vor größeren Releases und immer dann laufen, wenn sich Prompts, Tools, Modelle, Retrieval-Logik oder Policy-Regeln ändern.
Monitoring-Signale vor dem Launch definieren
Monitoring sollte entworfen werden, bevor der Agent live geht. Nützliche Signale sind:
- Häufigkeit von Tool-Aufrufen
- Fehlgeschlagene Validierungen
- Blockierte Aktionen
- HITL-Freigabe- und Ablehnungsraten
- Wiederholte Retries
- Token- und Kostenanomalien
- Latenzspitzen
- Erkennungen sensibler Daten
- Verdächtige Prompt-Muster
- Unerwarteter Datenzugriff
- Nutzerbeschwerden
- Versuche von Policy-Verstößen
Diese Signale sollten Warnmeldungen, Dashboards und Incident-Response-Workflows speisen.
Produktions-Monitoring nach dem Release
Tests enden nicht beim Launch. LLM-Agenten können driften, wenn sich Daten, Tools, Prompts, Modelle und Nutzerverhalten ändern.
Diese Lebenszyklus-Sicht entspricht dem NIST AI Risk Management Framework, das KI-Risikomanagement um Govern, Map, Measure und Manage organisiert. Für LLM-Agenten bedeutet das, dass Teams Risiken vor der Bereitstellung abbilden, Verhalten durch Evaluationen und Monitoring messen und Fehler durch Warnmeldungen, Rollback-Pfade und Incident Response managen sollten.
Nach dem Release sollten Teams prüfen:
- Ob der Agent weiterhin die Ziele für Aufgabenerfolg erfüllt
- Ob Sicherheitsblockierungen zunehmen
- Ob HITL-Prüfende den Agenten häufig überstimmen
- Ob Kostenmuster stabil sind
- Ob Nutzer neue Fehlermodi entdecken
- Ob Änderungen an Modell oder Anbieter das Verhalten beeinflussen
Produktions-Monitoring macht LLM-Sicherheit von einer einmaligen Checkliste zu einer fortlaufenden Betriebspraxis.
LLM-Sicherheits-Checkliste für sichere Auslieferung
Architekturkontrollen
Vor dem Launch bestätigen:
- Datenflüsse sind abgebildet.
- Klassen sensibler Daten sind identifiziert.
- Tool-Berechtigungen sind dokumentiert.
- RAG-Zugriffskontrollen sind getestet.
- Modell- und Anbietereinstellungen sind geprüft.
- Regions- und Aufbewahrungseinstellungen sind bestätigt.
- Secrets werden aus Prompts und Logs herausgehalten.
- Umgebungen sind getrennt.
Sicherheitskontrollen
Bestätigen:
- Prompt-Injection-Abwehrmaßnahmen sind getestet.
- Fälle indirekter Injection sind in der Evaluation enthalten.
- Tool-Allowlists werden durchgesetzt.
- Tool-Argumente werden serverseitig validiert.
- Tool-Ausgaben werden als nicht vertrauenswürdige Daten behandelt.
- Zugriff nach dem Need-to-know-Prinzip wird angewendet.
- Hochrisiko-Aktionen werden über Gates gesteuert.
- Audit-Logs sind aktiviert.
- Rate Limits und Timeouts sind konfiguriert.
Compliance-Kontrollen
Bestätigen:
- Datenaufbewahrung ist dokumentiert.
- Anbieter-/Subprozessorenprüfung ist abgeschlossen.
- Policy für menschliche Aufsicht ist definiert.
- Hochrisiko-Workflows sind auditierbar.
- Zugriffskontrollen sind rollenbasiert.
- Incident-Response-Schritte sind dokumentiert.
- Lösch- und Datenzugriffsprozesse sind verstanden.
- Rechts- und Compliance-Teams haben relevante Anforderungen geprüft.
Release-Kontrollen
Bestätigen:
- Evaluierungssuite hat bestanden.
- Regressionstests sind abgeschlossen.
- Sicherheitstestfälle sind geprüft.
- Monitoring-Warnmeldungen sind konfiguriert.
- Rollback-Pfad ist getestet.
- Kill Switch ist getestet.
- Post-Release-Owner ist zugewiesen.
- Review-Kadenz ist geplant.
Ein sicherer Launch ist nicht nur ein technischer Meilenstein. Er ist eine operative Verpflichtung.
Wie HDWEBSOFT Teams hilft, LLM- und agentische KI-Systeme abzusichern
LLM-gestützte Agenten sicher auszuliefern erfordert sowohl KI-Engineering als auch Sicherheitsdenken. Teams müssen Workflows entwerfen, Tools integrieren, Daten schützen, Verhalten testen und Produktionssysteme überwachen, ohne die Lieferung unnötig zu verlangsamen.
HDWEBSOFT hilft Teams, KI-Systeme mit praktischer Engineering-Unterstützung zu planen, zu entwickeln und abzusichern. Wenn Ihre Organisation ein LLM- oder agentisches KI-Rollout vorbereitet, kann unser Team Architekturdesign, KI-Workflow-Implementierung, Tool-Integration, Sicherheitsprüfung und Produktionsreife unterstützen.
Entdecken Sie unsere KI-Entwicklungsservices für sichere KI-Implementierung und unsere Cybersicherheitsservices für Sicherheitsbewertung, Risikoprüfung und stärkere Produktionskontrollen.
Fazit
LLM-Sicherheit ist nicht ein Prompt, eine Policy oder eine Checkliste. Für agentische KI muss sie das gesamte System abdecken: Prompts, abgerufene Daten, Tools, Berechtigungen, Logs, menschliche Freigaben, Tests und Produktions-Monitoring.
Die Teams, die sicher ausliefern, werden diejenigen sein, die Sicherheit von Anfang an als Teil der Architektur behandeln. Prompt-Injection-Kontrollen, Tool-Zugriff nach dem Need-to-know-Prinzip, Planung der Datenresidenz, HITL-Workflows und kontinuierliche Evaluation wirken zusammen, um Risiken zu reduzieren.
Für EU/US-Produktionsumgebungen besteht das Ziel nicht nur darin, den Agenten nützlich zu machen. Das Ziel ist, ihn kontrolliert, auditierbar, resilient und sicher genug zu machen, damit er in echten Geschäftsworkflows betrieben werden kann.
FAQ
Was ist LLM-Sicherheit?
LLM-Sicherheit ist die Praxis, LLM-gestützte Systeme vor Prompt Injection, Datenlecks, unbefugter Tool-Nutzung, unsicheren Ausgaben und Compliance-Verstößen zu schützen. Für agentische KI umfasst sie außerdem Tool-Berechtigungen, Audit-Logs, HITL-Workflows, Tests und Monitoring.
Warum ist LLM-Sicherheit für KI-Agenten schwieriger?
LLM-Sicherheit ist für KI-Agenten schwieriger, weil Agenten Aktionen ausführen können. Sie können Dokumente abrufen, APIs aufrufen, Systeme aktualisieren oder Workflows auslösen. Deshalb muss Sicherheit nicht nur Modellausgaben schützen, sondern auch die Tools und Daten, die mit dem Agenten verbunden sind.
Wie verhindert man Prompt Injection in LLM-Agenten?
Die Vermeidung von Prompt Injection erfordert mehrschichtige Kontrollen. Teams sollten vertrauenswürdige Anweisungen von nicht vertrauenswürdigen Inhalten trennen, Tool-Aufrufe validieren, Zugriff nach dem Need-to-know-Prinzip anwenden, abgerufene Inhalte als Daten behandeln, Policy-Prüfungen ergänzen, verdächtige Muster überwachen und mit adversarialen Fällen testen.
Was ist indirekte Prompt Injection?
Indirekte Prompt Injection tritt auf, wenn bösartige Anweisungen in Inhalten verborgen sind, die der Agent liest, etwa Webseiten, E-Mails, Dokumente, Support-Tickets, PDFs oder RAG-Ergebnisse. Der Agent kann diese Inhalte als Anweisung behandeln, sofern das System nicht darauf ausgelegt ist, sie zu isolieren und zu validieren.
Wie sichert man Tool Calling für LLM-Agenten ab?
Sicheres Tool Calling erfordert Zugriff nach dem Need-to-know-Prinzip, begrenzte API-Scopes, Tool-Allowlists, strukturierte Schemas, serverseitige Argumentvalidierung, Ausgabevalidierung, Rate Limits, Sandboxing für Hochrisiko-Tools, Secrets Management und Audit-Logging für Tool-Aktionen.
Wie wirkt sich Datenresidenz auf LLM-Anwendungen aus?
Datenresidenz beeinflusst, wo Prompts, abgerufene Dokumente, Embeddings, Ausgaben und Logs verarbeitet und gespeichert werden. EU/US-Bereitstellungen sollten Datenflüsse abbilden, Anbietereinstellungen prüfen, Aufbewahrung konfigurieren und Architekturmuster wählen, die zu Datenschutz- und Compliance-Anforderungen passen.
Was sollten Teams vor der Bereitstellung von LLM-Agenten testen?
Teams sollten Aufgabenerfolg, Widerstandsfähigkeit gegen Prompt Injection, indirekte Injection-Szenarien, Tool-Berechtigungen, Datenlecks, RAG-Zugriffskontrollen, HITL-Freigabeabläufe, Regressionsverhalten, Monitoring-Warnungen, Latenz, Kostenverhalten, Rollback-Pfade und Kill-Switch-Verhalten testen.
