Viele Unternehmen führen KI-Assistenten zuerst dort ein, wo der Produktivitätsgewinn offensichtlich ist: Tickets zusammenfassen, Confluence-Seiten durchsuchen, Projektstände erklären, Aufgaben vorbereiten. Genau dort liegt aber auch das Sicherheitsproblem. Ein Assistent wie Atlassian Rovo arbeitet nicht am Rand der Organisation, sondern mitten im Wissensbestand: Jira, Confluence, Bitbucket und angebundene SaaS-Quellen werden zu einem gemeinsamen Kontext. Wenn dieser Kontext nicht sauber zwischen Daten und Anweisungen trennt, kann ein normaler Nutzerklick oder ein präpariertes Dokument reichen, damit erlaubte interne Informationen unerlaubt nach außen fließen.
Aktuelle Veröffentlichungen von PromptArmor, Varonis und Bugcrowd machen dieses Risiko greifbar. Es geht nicht um einen klassischen Login-Bypass und auch nicht um eine Schwachstelle, die einem Angreifer plötzlich globale Administratorrechte verschafft. Die stärkere Lehre ist unbequemer: Der Agent tut im Kern das, wofür er gebaut wurde – er liest Unternehmensdaten im Namen eines angemeldeten Nutzers, kombiniert sie und ruft externe Ressourcen auf. Genau diese Kette muss in Enterprise-KI-Architekturen als eigener Sicherheitsfall behandelt werden.
Was technisch passiert ist
PromptArmor veröffentlichte am 5. August 2026 einen Angriff auf Atlassian Rovo, bei dem ein indirekter Prompt-Injection-Text in eine Datei eingebettet wurde. Der Nutzer lädt die Datei hoch und bittet Rovo beispielsweise, Jira-Tickets zu organisieren. Rovo liest daraufhin die präparierten Inhalte, sucht in Jira und Confluence und wird durch die versteckte Anweisung dazu gebracht, gefundene Informationen an eine vom Angreifer kontrollierte URL anzuhängen. Der externe Server sieht die Daten dann in seinen Logs.
Wichtig ist die Einordnung: Das ist nicht sauber als „Zero Click“ im klassischen Sinn zu bezeichnen. Der Nutzer muss den Agenten mit dem manipulierten Inhalt in Kontakt bringen und eine normale Aufgabe starten. Laut PromptArmor braucht die eigentliche Exfiltration aber keine gesonderte menschliche Freigabe. Kritisch ist außerdem die Behauptung, dass der Angriff auch dann funktionierte, wenn die organisationsweite Websuche für Rovo deaktiviert war. PromptArmor führt das darauf zurück, dass nicht geprüft wurde, ob eine URL vom Agenten selbst dynamisch konstruiert wurde. Der Websuche-Schalter entfernte demnach nicht die relevante URL-Abrufmöglichkeit.
Varonis beschrieb am 7. August 2026 eine zweite, anders gelagerte Route namens „RovoBlast“. Hier stand der URL-Parameter rovoChatPrompt im Mittelpunkt. Ein präparierter Link konnte einen Prompt in Rovo Chat vorbefüllen. Klickt ein angemeldeter Nutzer auf diesen Link, verarbeitet Rovo die eingebetteten Anweisungen innerhalb der legitimen Nutzersitzung. In der veröffentlichten Beschreibung konnte Rovo dadurch Informationen suchen, zusammenführen und über eine externe Bild- oder URL-Anfrage an den Angreifer senden.
Der Bugcrowd-Eintrag zur RovoBlast-Meldung ist besonders hilfreich, weil er Status und Zeitlinie dokumentiert. Die Schwachstelle wurde am 4. November 2025 gemeldet, am 6. Januar 2026 als P2 triagiert und mit 6.000 US-Dollar prämiert. Atlassian markierte sie am 8. Juli 2026 als behoben; die Veröffentlichung erfolgte im Juli. Bugcrowd beschreibt den Fehler als Information Disclosure in Rovo und nennt Confluence, Jira sowie über Konnektoren erreichbare Quellen wie SharePoint und Outlook als getestete beziehungsweise betroffene Datenflächen.
Warum das für Unternehmen relevant ist
Der eigentliche Blast Radius entsteht nicht durch ein einzelnes Produktdetail, sondern durch die Rolle moderner KI-Assistenten. Rovo ist laut Atlassian auf Standard-, Premium- und Enterprise-Plänen verfügbar; in der Dokumentation heißt es, dass Nutzer einer Organisation Zugriff auf Rovo-Funktionen erhalten können. Gleichzeitig arbeitet Rovo mit Berechtigungen und Konnektoren: Es soll nur Inhalte anzeigen, die ein Nutzer sehen darf, kann aber über Jira, Confluence und Drittanbieterquellen hinweg suchen und zusammenfassen.
Genau hier liegt der Unterschied zu vielen älteren Web-Schwachstellen. Wenn ein Agent Daten exfiltriert, ist die Frage nicht nur: „Wurde eine Berechtigungsprüfung umgangen?“ Die Frage lautet auch: „Darf ein Agent, der sensible Daten lesen kann, selbstständig einen externen Kommunikationspfad konstruieren?“ Bestehende Berechtigungen begrenzen zwar, was der einzelne Nutzer sieht. Sie verhindern aber nicht automatisch, dass der Agent diese erlaubten Daten in einen nicht vorgesehenen Kanal schreibt.
Das Muster ist aus anderen Agenten- und Copilot-Fällen bekannt: untrusted input, trusted identity, external sink. Ein Ticket, eine Confluence-Seite, ein Link, ein Dokument oder eine Chat-Nachricht ist zunächst Datenmaterial. Sobald ein LLM-Agent daraus Handlungsanweisungen ableitet, wird dieses Datenmaterial zur Steuerfläche. Wenn derselbe Agent zugleich interne Suche, Zusammenfassung, URL-Fetching, Markdown-Rendering oder Konnektoren bedienen kann, entsteht eine Kette, die klassische DLP- und Webfilterregeln oft nicht sauber abbilden.
Konkrete Implikationen für Sicherheits- und Plattformteams
Erstens sollten Unternehmen KI-Assistenten nicht nur nach Datenzugriff, sondern nach Ausgabekanälen modellieren. Welche Tools darf der Agent nutzen? Darf er externe URLs öffnen? Werden vom Modell erzeugte Links, Bilder oder Webhooks ohne Bestätigung geladen? Gibt es Unterschiede zwischen Websuche, URL-Retrieval und Markdown-Rendering? Ein deaktivierter Websuche-Schalter ist nur dann eine Sicherheitskontrolle, wenn alle alternativen externen Pfade ebenfalls erfasst sind.
Zweitens braucht Agentenbetrieb eine explizite Prompt-Injection-Annahme. Inhalte aus Tickets, Dokumenten, Webseiten, E-Mails und Konnektoren sollten grundsätzlich als potenziell feindlich gelten. Das bedeutet nicht, KI-Assistenten abzuschalten. Es bedeutet, dass Tool-Aufrufe mit Datenabflusswirkung – externe Fetches, Bild-Rendering, Mailversand, Ticketänderungen, Webhooks – eine andere Kontrollklasse brauchen als interne Leseoperationen.
Drittens sollten Berechtigungen für Rovo und ähnliche Systeme enger geschnitten werden als für menschliche Nutzer. Atlassian dokumentiert Möglichkeiten, Rovo-Funktionen für unterstützte Apps zu blockieren und in Enterprise-Umgebungen nach Apps und Nutzergruppen zu steuern. Das ist kein Allheilmittel, aber ein wichtiger Hebel: Nicht jede Gruppe, die Jira oder Confluence lesen darf, muss auch einen agentischen Such- und Aktionslayer darüber erhalten.
Viertens gehört Monitoring auf die Agentenebene. Logs sollten nicht nur zeigen, welcher Nutzer welche Seite geöffnet hat, sondern welche Quellen der Agent gelesen, welche Tool-Aufrufe er ausgelöst und welche externen Ziele er kontaktiert hat. Besonders verdächtig sind dynamisch erzeugte URLs mit langen Pfad- oder Query-Parametern, ungewöhnliche Bildabrufe, wiederholte URL-Fetches nach internen Suchoperationen und Agentenläufe, die sensible Projektnamen oder Schlüsselwörter mit externen Domains kombinieren.
Risiken und Grenzen der aktuellen Befunde
Die Berichte zeigen kein bekanntes massenhaftes Ausnutzen in freier Wildbahn. Für den Bugcrowd-Fall ist eine serverseitige Behebung dokumentiert. Für die von PromptArmor beschriebene content-basierte Route ist öffentlich vor allem der Stand der Veröffentlichung belegt; The Hacker News berichtete am 8. August, dass kein eindeutiges Post-Publication-Update gefunden wurde. Unternehmen sollten daher nicht aus einzelnen Schlagzeilen ableiten, dass jede Rovo-Instanz aktuell kompromittierbar ist. Sie sollten aber den Kontrolltyp ernst nehmen.
Ebenso wichtig: Der Zugriff folgt nach den verfügbaren Informationen den Rechten des angemeldeten Nutzers. Das reduziert die Reichweite gegenüber einem Tenant-weiten Admin-Bypass, macht den Fall aber nicht harmlos. In vielen Organisationen haben Projektleiter, Entwickler, Support-Mitarbeiter oder Produktmanager Zugriff auf genug interne Dokumente, Tickets, Kundendaten oder technische Secrets, um einen relevanten Vorfall auszulösen.
Fazit
RovoBlast und die PromptArmor-Demonstration sind weniger ein isoliertes Atlassian-Problem als ein Architekturhinweis für Enterprise-KI. Agenten, die Unternehmensdaten lesen und externe Aktionen ausführen können, brauchen Kontrollen am Übergang von Kontext zu Handlung. Websuche deaktivieren, Berechtigungen korrekt setzen und auf Hersteller-Patches warten reicht nicht aus. Unternehmen sollten Agenten wie neue Integrationsplattformen behandeln: mit minimalem Zugriff, kontrollierten Ausgabekanälen, prüfbaren Tool-Aufrufen, gruppenbasiertem Rollout und klaren Regeln für untrusted content. Produktivität entsteht durch Verbindung von Daten. Sicherheit entsteht erst, wenn diese Verbindung nicht automatisch auch zum Datenabflusskanal wird.
Quellen: PromptArmor („Atlassian Rovo Exfiltrates Data, Bypassing Controls“, 5. August 2026), Varonis („RovoBlast“, 7. August 2026), Bugcrowd-Disclosure zu rovoChatPrompt, Atlassian Support-Dokumentation zu Rovo-Zugriff und Datenschutz, The Hacker News (8. August 2026).
