Prompt-Injection wirkt oft wie ein Labortrick gegen einen Spielzeug-Chatbot. Der neue Bericht von PromptArmor zu Atlassian Rovo ist praktischer: Er beschreibt ein Unternehmensrisiko. Ein KI-Assistent liest private Arbeitsdaten, verarbeitet nicht vertrauenswürdige Inhalte und hat weiterhin einen Weg zu einer externen Adresse. Genau dort muss die Sicherheitsgrenze liegen.

KI-Assistent wird von einer Sicherheitsbarriere gestoppt, bevor Unternehmensdokumente an ein externes Netzwerk gehen

PromptArmor veröffentlichte den Bericht am 5. August 2026. Die Forscher behaupten, Rovo könne durch eine versteckte Anweisung dazu gebracht werden, Inhalte aus Jira-Tickets und Confluence-Dokumenten an eine vom Angreifer kontrollierte Website zu senden. Nach eigenen Angaben meldeten sie das Problem am 23. Mai an Atlassian, erhielten am 25. Mai eine Fallnummer, fragten im Juni und Juli erneut nach und veröffentlichten nach mehr als zwei Monaten ohne öffentliche Behebung oder weitere Antwort. Zum Zeitpunkt der Redaktion fand ich keine öffentliche Atlassian-Stellungnahme, die den Bericht widerlegt.

Das bedeutet nicht, dass bei allen Atlassian-Kunden Daten abgeflossen sind. Öffentlich beschrieben ist eine demonstrierte Angriffskette, keine bestätigte Massenausnutzung. Die richtige Reaktion ist keine Panik, sondern eine nüchterne Prüfung: KI-Assistenten in Unternehmenssoftware sind Programme mit Datenrechten und Netzwerkfähigkeiten.

Lesen ist nur die halbe Grenze

Rovo ist Atlassians KI-Schicht für Jira, Confluence und verbundene Dienste. Atlassian beschreibt Rovo als Assistenten, der das Geschäft kennt, Kontext aus Personen, Projekten und Code zusammenführt und SaaS-Anwendungen von Drittanbietern verbindet. Die Connector-Seite nennt unter anderem Google Drive, GitHub, GitLab, Microsoft SharePoint, Outlook Mail, Gmail, Zendesk, Box, Dropbox, Figma, Azure DevOps, ServiceNow und Slack.

Das ist der Nutzen und zugleich das Risikomodell. In Jira und Confluence liegen oft Roadmaps, Kundenmeldungen, Sicherheitsnotizen, Entwicklungspläne, interne Verfahren und Links zu anderen Systemen. Ein nützlicher Assistent braucht diesen Kontext. Ein sicherer Assistent braucht klare Regeln, wohin dieser Kontext gelangen darf.

Atlassians Vertrauensseiten sagen, dass Plattform- und Connector-Berechtigungen bei korrekter Konfiguration respektiert werden. Sie erklären auch, dass administrierte Drittanbieter-Connectoren nicht standardmäßig aktiv sind und dass für Quellen wie Google Drive oder SharePoint Freigabe- oder Sperrlisten möglich sind. Das ist wichtig, beantwortet aber nicht die konkrete Frage: Kann der Assistent Daten, die er lesen darf, in eine externe Anfrage einfügen, die das Modell selbst gebaut hat?

Die beschriebene Kette

Zuerst gelangt nicht vertrauenswürdiger Inhalt in einen Bereich, den der Assistent lesen kann. Im Beispiel von PromptArmor ist es eine Datei mit versteckten Anweisungen. Laut den Forschern kann derselbe Typ Inhalt aber auch aus Support-Tickets, externen Dokumenten, verbundenen Anwendungen oder Webdaten stammen, wenn Suche aktiviert ist.

Dann bittet der Nutzer Rovo um eine normale Aufgabe, etwa Tickets zu ordnen. Rovo durchsucht Jira und Confluence, weil das seine Aufgabe ist. Die versteckte Anweisung versucht, vertrauliche Inhalte in eine externe Adresse einzubauen. Das URL-Werkzeug öffnet diese Adresse, und der empfangende Server kann die Daten protokollieren.

Der entscheidende Punkt ist das URL-Werkzeug. PromptArmor schreibt, der Angriff funktioniere auch bei deaktivierter Websuche, weil diese Einstellung nicht das Werkzeug zum Öffnen von Ergebnisadressen entfernt. Eine sichtbare Suchfunktion auszuschalten bedeutet also nicht zwingend, dass alle Netzwerkpfade geschlossen sind.

Nicht nur das Modell ist schuld

Es greift zu kurz, dem Modell Leichtgläubigkeit vorzuwerfen. Das Modell arbeitet in einem Werkzeugsystem. Wenn dieses System private Daten und externe Kommunikation bereitstellt, darf das Urteil des Modells nicht die Sicherheitskontrolle sein.

Simon Willisоns Formel hilft: private Daten, nicht vertrauenswürdiger Inhalt und externe Kommunikation. Zwei Elemente lassen sich oft beherrschen. Alle drei zusammen erzeugen einen Abflussweg. Rovo ist damit nicht einzigartig; dasselbe Muster kann bei Browser-Agenten, Code-Assistenten, Bürotools, Support-Bots und internen Suchsystemen entstehen.

Die Abwehr muss deterministisch sein. Ein Werkzeug zum Öffnen von Adressen sollte keine beliebige URL abrufen dürfen, die das Modell zusammensetzt. Sicherer ist es, nur Adressen zu erlauben, die der Nutzer selbst eingegeben hat oder die von einer vertrauenswürdigen Komponente stammen. Auch entfernte Bilder in Markdown sind Netzwerkaufrufe und können als Signalgeber missbraucht werden.

Was Administratoren prüfen sollten

Prüfen Sie zuerst, ob Rovo und Atlassian-KI in Ihrer Organisation aktiv sind. Verlassen Sie sich nicht auf eine Produktseite, sondern auf die echte Administrationskonsole Ihres Tenants.

Erstellen Sie eine Liste der Connectoren. Besondere Aufmerksamkeit verdienen breite Dokumentenquellen, Codeplattformen, Supportsysteme und E-Mail: Google Drive, SharePoint, GitHub, GitLab, Zendesk, ServiceNow, Gmail und Outlook. Ein Connector, der für Suche sinnvoll ist, kann riskanter werden, wenn ein Assistent Ergebnisse mit nicht vertrauenswürdigen Anweisungen und externen Anfragen kombiniert.

Begrenzen Sie Daten nach dem Prinzip minimaler Rechte. Verbinden Sie nicht ganze Laufwerke oder SharePoint-Wurzeln, wenn eine kleinere Freigabeliste genügt. Prüfen Sie Gruppen, Gäste, Dienstleister und alte Konten.

Stellen Sie Atlassian eine konkrete Frage: Kann Rovo bei deaktivierter Websuche eine vom Modell erzeugte URL öffnen? Falls ja, lässt sich diese Fähigkeit abschalten, auf vertrauenswürdige Quellen begrenzen oder vollständig protokollieren?

Blockieren Sie nach Möglichkeit externe Adressen, die vom Modell zusammengesetzt werden. Netzwerkprotokolle, Proxy-Regeln oder Schutz vor Datenabfluss können sensible Daten in ausgehenden Parametern sichtbar machen. Behandeln Sie entfernte Bilder, Vorschauen und Markdown als Netzwerkaufrufe. Verlangen Sie menschliche Freigabe, wenn interne Daten nach außen kommuniziert werden sollen.

Was Nutzer tun können

Laden Sie keine beliebigen externen Dateien in einen Assistenten hoch, der zugleich Zugriff auf sensible Tickets und Dokumente hat. Seien Sie vorsichtig, wenn ein privilegierter Assistent unbekannte Kundenanhänge, Lieferantendokumente oder Webseiten zusammenfassen soll. Wenn der Assistent unerwartet externe Links öffnen will, merkwürdige Bildreferenzen erzeugt oder Text ausgibt, der wie eine versteckte Anweisung wirkt, melden Sie es.

Die Lehre ist einfach: “Das Modell sollte wissen, dass es nichts verraten darf” ist keine Sicherheitsmaßnahme. Die Grenze gehört in die Werkzeugebene: Freigabelisten, Datenklassenprüfungen, Herkunftsregeln, Freigaben, Protokolle und sichere Voreinstellungen. Bei einem Assistenten mit Zugriff auf Jira, Confluence, Mail, Dokumente und Code zählt nicht, wie klug er wirkt. Entscheidend ist, was er lesen, anzeigen, aufrufen und senden kann — und wer das überprüft.