What was reported
Rovo is Atlassian's multi-purpose AI agent, operating across the company's product suite including Jira and Confluence. What PromptArmor published is a report that data inside an Atlassian tenant — the workspace tied to a customer account — can be taken out through Rovo.
What makes it notable is how little is required. The report describes it as zero-click: it succeeds without the user pressing an approval button. The target is Rovo's URL retrieval tool, which the report says has no protections against opening a URL the agent constructed itself.
Atlassian AI ‘Rovo’ is susceptible to zero-click data exfiltration via indirect prompt injection, bypassing organization-level web search controls. ／ Atlassian’s Rovo AI is a multi-purpose agent that operates across Atlassian’s product suite (Jira, Confluence, etc.). ／ Vulnerabilities have been identified that enable data exfiltration across an Atlassian tenant (Jira tickets, Confluence docs, etc.) via indirect prompt injection. ／ This attack executes without requiring any human-in-the-loop approval, and succeeds by exploiting Rovo’s URL retrieval tool. — From the passages on the nature of the vulnerability, the products in scope, the data that can leak, and the absence of an approval step
Why a setting change does not stop it
The first control an administrator reaches for is turning off web search. The report rejects that directly.
The attack succeeds even with web search disabled. Turning the setting off does not remove the tool for opening the search results. The entrance is closed while the route out remains open.
The report includes a screenshot of the organisation-wide "Enable web search" setting toggled off, with the attack succeeding under that condition.
The awkward part is what the attack leaves behind. If the user returns to the chat later, they see the ticket updates the agent proposed, but no evidence of the attack. There is nothing on the user's side to notice.
This attack succeeds even if an organization has disabled web search for Rovo. This is because the web search setting fails to remove the tool for opening the search results. ／ Rovo’s URL retrieval tool is insecure: there are no protections against opening a URL that has been dynamically created by the agent. ／ The organization-wide ‘Enable web search’ setting for Rovo is toggled off. ／ If the user returns to the chat later, they see the agent's suggested ticket updates, but no evidence of the attack. — From the passages on why the web search setting is not a defence, the lack of protection on the URL retrieval tool, the configuration used in testing, and the absence of traces afterwards
There is more than one way in
What the report emphasises is that the injection does not have to arrive by one particular route.
The demonstration used a user handing Rovo a document — finding a file online and uploading it, which the report notes is quite common. But it states explicitly that the attack is not dependent on the injection source. Other routes it names are externally sourced data inside Atlassian such as support tickets, web data where search is enabled, and third-party connectors.
"Don't open suspicious files" is not a defence that holds. The paths by which text from outside an organisation reaches an agent's eyes run all through the systems people work in.
The report also covers Markdown image rendering as a separate route. Rendering image syntax that appears in AI output is, it notes, a well-known vector for exfiltration via indirect prompt injection.
For general use cases, this is quite common: a user finds a file online and uploads it to Rovo. ／ This attack is not dependent on the injection source - other injection sources include, but are not limited to: external data in Atlassian (e.g., support tickets), web data (if search is enabled), third-party ‘connectors’, etc. ／ Atlassian Rovo also renders Markdown images from AI outputs. ／ Insecure Markdown image rendering is a well-known vector for data exfiltration via indirect prompt injection. — From the passages on how ordinary the demonstrated route is, the independence from the injection source and the other routes named, and Markdown image rendering as a separate vector
From disclosure to publication
The timeline is published as well. PromptArmor disclosed on May 23. Atlassian assigned a case number and expressed thanks.
What followed is the problem. According to PromptArmor, after multiple follow-ups over more than two months there was no further communication, and Rovo remains vulnerable. Publishing to inform users of the risks is given as the reason for going public.
This is PromptArmor's account, though, and Atlassian's position could not be confirmed as of writing. It should be read as a timeline given by one party.
PromptArmor disclosed the vulnerabilities covered in this article to Atlassian on May 23rd. ／ Atlassian assigned a case number and expressed thanks, but after multiple follow-ups by PromptArmor over more than two months, Atlassian has made no further communication, and Rovo remains vulnerable. ／ As such, we are publishing to inform users of the risks. — From the passages on the disclosure date, Atlassian's initial response and what followed, and the reason for publishing
What to review on the user side
What this pushes at is that the read permissions you grant an AI agent become the range of what can leak. The flip side of that is straightforward: what you never showed it cannot leave.
The review starts with an inventory of connectors. Then the question of whether the range you let the agent read is genuinely the range the work requires. The point of the report is that this is not a situation one settings toggle resolves.
The same shape appears in the incident the UK AISI published from its evaluations, where what finally stopped it was a person. As a design that avoids distributing permissions in the first place, Cloudflare OS's approach of never handing the agent a key is the contrasting answer.
The prompt injection can exfiltrate any data the agent can access in Atlassian, including any data the agent can access via ‘connectors’. — From the passage stating that the range of data at risk matches the agent's own access
