Sicherheit von Agenten
Agenten lesen Texte von Fremden und handeln anschließend mit Ihren Zugangsdaten. Diese Seite erläutert die Grundregel, beide OWASP-Listen von 2026, die bisherigen Vorfälle und die Abwehrmaßnahmen, mit denen sie sich hätten verhindern lassen.
Die tödliche Triade
- Zugriff auf private DatenE-Mails, Repositories, Datenbanken, Dateien oder andere Inhalte, die durch Ihre Zugangsdaten geschützt sind.
- Kontakt mit nicht vertrauenswürdigen InhaltenWebseiten, Issues, Support-Tickets, eingehende E-Mails und Tool-Beschreibungen: Jeder Text, den ein Angreifer verfassen kann.
- Möglichkeit zur externen KommunikationE-Mails versenden, Pull Requests öffnen, URLs abrufen oder entfernte Bilder anzeigen. Simon Willison benannte diese Kombination aus drei Elementen im Juni 2025.
Wenn ein Agent über alle drei Möglichkeiten verfügt, gehen Sie davon aus, dass eine Prompt Injection ihn dazu bringen kann, Ihre Daten an einen Angreifer weiterzugeben. Verlassen Sie sich nicht darauf, dass das Modell sich weigert. Entfernen Sie für jeden Agenten und jede Sitzung mindestens eines der drei Elemente.
Sicherheitscheckliste
22 Prüfungen zu Eingaben, Tools, Laufzeitumgebung, MCP, CI und Betrieb. Haken Sie die Punkte nach und nach ab und exportieren Sie das Ergebnis als Markdown-Datei.
Vorfallprotokoll
Zu jedem öffentlich bekannten Sicherheitsvorfall mit Agenten seit April 2025: was passiert ist, warum der Angriff funktioniert hat und was Sie in Ihrer eigenen Einrichtung ändern sollten.
Aktuelle Vorfälle
- MCP Python SDK: Sitzungsübernahme und Zugriff auf Tasks anderer Sitzungen
- Claude Code: WebFetch-Auto-Freigabe ermöglichte Datenabfluss über huggingface.co
- Comment and Control: PR-Texte stehlen Secrets von CI-Agenten
- MCP TypeScript SDK gab Antworten zwischen Clients preis
- ClawHavoc: Hunderte schädliche ClawHub-Skills verbreiten AMOS
OWASP Top 10 für agentische Anwendungen 2026
Das OWASP GenAI Security Project veröffentlichte diese Liste am 9. Dezember 2025. Sie behandelt die Risiken, die entstehen, sobald ein Modell plant, Erinnerungen speichert, Tools aufruft und mit anderen Agenten zusammenarbeitet.
ASI01Übernahme des AgentenzielsEin Angreifer verändert das Ziel des Agenten, meist durch Anweisungen, die in den von ihm gelesenen Inhalten verborgen sind. Daraufhin verfolgt der Agent das Ziel des Angreifers mit den Tools und Berechtigungen des Nutzers.
ASI02Missbrauch und Ausnutzung von ToolsDer Agent setzt legitime Tools auf schädliche Weise ein, etwa um Datensätze zu löschen, Nachrichten zu versenden oder Aufrufe zu verketten. Ursache dafür ist entweder Manipulation oder ein zu weitreichender Tool-Zugriff, der über die Anforderungen der Aufgabe hinausgeht.
ASI03Missbrauch von Identitäten und BerechtigungenAgenten handeln mit Zugangsdaten, delegierten Tokens und übernommenen Berechtigungen. Angreifer missbrauchen diese Identitäten oder die Lücken zwischen ihnen, um ihre Berechtigungen auszuweiten oder als eine andere Person zu handeln.
ASI04Schwachstellen in der Lieferkette agentischer SystemeTools, MCP-Server, Skills, Plugins, Modelle und Prompts, die beim Build oder zur Laufzeit geladen werden, können bösartig oder kompromittiert sein. Da Agenten viele davon dynamisch laden, betrifft eine einzige schadhafte Komponente jede Sitzung, in der sie verwendet wird.
ASI05Unerwartete Codeausführung (RCE)Agenten, die Code schreiben und ausführen oder Modellausgaben an Shells und Interpreter übergeben, lassen sich dazu verleiten, vom Angreifer ausgewählte Befehle auf dem Host auszuführen.
ASI06Vergiftung von Gedächtnis und KontextAngreifer schleusen falsche Fakten oder Anweisungen in das Gedächtnis eines Agenten, abgerufene Dokumente oder gespeicherten Kontext ein. Die Vergiftung bleibt bestehen und beeinflusst spätere Sitzungen, lange nachdem die ursprüngliche Eingabe verschwunden ist.
ASI07Unsichere Kommunikation zwischen AgentenNachrichten zwischen Agenten werden ohne angemessene Authentifizierung, Integritätsprüfungen oder Validierung übertragen. Sie können daher gefälscht, wiederholt oder verändert werden, um den empfangenden Agenten in die Irre zu führen.
ASI08Kaskadierende AusfälleEin einzelner Fehler, etwa eine vergiftete Eingabe, ein fehlerhaftes Tool-Ergebnis oder ein kompromittierter Agent, breitet sich über verbundene Agenten und automatisierte Schritte schneller aus, als Menschen ihn erkennen können.
ASI09Ausnutzung des Vertrauens zwischen Mensch und AgentAgenten wirken selbstsicher und hilfsbereit, weshalb Menschen ihren Vorschlägen eher zustimmen. Angreifer nutzen dieses Vertrauen aus, um Menschen dazu zu bringen, eine schädliche Aktion zu bestätigen oder Informationen preiszugeben.
ASI10Abtrünnige AgentenEin kompromittierter Agent oder einer, der von seinem vorgesehenen Verhalten abgewichen ist, handelt weiterhin eigenständig und außerhalb des vorgegebenen Umfangs und der vorgesehenen Kontrolle.
OWASP Top 10 für LLM-Anwendungen 2026
Diese Ausgabe wurde am 4. August 2026 veröffentlicht und ersetzt die Liste von 2025. Excessive Agency stieg vom sechsten auf den dritten Platz, und System Prompt Leakage wurde in Hidden Context Exposure umbenannt.
LLM01Prompt InjectionEine Eingabe verändert das Verhalten des Modells auf eine Weise, die der Entwickler nicht beabsichtigt hat. Sie kann direkt vom Nutzer oder indirekt aus Dokumenten, Webseiten und Tool-Ergebnissen stammen, die das Modell liest.
LLM02Offenlegung sensibler InformationenDas Modell oder die Anwendung gibt in der Ausgabe personenbezogene Daten, Zugangsdaten, Geschäftsgeheimnisse oder andere vertrauliche Informationen preis, die aus Trainingsdaten, dem Kontext oder verbundenen Systemen stammen.
LLM03Übermäßige AutonomieDie Anwendung räumt dem Modell mehr Funktionen, Berechtigungen oder Autonomie ein, als die Aufgabe erfordert. Dadurch kann eine manipulierte oder fehlerhafte Ausgabe echten Schaden verursachen. 2025 lag diese Kategorie noch auf Platz sechs, 2026 bereits auf Platz drei.
LLM04LieferketteModelle, Datensätze, Adapter, Pakete und Plugins von Drittanbietern können manipuliert oder verwundbar sein und diese Risiken in Ihre Anwendung einbringen.
LLM05Vergiftung von Daten und ModellenAngreifer manipulieren Pre-Training-, Fine-Tuning- oder Embedding-Daten, um Hintertüren, Verzerrungen oder fehlerhaftes Verhalten einzuschleusen, das sich erst später in der Produktion zeigt.
LLM06Unbegrenzter RessourcenverbrauchOhne Limits für Anfragen, Eingabegröße oder Rechenleistung können Angreifer Ihre Kosten in die Höhe treiben, Ressourcen erschöpfen oder ein Modell durch massenhafte Abfragen kopieren.
LLM07FehlinformationenDas Modell erzeugt falsche oder irreführende Ausgaben, die glaubwürdig wirken. Nutzer oder nachgelagerte Systeme handeln danach, ohne sie zu überprüfen.
LLM08Offenlegung verborgener KontexteFrüher: System Prompt Leakage. System-Prompts, verborgene Anweisungen und andere Kontexte, die Nutzer nicht sehen sollen, lassen sich extrahieren. Dadurch werden die dort hinterlegten Regeln, die Logik oder Geheimnisse offengelegt.
LLM09Schwachstellen bei Vektoren und EmbeddingsSchwachstellen bei der Erzeugung, Speicherung und Abfrage von Embeddings ermöglichen es Angreifern, Inhalte einzuschleusen, Daten zwischen Mandanten offenzulegen oder den Quelltext wiederherzustellen. RAG-Systeme sind besonders betroffen.
LLM10Unzureichende Verarbeitung von AusgabenModellausgaben gelangen ohne Validierung oder Kodierung in Browser, Shells, Datenbanken oder andere Komponenten. Das ermöglicht XSS, SQL-Injection, Codeausführung und Datenexfiltration.
Abwehrmaßnahmen
Fünfzehn dokumentierte Abwehrmaßnahmen, jeweils mit einem Link zur Quelle. Kombinieren Sie mehrere davon, denn keine einzelne Maßnahme schützt vor allen Angriffen.
Die tödliche Triade durchbrechen
Simon Willisons Regel: Ein Agent, der private Daten lesen und nicht vertrauenswürdige Inhalte sehen sowie Daten nach außen senden kann, lässt sich durch beliebigen Text, den er liest, gegen Sie einsetzen. Entfernen Sie bei jedem Agenten oder jeder Sitzung mindestens eine dieser drei Fähigkeiten. Der Agent, der öffentliche Issues sortiert, erhält zum Beispiel keine Geheimnisse. Der Agent, der Geheimnisse verwaltet, erhält keinen Kanal nach außen.
Agenten nach nicht vertrauenswürdigen Eingaben einschränken
Forschung zu Design-Patterns für Agent-Sicherheit folgt einer Regel: Sobald ein Agent nicht vertrauenswürdige Eingaben verarbeitet hat, dürfen diese keine folgenreichen Aktionen auslösen können. Zu den Patterns gehören action-selector, plan-then-execute, dual LLM und Kontextminimierung. Wählen Sie für jeden Workflow ein Pattern, zum Beispiel indem Sie den Plan festschreiben, bevor der Agent nicht vertrauenswürdige Daten liest.
Datenflüsse mit CaMeL verfolgen
CaMeL teilt den Agenten in zwei Teile: Ein privilegierter Planner schreibt Code auf Grundlage der Anfrage des Nutzers, während ein isoliertes Modell nicht vertrauenswürdige Daten verarbeitet. Werte aus dem isolierten Bereich erhalten Capability-Tags, die von Richtlinien geprüft werden, bevor ein Tool ausgeführt wird. Im Paper löste CaMeL 77% der AgentDojo-Aufgaben mit nachweisbarer Sicherheit – gegenüber 84% bei einem ungeschützten Agenten.
Anmeldedaten mit minimalen Rechten verwenden
Gewähren Sie Agenten standardmäßig schreibgeschützten, auf ein Projekt beschränkten Zugriff und verwenden Sie niemals einen Admin- oder service_role-Schlüssel, der in Supabase Row-Level Security umgeht. Beschränken Sie CI- und Repository-Tokens auf den jeweiligen einzelnen Job. Der Vorfall mit Amazon Q Developer ging auf ein zu weitreichend berechtigtes GitHub-Token in CodeBuild zurück.
Folgenreiche Aktionen bestätigen lassen
Lassen Sie Tool-Aufrufe, die Daten schreiben, löschen, versenden oder Geld ausgeben, von einer Person bestätigen. Wenn niemand antwortet, muss die Aktion abgebrochen werden. Supabase empfiehlt die manuelle Bestätigung von MCP-Tool-Aufrufen. In OpenClaw setzen Sie tools.exec.ask auf always und lassen askFallback auf deny. Zeigen Sie die vollständigen Argumente an, damit die prüfende Person sieht, was tatsächlich ausgeführt wird.
Code- und Tool-Ausführung in einer Sandbox ausführen
Führen Sie Shell-Befehle und generierten Code in einem Container oder einer VM aus, die keine Anmeldedaten enthält und nur den Workspace sieht. Bei OpenClaw ist Sandboxing standardmäßig deaktiviert und tools.exec.security auf Gateway-Hosts auf full gesetzt. Aktivieren Sie daher Sandboxing, setzen Sie die exec-Sicherheit auf deny oder allowlist, setzen Sie fs.workspaceOnly auf true und lassen Sie den erhöhten Modus deaktiviert. Prüfen Sie das Ergebnis mit openclaw sandbox explain.
Ausgehenden Netzwerkzugriff einschränken
Sperren Sie standardmäßig ausgehenden Datenverkehr von Agenten und MCP-Servern und geben Sie anschließend nur die benötigten Hosts frei. Genehmigen Sie niemals automatisch Abrufe von mandantenfähigen Hosts, auf denen beliebige Personen Inhalte veröffentlichen können. Genau so wurde huggingface.co durch CVE-2026-54316 zu einem Exfiltrationskanal. Ein E-Mail-Server sollte nur seine Mail-API erreichen können, wie der Fall postmark-mcp gezeigt hat.
Control Planes nicht ins Internet stellen
Binden Sie Agent-Gateways, Dashboards und Debug-Proxys an loopback und verlangen Sie ein Token mit mindestens 24 Zeichen, zum Beispiel aus openssl rand -hex 32. Stellen Sie den Fernzugriff über einen SSH-Tunnel oder Tailscale Serve her und verwenden Sie Tailscale Funnel nur mit Passwortauthentifizierung. Führen Sie regelmäßig openclaw security audit --deep aus.
Audience von MCP-Tokens prüfen
Die MCP-Autorisierungsspezifikation verlangt von einem Server, Zugriffstokens abzulehnen, die nicht für ihn ausgestellt wurden. Außerdem darf er das Token eines Clients nicht an eine nachgelagerte API weiterreichen. Clients senden RFC 8707 Resource Indicators, damit jedes Token an genau einen Server gebunden ist. Ein Proxy-Server benötigt die Zustimmung jedes Clients, andernfalls wird er zum Confused Deputy.
MCP-Sitzungen und Mandanten isolieren
Erstellen Sie für jede Sitzung eine eigene Server- und Transportinstanz, statt eine Instanz für mehrere Clients gemeinsam zu verwenden. Binden Sie jede Sitzung und jeden Task an den authentifizierten Principal, der sie erstellt hat, und prüfen Sie diese Bindung bei jeder Anfrage. Beide MCP-SDK-Sicherheitshinweise aus 2026 gingen auf gemeinsam genutzten oder nicht gebundenen Zustand zurück.
Skills, Plugins und MCP-Server prüfen
Fixieren Sie exakte Versionen, prüfen Sie vor jedem Update den Diff und berücksichtigen Sie Scanner-Ergebnisse wie VirusTotal sowie den Sicherheitsprüfstatus von ClawHub. Hashen Sie Tool-Beschreibungen, wenn Sie einen Server genehmigen, und lösen Sie bei Änderungen einen Alarm aus. So erkennen Sie Rug Pulls. OpenClaw blockiert Installationen standardmäßig nicht. Legen Sie security.installPolicy daher selbst fest.
Festlegen, wer dem Agenten Nachrichten senden darf
Beschränken Sie den Zugriff auf Direktnachrichten auf Pairing oder eine Allowlist, verlangen Sie in Gruppenchats eine Erwähnung, bevor der Agent aktiv wird, und setzen Sie session.dmScope auf per-channel-peer, damit Absender niemals Kontext teilen. Jede Person, die dem Agenten Nachrichten senden kann, kann versuchen, ihn anzuweisen. Die Absenderliste gehört daher zu Ihrer Angriffsfläche.
Secrets aus nicht vertrauenswürdigen CI-Läufen heraushalten
Führen Sie keinen Agenten mit Repository-Secrets in Workflows aus, die Außenstehende über einen Pull Request, ein Issue oder einen Kommentar auslösen können. Behandeln Sie Titel, Beschreibungen und Kommentare aus diesen Ereignissen als nicht vertrauenswürdig. Wenn ein Schritt tatsächlich Secrets benötigt, führen Sie ihn erst aus, nachdem ein Maintainer den Lauf genehmigt hat.
Modellausgaben als nicht vertrauenswürdig behandeln
Kodieren oder bereinigen Sie Modellausgaben, bevor Sie sie rendern, und übergeben Sie sie niemals ungeprüft an eine Shell, SQL-Abfrage oder einen Browser. Blockieren Sie das automatische Laden von Markdown-Bildern und Links zu externen Domains und setzen Sie eine strenge Content Security Policy. EchoLeak schleuste Daten über URLs nach außen, die automatisch geladen wurden.
Agent-Signaturen prüfen und Anfragen autorisieren
Um einen Agenten zu identifizieren, der Ihre Website oder API aufruft, prüfen Sie seine Web Bot Auth-Signatur anhand der Schlüssel, die der Betreiber unter /.well-known/http-message-signatures-directory veröffentlicht. ChatGPT agent signiert als Signature-Agent https://chatgpt.com. Eine gültige Signatur zeigt, wer den Agenten betreibt, nicht, welcher Nutzer die Anfrage gesendet hat oder was dieser Nutzer tun darf. Autorisieren Sie daher jede Anfrage separat.
Fragen zur Sicherheit von Agenten
Was ist Prompt Injection bei KI-Agenten?
Prompt Injection ist Text, den das Modell als Anweisungen behandelt, obwohl er als Daten übermittelt wurde, zum Beispiel auf einer Webseite, in einer E-Mail oder in einer Toolbeschreibung. Bei einem Agenten können solche Anweisungen Tool-Aufrufe auslösen, die mit Ihren Zugangsdaten ausgeführt werden. OWASP führt sie als LLM01:2026, und Agent Goal Hijack (ASI01) bezeichnet die agentische Form.
Was ist die tödliche Triade für KI-Agenten?
Simon Willison bezeichnet damit einen Agenten, der Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und eine Möglichkeit zur externen Kommunikation kombiniert. Sind alle drei Voraussetzungen erfüllt, kann eine Prompt Injection Ihre Daten auslesen und nach außen senden. Das MCP-Token-Leck bei Supabase 2025 ist ein Paradebeispiel.
Wie sichere ich einen MCP-Server ab?
Weisen Sie Zugriffstokens zurück, die nicht für Ihren Server ausgestellt wurden, und leiten Sie niemals das Token eines Clients an eine vorgelagerte API weiter. Erstellen Sie pro Sitzung jeweils eine eigene Server- und Transportinstanz und ordnen Sie Sitzungen und Aufgaben dem authentifizierten Nutzer zu. Verwenden Sie das TypeScript SDK in Version 1.26.0 oder höher und das Python SDK in Version 1.27.2 oder höher. Diese Versionen beheben ein Datenleck bei Antworten zwischen Clients und das Hijacking von Sitzungen.
Kann ein besserer System-Prompt Prompt Injection verhindern?
Verlassen Sie sich nicht darauf. Untersuchungen zu Designmustern für Agenten kommen zu dem Schluss, dass ein Agent, sobald er nicht vertrauenswürdige Eingaben verarbeitet hat, so eingeschränkt werden muss, dass diese Eingaben keine folgenreichen Aktionen auslösen können. CaMeL setzt dies mit Capability-Tracking durch und löste 77% der AgentDojo-Aufgaben mit nachweisbarer Sicherheit – gegenüber 84% bei einem ungeschützten Agenten.
Worin unterscheiden sich OWASP LLM Top 10 und Agentic Top 10?
Die OWASP Top 10 for LLM Applications, deren Ausgabe 2026 am 4 August 2026 erschien, behandelt Risiken aller Anwendungen, die auf einem Sprachmodell basieren. Die OWASP Top 10 for Agentic Applications, veröffentlicht am 9 December 2025, behandelt die zusätzlichen Risiken, die entstehen, wenn das Modell plant, Tools verwendet, Erinnerungen speichert und mit anderen Agenten kommuniziert. Die meisten Entwickler von Agenten sollten beide berücksichtigen.
Ist es sicher, ein OpenClaw-Gateway über das Internet zugänglich zu machen?
Nein. Lassen Sie gateway.bind auf dem Standardwert loopback und verwenden Sie für den Fernzugriff einen SSH-Tunnel oder Tailscale Serve. OpenA2A zählte am 1 September 2026 192,492 öffentlich erreichbare Gateways. CVE-2026-25253 zeigte außerdem, dass selbst Installationen, die nur an loopback gebunden sind, umgehend gepatcht werden müssen.