LangChain, LangGraph, LlamaIndex, CrewAI und AutoGen: Sicherheit von agentischen Custom-Anwendungen
Mit LangChain, LangGraph, LlamaIndex, CrewAI und AutoGen nutzt das Team nicht nur einen Coding-Assistenten: Es baut Anwendungen, in denen ein LLM logische Schlussfolgerungen zieht, Kontext abruft, Werkzeuge verwendet, APIs aufruft und Prozessschritte koordiniert. Die Angriffsfläche ist nicht mehr nur die einer Web-App oder eines isolierten Modells, sondern umfasst die agentische Laufzeitumgebung, Tools, Speicher, Retrieval-Systeme und die Berechtigungen, die diese steuern.
Es geht nicht darum, ob KI eine gute oder schlechte Wahl für die Entwicklung ist. Es geht um eine sehr praktische Frage: Welche Kontrollen sind erforderlich, wenn ein durch KI generiertes oder beschleunigtes Ergebnis in ein Produkt, einen Unternehmens-Workflow oder eine Umgebung mit echten Daten einfließt? Dieser Artikel richtet sich an Gründer, CTOs, Entwickler sowie IT- und Security-Teams, die agentische Custom-Anwendungen entwickeln und verstehen wollen, wo sie Kontrollen ansetzen müssen: Tool-Missbrauch, RAG-Poisoning, Memory-Poisoning, Berechtigungen und nicht validierte Ausgaben.
Warum eine funktionierende App nicht zwangsläufig sicher ist
KI-Tools reduzieren die Zeit für die Erstellung von Code, Schnittstellen, Workflows, Tests und Konfigurationen. Diese Geschwindigkeit kann jedoch die Schritte komprimieren, die Software normalerweise zuverlässig machen: Threat Modeling, Code-Reviews, Geheimnisverwaltung (Secrets Management), Rollenkonzepte, Eingabevalidierung, Überprüfung von Abhängigkeiten und manuelle Tests kritischer Pfade.
Eine Demo funktioniert mit einem einzelnen Benutzer, fiktiven Daten und impliziten Berechtigungen. Dieselbe Logik kann versagen, wenn echte Kunden, mehrere Mandanten (Multi-Tenancy), unterschiedliche Rollen, öffentliche APIs, Integrationen, personenbezogene Daten, Zahlungen oder Automatisierungen mit externen Auswirkungen hinzukommen. Deshalb muss die Sicherheit am tatsächlichen Verhalten der App bewertet werden, nicht am Versprechen des Tools, das sie generiert hat.
Tool-Calling und übermäßige Berechtigungen
Jedes Tool, das einem Agenten gewährt wird, ist de facto eine Anwendungsberechtigung. Lese- und Schreibzugriffe, E-Mails, Tickets, Datenbanken, Shell-Zugriffe oder CRM-Integrationen müssen über einen minimalen Scope, Richtlinien außerhalb des Modells, Audit-Logs und eine explizite Bestätigung für sensible Aktionen verfügen. Die Verwaltung von Berechtigungen an den Prompt zu delegieren, ist einer der häufigsten und gefährlichsten Fehler in agentischen Anwendungen: Kritische Regeln müssen im Code, in Richtlinien und in serverseitigen Kontrollen verankert sein, nicht im System-Prompt.
RAG, Speicher und nicht vertrauenswürdiger Kontext
Dokumente, Tickets, Webseiten, E-Mails und Wissensdatenbanken können feindselige Anweisungen enthalten. Das Retrieval muss nach Berechtigungen filtern, und die abgerufenen Inhalte dürfen nicht in der Lage sein, Systemrichtlinien oder Benutzerberechtigungen zu überschreiben. Das Risiko von RAG-Poisoning und Memory-Poisoning zwischen Sitzungen oder Mandanten ist real und wird oft unterschätzt: Ein bösartiges Dokument in der Wissensdatenbank kann das Verhalten des Agenten auf eine Weise verändern, die ohne spezifische Tests nicht erkennbar ist.
Output-Handling und automatisierte Entscheidungen
Die Ausgabe des Modells sollte nicht direkt verwendet werden, um HTML zu generieren, Abfragen zu erstellen, Befehle auszuführen, APIs aufzurufen, Berechtigungen zu verwalten oder irreversible Entscheidungen zu treffen. Es sind strukturierte Validierung, Schemata, Allowlists, Sandboxing und Tests mit bösartigen Eingaben erforderlich, bevor eine Ausgabe ein reales System erreicht.
Hauptrisiken, die überprüft werden müssen
Die folgenden Risiken sind nicht theoretisch: Sie betreffen das konkrete Verhalten der Anwendung mit echten Daten und müssen anhand von Nachweisen, Konfigurationen, Laufzeitverhalten und tatsächlichen Auswirkungen verifiziert werden.
- Direkte und indirekte Prompt-Injection: Feindselige Anweisungen, die in den Prompt oder in vom System abgerufene Dokumente eingeschleust werden.
- Tool-Missbrauch durch übermäßige Berechtigungen: Agenten, die unbefugte Aktionen ausführen können, weil die Tools keinen begrenzten Scope haben.
- RAG-Poisoning und feindselige Dokumente: Bösartige Inhalte in der Wissensdatenbank, die das Verhalten des Agenten manipulieren.
- Memory-Poisoning zwischen Sitzungen oder Mandanten: Kontamination des persistenten Speichers, die nachfolgende Sitzungen oder andere Benutzer beeinflusst.
- Offenlegung sensibler Informationen (Sensitive Information Disclosure): Sensible Daten, die durch Ausgaben, Logs oder Modellantworten preisgegeben werden.
- Nicht validierte Ausgaben an APIs oder Shells: Modellergebnisse, die ohne Bereinigung direkt als Eingabe für externe Systeme verwendet werden.
- An den Prompt delegierte Autorisierung: Zugriffskontrolllogik, die dem System-Prompt anvertraut wird, anstatt serverseitige Richtlinien zu nutzen.
Diese Risiken müssen mit dem konkreten Perimeter der Anwendung verknüpft werden. Eine öffentlich zugängliche App erfordert manuelle Anwendungstests; eine kritische Codeänderung erfordert eine Review; ein interner Workflow erfordert die Kontrolle von Berechtigungen und Anmeldedaten; eine agentische App erfordert Tests von Prompts, Tools und Ausgaben. Die richtige Kombination hängt von der tatsächlichen Auswirkung ab, nicht vom Namen des Tools, mit dem sie erstellt wurde.
Mindestkontrollen vor dem Go-Live
- Benutzer, Rollen, echte Daten, Integrationen, Umgebungen und Service-Owner abbilden.
- Identifizieren, welche Teile mit KI generiert oder modifiziert wurden und wer diese überprüft hat.
- Serverseitige Berechtigungen, Mandantentrennung und administrative Funktionen verifizieren.
- Nach Geheimnissen (Secrets) in Code, Prompts, Logs, Umgebungsvariablen, Builds und Repository-Historie suchen.
- Abhängigkeiten, Lizenzen, Pakete, Vorlagen, Plugins und generierte Komponenten prüfen.
- Feindselige Eingaben, Fehlerbehandlung, Logging, Rate-Limits und unerwartete Pfade testen.
- Blockierende Fixes, geplante Korrekturen und akzeptiertes Restrisiko trennen.
- Tests oder Retests nach Korrekturen durchführen, die kritische Abläufe betreffen.
Wann eine unabhängige Überprüfung erforderlich ist
Eine unabhängige Überprüfung ist erforderlich, wenn die App oder der Workflow echte Daten, externe Benutzer, Rollen, APIs, Unternehmensintegrationen, Zahlungen, Speicher, automatisierte Workflows oder kritischen, KI-generierten Code verarbeitet. Sie ist auch dann notwendig, wenn das Team nicht nachweisen kann, welche Teile überprüft wurden und welche Kontrollen Regressionen oder Missbrauch verhindern.
Für agentische Anwendungen umfasst der empfohlene Perimeter: KI-Anwendungstests, Code-Reviews und Sichere Architektur-Reviews. Die nützlichste Review ist nicht generisch: Sie muss reproduzierbare Ergebnisse, Prioritäten für die Fehlerbehebung, Angaben zum Restrisiko und bei Bedarf Retests nach den Korrekturen liefern.
Operative Fragen für Gründer, CTOs und Security-Teams
- Welche echten Daten gelangen in das System und wo werden sie gespeichert, protokolliert oder gesendet?
- Welche Rollen existieren und welche Aktionen sind serverseitig blockiert, nicht nur in der Benutzeroberfläche?
- Welche Geheimnisse, Token, Webhooks oder Anmeldedaten würden den Zugriff auf kritische Systeme ermöglichen?
- Welche Teile wurden von der KI generiert oder modifiziert und welche wurden von einer kompetenten Person überprüft?
- Welche Tests decken Missbrauch, Fehler, verschiedene Rollen und verschiedene Mandanten ab, nicht nur den Idealfall (Happy Path)?
- Welche Nachweise können Kunden, Auditoren, der Einkauf oder die Geschäftsführung einsehen?
Nützliche weiterführende Informationen
- KI-Anwendungstests: Vertieft Methoden und den Umfang von Tests für Anwendungen, die LLMs integrieren, ohne den Fokus dieses Artikels zu duplizieren.
- OWASP Top 10 Agentic AI: Überblick über die von OWASP klassifizierten Risiken für agentische Anwendungen, nützlich als regulatorische Referenz und für die Priorisierung.
- Risiken von MCP-Servern und Coding-Agenten: Spezifische Analyse der Risiken im Zusammenhang mit Model Context Protocol-Servern und Coding-Agenten.
- Sicherheit von API-Keys und KI-Workflows: Leitfaden zur sicheren Verwaltung von Anmeldedaten in Workflows, die KI-Modelle integrieren.
FAQ
- Was ist der Unterschied zwischen einer LLM-App und einer agentischen App?
- Eine agentische App antwortet nicht nur auf einen Prompt: Sie ruft Kontext ab, plant, verwendet Werkzeuge, ruft APIs auf oder koordiniert Schritte mit externen Auswirkungen auf reale Systeme.
- Kann der Prompt eine Sicherheitsbarriere sein?
- Nein. Kritische Regeln müssen im Code, in Richtlinien, Berechtigungen und serverseitigen Kontrollen verankert sein. Der System-Prompt kann das Verhalten des Modells steuern, ist aber kein zuverlässiger Sicherheitsmechanismus.
- Wie testet man indirekte Prompt-Injection?
- Indem feindselige Anweisungen in Dokumente, Seiten, Tickets oder Datensätze eingefügt werden, die vom System abgerufen werden, und anschließend Tool-Aufrufe, Ausgaben und Datenzugriffe in den Antworten des Agenten überprüft werden.
- Wann sind KI-Anwendungstests erforderlich?
- Wenn die App LLMs, RAG, Speicher, Tool-Calling, Agenten oder Workflows mit Aktionen auf realen Systemen integriert, insbesondere wenn sie sensible Daten oder externe Benutzer verwaltet.
- Ist auch eine Code-Review erforderlich?
- Ja. Man muss Berechtigungen, Tool-Wrapper, Output-Validierung, Retrieval, Logging, Geheimnisverwaltung und operative Limits lesen: Aspekte, die ein reiner Anwendungstest allein nicht abdeckt.
[Callforaction-CR-Footer]
Leave a Reply