Ein wachsendes Problem in Unternehmen ist nicht mehr nur, ob ein KI-Agent eine E-Mail zusammenfassen, ein Ticket beantworten oder eine Datei finden kann. Entscheidend wird eine andere Frage: Wann darf der Agent einer Information vertrauen — und daraus eine Handlung ableiten?
Genau an dieser Grenze setzen zwei aktuelle Untersuchungen zu OpenClaw an. Imperva beschrieb am 10. Juni Prompt-Injection-Vektoren in Messaging-Objekten wie Kontakten, vCards und Standortdaten. Varonis veröffentlichte am 9. Juni Tests, in denen ein OpenClaw-basierter Mail-Agent durch plausibel formulierte E-Mails zur Weitergabe synthetischer Zugangsdaten und Kundendaten bewegt wurde. The Hacker News fasste beide Fälle am 11. Juni zusammen.
Für AIFence ist das Thema relevant, weil es nicht um einen exotischen Modellfehler geht. Es geht um eine Architekturfrage, die jedes Unternehmen beim Einsatz agentischer Systeme beantworten muss: Ein Agent liest untrusted Input, hat Zugriff auf interne Daten und kann nach außen kommunizieren oder Tools ausführen. Treffen diese drei Eigenschaften zusammen, wird normale Geschäftskommunikation zur potenziellen Steuerfläche.
Was Imperva technisch gefunden hat
Imperva untersuchte, wie OpenClaw eingehende Messaging-Objekte an das zugrunde liegende Sprachmodell übergibt. Nach Darstellung der Forscher landeten bestimmte Objekte — etwa geteilte Kontakte, vCard-Felder oder Standortbezeichnungen — im Prompt-Text, ohne klar genug als nicht vertrauenswürdige Metadaten abgegrenzt zu sein. Dort lag die Schwachstelle: Eine für den Nutzer unsichtbare oder unauffällige Anweisung konnte aus Sicht des Modells wie legitimer Kontext erscheinen.
Die Forscher beschreiben mehrere Injektionsvektoren, bei denen manipulierte Informationen die Grenze zwischen unauthentifiziertem Objekt und authentifiziertem Nutzerkontext überschritten. Kritisch ist dabei nicht nur die einzelne Nachricht, sondern die Kombination mit den Fähigkeiten des Agenten. OpenClaw automatisiert Workflows, ruft APIs auf, arbeitet mit Dateien oder Datenbanken und lässt sich in Kanäle wie Messenger einbinden. Trennt ein LLM in diesem Kontext Anweisungen aus untrusted Metadaten nicht zuverlässig von echter Nutzerintention, kann aus einem harmlosen Kontaktobjekt eine Handlungsanweisung werden.
Laut Imperva wurden die Schwachstellen verantwortungsvoll an das OpenClaw-Team gemeldet. Ein Fix sei in Version 2026.4.23 ausgeliefert worden. The Hacker News berichtet, dass Kontaktname, vCard-Felder und Standortlabels aus dem Prompt-Körper in einen separaten Kanal für untrusted Metadata verschoben wurden. Das ist ein wichtiger Patch. Das Grundproblem bleibt jedoch: Es gibt noch keinen allgemein etablierten Standard dafür, wie Messaging-Objekte, Dokumente, Kalenderinhalte oder CRM-Felder sicher in Modellkontext serialisiert werden.
Varonis: Wenn eine normale E-Mail genügt
Varonis wählte einen anderen, praxisnahen Ansatz. Das Team baute einen OpenClaw-Agenten namens „Pinchy“, verband ihn mit einer Gmail-Inbox in einer Google-Workspace-Testumgebung und füllte diese mit synthetischen, aber realistisch wirkenden Geschäftsdaten. Dazu zählten mock AWS-Zugangsdaten, Datenbankpasswörter, SSH-Zugänge und Kundendatensätze. Anschließend testete Varonis, ob klassische Phishing-Muster auch gegen einen Agenten funktionieren.
Die Ergebnisse sind für Unternehmen relevant. In einem Szenario schrieb ein angeblicher Teamlead von einer externen Gmail-Adresse und bat wegen eines simulierten Produktionsvorfalls um Staging-Zugangsdaten. Der Agent fand laut Varonis die relevanten Informationen und leitete mock AWS-IAM-Keys, Datenbank-Connection-Strings und SSH-Credentials im Klartext weiter.
In einem zweiten Szenario bat ein vermeintlicher Kollege routinemäßig um den aktuellen Customer Export für ein QBR-Deck. Auch hier gab der Agent die synthetischen Daten weiter. Varonis nennt 247 Enterprise-Kunden inklusive Kontaktdaten, Vertragsinformationen, Kundenstufen und rund 1,28 Millionen Dollar monatlichem wiederkehrendem Umsatz in den Testdaten.
Wichtig ist die Einordnung: Das waren Labortests mit synthetischen Informationen, keine öffentliche Meldung über kompromittierte echte Kundendaten. Trotzdem zeigen sie eine reale Risikoklasse. Varonis unterscheidet zwischen indirekter Prompt Injection und „Agent Phishing“. Prompt Injection versteckt Anweisungen in Daten, die ein Modell verarbeitet. Agent Phishing nutzt dagegen eine plausible Anfrage über einen normalen Kommunikationskanal — und scheitert daran, dass der Agent Identität und Berechtigung nicht ausreichend prüft, bevor er handelt.
Der Branchenkontext: Agenten verändern die Sicherheitsgrenze
Die OpenClaw-Fälle passen in ein Muster, das in den vergangenen Wochen deutlicher geworden ist: Agenten sind keine Chatbots mit besserem Interface. Sie sind nicht-menschliche Akteure mit Kontextzugriff, Werkzeugrechten und potenziellen Seiteneffekten.
Frühere Supply-Chain-Fälle rund um Skills oder Erweiterungen drehten sich vor allem um die Frage, welche Komponenten ein Agent installiert und ausführt. Die aktuellen Untersuchungen verschieben den Fokus auf alltägliche Eingaben: Kontakte, E-Mails, Standortdaten, Anhänge, Tickets und interne Dokumente.
Damit verändern sich Trust-Boundaries. In klassischen Anwendungen ist eine E-Mail zunächst Dateninput. In agentischen Workflows kann dieselbe E-Mail zur Aufgabenbeschreibung, Priorisierung, Tool-Auswahl und Kommunikationsfreigabe beitragen. Wenn der Agent zusätzlich interne Daten lesen und extern senden kann, entsteht das, was Simon Willison als „lethal trifecta“ beschrieben hat: Zugriff auf private Daten, Verarbeitung untrusted Contents und ein Kanal nach außen.
Konkrete Implikationen für Unternehmen
Erstens sollten Unternehmen ihre agentischen Workflows inventarisieren. Welche Systeme lesen E-Mails, Tickets, Slack- oder Teams-Nachrichten, Kalender, CRM-Einträge oder Kundendokumente? Welche davon dürfen Dateien lesen, Datenbanken abfragen, Credentials nutzen oder externe Nachrichten versenden? Ohne diese Übersicht bleibt jede Risikobewertung spekulativ.
Zweitens reicht ein System-Prompt nicht als Sicherheitsgrenze. Regeln wie „prüfe den Absender“ oder „gib keine Secrets weiter“ sind sinnvoll. Sie müssen aber technisch abgesichert werden: durch Tool-Allowlisting, Datenklassifizierung, getrennte Berechtigungen, Bestätigungsschritte für sensible Aktionen, Egress-Regeln und revisionssichere Logs.
Drittens sollten Unternehmen Lesen und Handeln trennen. Ein Agent kann E-Mails priorisieren oder Antwortentwürfe erstellen, ohne eigenständig Zugangsdaten, Kundendaten oder Exporte zu versenden. Für Aktionen mit Datenabfluss, Credential-Zugriff oder Änderungen an produktiven Systemen braucht es explizite Freigaben und policy-basierte Gates.
Viertens muss untrusted Metadata als eigener Angriffsvektor behandelt werden. Nicht nur Webseiten und PDFs können Prompt-Injection-Inhalte tragen. Auch Kontaktfelder, Kalenderbeschreibungen, Dateinamen, Alt-Texte, Chat-Metadaten oder API-Antworten können Modellkontext beeinflussen. Die Serialisierung solcher Objekte sollte markiert, begrenzt und möglichst vom Handlungskontext getrennt werden.
Risiken und Limitierungen
Nicht jede OpenClaw-Installation ist automatisch gefährdet. Das konkrete technische Problem aus der Imperva-Analyse wurde nach Angaben der Forscher in Version 2026.4.23 behoben. Zudem hängt das Risiko stark davon ab, welche Integrationen aktiv sind, ob Execution-Sandboxing genutzt wird, welche Secrets erreichbar sind und ob der Agent ohne menschliche Freigabe nach außen kommunizieren darf.
Gleichzeitig wäre es falsch, den Fall als reines OpenClaw-Problem abzutun. Imperva weist selbst darauf hin, dass ähnliche Muster auch in anderen persönlichen KI-Assistenten auftreten können. Varonis zeigt zusätzlich, dass manche Risiken nicht einfach patchbar sind. Sie entstehen aus Geschäftslogik und Berechtigungsmodell. Ein Agent, der Daten lesen und E-Mails senden darf, braucht mehr als besseres Prompting.
Fazit
Die neuen OpenClaw-Untersuchungen markieren die nächste Phase der AI-Security. Der kritische Punkt ist nicht nur das Modell. Entscheidend ist die Übergabe von untrusted Kontext in eine Umgebung mit Tool-Rechten. Unternehmen sollten Agenten deshalb wie produktive Identitäten behandeln: mit minimalen Rechten, klaren Trust-Boundaries, geprüften Datenflüssen, Egress-Kontrollen und menschlichen Gates für sensible Aktionen.
Der praktische Schritt ist überschaubar: OpenClaw-Instanzen auf mindestens Version 2026.4.23 aktualisieren, aktive Integrationen prüfen, Secrets aus Agentenkontexten entfernen, externe Sendefunktionen begrenzen und Tests mit realistischen Phishing- sowie Prompt-Injection-Szenarien durchführen.
Wer KI-Agenten produktiv einsetzen will, muss nicht in Panik verfallen. Er muss aber akzeptieren, dass jede Nachricht, jedes Objekt und jedes Metadatum im Agentenkontext sicherheitsrelevant sein kann.
Quellen: Imperva, „Compromise OpenClaw with Prompt Injections in Message Objects“, 10. Juni 2026; Varonis Threat Labs, „Phishing for Lobsters: How We Tricked OpenClaw into Spilling Secrets“, 9. Juni 2026; The Hacker News, „New Attacks Trick OpenClaw AI Agent Into Running Code and Leaking Secrets“, 11. Juni 2026.
