Atlassian Rovo is designed to make Jira and Confluence easier to search, summarize, and act on. That usefulness is also what makes the latest prompt-injection research important for security teams: if an assistant can see sensitive project data on behalf of a user, an attacker who influences the assistant’s instructions may be able to turn that access into a data-exfiltration path.

According to reporting from The Hacker News, two separate security firms found ways to make Rovo collect information available to a signed-in user and send it to attacker-controlled infrastructure. One path, involving a preloaded chat prompt in a URL parameter, has reportedly been fixed server-side by Atlassian. Another path, involving malicious instructions hidden in content that Rovo reads, was reported as still working at the time of PromptArmor’s August 5 publication. Organizations using Rovo should therefore treat this as a configuration, monitoring, and data-governance issue—not simply as a traditional patch-management item.

What happened

The core issue is indirect prompt injection. Instead of attacking the application with a conventional exploit, the attacker places instructions in content the AI assistant may process: a document, page, ticket, or link. When a user asks the assistant to help with legitimate work, the model can treat attacker-supplied text as operational instructions.

In the reported PromptArmor scenario, a document contained hidden directions for Rovo. When the assistant was asked to organize Jira tickets, it could search Jira and Confluence, collect data visible to the user, append that data to an external URL, and make a request that exposed the information to an attacker-controlled server. The notable risk is not that Rovo gains more permissions than the user; it is that it can automate misuse of the permissions the user already has.

Varonis Threat Labs described a different route, dubbed RovoBlast, where an attacker could use a rovoChatPrompt URL parameter to preload instructions into Rovo Chat. A signed-in user clicking the crafted link could cause Rovo to act with that user’s privileges. The Bugcrowd record cited in the report says Atlassian fixed that link-based issue on July 8, 2026 and that the fix was validated.

Why this matters to security teams

Many organizations think of AI assistants as productivity features, but assistants connected to Jira and Confluence sit close to high-value information: incident notes, architectural diagrams, roadmaps, customer issues, support escalations, credentials accidentally pasted into tickets, and internal discussions about vulnerabilities. Even when each individual user has “appropriate” access, a compromised workflow can aggregate and export more data than a person would normally review manually.

Treat AI assistants as privileged data paths, not just chat interfaces. If an assistant can query multiple systems, combine results, render Markdown, call URLs, or fetch external resources, it needs controls similar to those used for integrations and automation accounts. The threat model should include content that is intentionally crafted to manipulate the assistant, including files received from outside the organization, copied web content, imported support material, and pages edited by less-trusted collaborators.

Immediate defensive actions

First, review who can use Rovo. Limit access to groups with a clear business need, especially while prompt-injection protections and logging mature. If Rovo is enabled broadly by default, consider a temporary reduction in scope for users who can access sensitive projects, security workspaces, executive planning areas, legal matters, or customer-confidential spaces.

Second, audit Jira and Confluence permissions. Prompt injection becomes more damaging when users have broad read access “just in case.” Reduce inherited global access, remove stale groups, and separate highly sensitive spaces from everyday collaboration areas. Least privilege is still one of the strongest mitigations when an AI assistant acts on behalf of a user.

Third, review web-search and external-resource settings, but do not rely on a single toggle as a complete control. The reported PromptArmor chain is significant because it allegedly worked even when Rovo’s web-search option was disabled, using a separate URL-retrieval behavior. Administrators should verify how outbound requests are governed in their own Atlassian environment and ask vendors for precise documentation of which AI actions are covered by each setting.

Fourth, monitor for suspicious outbound activity. Look for assistant-generated requests to unfamiliar domains, long URLs containing encoded internal text, unusual Markdown image loads, or repeated access patterns that combine internal search with external fetches. If logs do not currently expose these events with enough detail, that gap should be documented as a risk.

User guidance that actually helps

Generic advice such as “do not trust AI” is unlikely to change behavior. Give users concrete rules: do not ask Rovo to process untrusted files in sensitive projects; be cautious with links that open Rovo Chat or prefill prompts; avoid running assistant-suggested actions when the prompt includes odd instructions, external URLs, or requests to ignore previous rules; and report unexpected assistant behavior as a security event.

Security teams should also create test cases. Place benign canary strings in controlled Jira or Confluence pages, run approved Rovo workflows, and confirm those strings do not appear in outbound network logs, rendered image requests, or unexpected destinations. This kind of validation is especially useful after vendor-side changes because cloud AI features can change without a customer-applied patch.

Longer-term controls to request from vendors

Enterprises should expect AI assistants to distinguish between trusted user instructions and untrusted retrieved content. They should also provide explicit approval for external transmissions, allow domain allowlisting, block model-generated URLs that contain internal data, expose detailed audit logs, and provide tenant-level controls for tool use. A secure assistant should not silently move data from private workspaces to arbitrary external endpoints.

For now, the practical takeaway is straightforward: connected AI assistants expand the blast radius of ordinary collaboration data. If Rovo is active in your organization, verify the vendor-side fix status, narrow access where possible, tighten Jira and Confluence permissions, and monitor for external data movement initiated through AI workflows.

Source: The Hacker News source