Atlassian Rovo Prompt Injection: SaaS Data Checklist

An AI assistant becomes a security boundary when it can read internal work, combine information from several platforms, and reach outside services. That is the lesson behind two recent Atlassian Rovo disclosures. Varonis Threat Labs showed that one crafted link could seed instructions into an authenticated Rovo session. PromptArmor separately showed that hidden instructions in a document or other ingested content could redirect Rovo toward an attacker-controlled URL.

The reports are not evidence of active exploitation in customer environments, and they are not the same vulnerability. The one-click RovoBlast path was fixed by Atlassian. The separately reported indirect prompt-injection path was described by PromptArmor as unresolved when it published on August 5, 2026; no later public fix confirmation was identified as of August 11. For SMB leaders, the right response is neither panic nor dismissal. It is a measured review of who can use Rovo, what it can reach, what it can automate, what telemetry exists, and how quickly access can be reduced if an investigation begins.

RovoBlast and the Zero-Click Path Are Different Findings

Varonis published RovoBlast on August 7, 2026. The issue involved the rovoChatPrompt query parameter used by Rovo Chat. An attacker could place a malicious prompt inside a crafted home.atlassian.com/chat link. When a signed-in user clicked it, Rovo accepted the externally supplied text as a user request without a meaningful warning or confirmation. The proof of concept then used an outbound image request to place data in a URL received by an attacker-controlled server.

RovoBlast required one click and an authenticated victim with access to the targeted information. It was not an authentication bypass, a tenant boundary break, or a zero-click exploit. Atlassian’s public Bugcrowd disclosure classifies it as a P2 information-disclosure vulnerability, says the server-side fix was deployed July 8, and records that the reporter validated the fix. Customers do not have a Rovo server package to patch for this cloud-side remediation.

PromptArmor’s August 5 disclosure described a separate indirect prompt-injection chain. In its demonstration, a user uploaded a file containing concealed instructions and then asked Rovo to perform an ordinary task involving Jira tickets. The hidden instructions caused Rovo to collect accessible Jira and Confluence information, append that data to an attacker-controlled URL, and call a URL-retrieval tool. PromptArmor also identified Markdown image rendering as another potential outbound path.

“Zero-click” needs careful interpretation. The demonstration included normal user activity: a file was uploaded and Rovo was asked to do work. Zero-click means the victim did not click an attacker’s exfiltration link or separately approve the outbound transfer after the poisoned content entered the model’s context. Equivalent content could potentially enter through a support ticket, a connected data source, web content, or an automated workflow. It does not mean an unauthenticated attacker can silently dump any Atlassian tenant without Rovo processing attacker-controlled material.

Why Normal User Permissions Do Not Eliminate Exposure

Atlassian says Rovo respects permissions in Atlassian products and connected systems. That is an important control: a user should not receive a private Confluence page or SharePoint file they cannot normally access. But authorization answers “may this identity read the data?” It does not answer “did this person intend for an AI agent to collect it for this purpose and send it to this destination?”

Neither research team demonstrated a source-system access-control bypass. The concern is confused intent. A manipulated assistant uses the victim’s legitimate permissions to retrieve information and an allowed tool to move it elsewhere. Least privilege reduces the maximum loss, but it does not make poisoned instructions trustworthy. A finance leader may appropriately access forecasts, contracts, selected Jira projects, and email. A hijacked AI session can potentially consolidate that scattered access much faster than a person could.

This makes oversharing a direct AI risk. Public-to-the-organization Confluence pages, broadly visible Jira projects, inherited SharePoint access, permissive Slack channels, and group memberships accumulated over years all become part of the effective Rovo boundary. Review the underlying permissions first. Do not rely on an AI-layer control to compensate for source systems that already expose too much.

How Connectors Expand the SaaS Blast Radius

Rovo’s value comes from joining information that normally lives in separate systems. Atlassian’s Teamwork Graph connector catalog includes Microsoft SharePoint and OneDrive, Outlook mail and calendar, Teams, Slack, Google Drive, Gmail, Google Calendar, GitHub, Salesforce, ServiceNow, Workday, and many other platforms. Varonis reported that Rovo could enumerate Jira, Confluence, Bitbucket, Slack, Microsoft 365, Google Workspace, relational databases, uploaded files, web pages, and archives in its test environment.

Do not translate that catalog into a claim that every connector was individually compromised. The proven demonstrations were narrower. The catalog matters because it shows the potential reach of a manipulated agent in a customer environment. The blast radius is the intersection of four things: connected sources, the user or service identity’s permissions, the agent’s enabled tools, and available outbound channels.

Atlassian documents three connector patterns: synced connectors can index workspace content, direct connectors retrieve content through provider APIs at runtime, and Smart Link connectors use an individual user’s permissions and history. Its Rovo data guidance says an admin-managed connector can index an entire workspace, although some sources support scope controls. For Google Drive and SharePoint, admins can use allowlists or blocklists at the shared-drive or site level. Atlassian also warns that Chat may fetch third-party data at runtime using the user’s source-system access, so an indexing list is not the only permission boundary.

Create a connector register with the business owner, technical owner, connector type, authorizing identity, granted OAuth scopes, indexed locations, runtime permissions, sensitive-data categories, logging source, and emergency revocation method. Include personal user authorizations, not only organization-wide connectors. Atlassian’s unresolved ROVO-634 audit request states that organization audit logs record high-level connector administration but do not currently show each user’s authorization or revocation of a personal third-party connection. That gap makes source-provider OAuth inventories and sign-in logs essential.

What Should Administrators Review Now?

1. Define the exposure window and preserve evidence

Start with the earliest date Rovo, its browser extension, relevant agents, automations, and each connector were enabled. Export records before changing settings when operations are stable enough to do so. Preserve Atlassian organization audit logs, Rovo and Studio configuration screenshots, agent definitions, enabled tools, knowledge sources, automation rules, automation audit logs, connector settings, source-system OAuth consent, identity-provider sign-ins, and secure web gateway or DNS records.

Atlassian says Rovo Chat and agent inputs and outputs are retained for 30 days for safety and security purposes. Jira and Confluence automation audit logs retain activity for 90 days. Open a support case promptly and ask Atlassian to preserve tenant-relevant telemetry before ordinary retention windows expire. Record time zones, export times, and who collected each artifact.

2. Review Rovo and AI activity

Use Atlassian Administration’s audit log to search the full review period. Atlassian’s audit activity database lists Rovo events for created, updated, and deleted agents; started agent chats; definitions; and created, updated, or deleted third-party connector connections. It also records Rovo MCP tool invocations where that service is in use. Correlate each event with the named user, role, device, source address where available, and a documented business reason.

• Identify first-time or unusual Rovo use by executives, administrators, finance, legal, HR, and incident-response staff.
• Review new or modified agents, especially changes to instructions, knowledge sources, tools, sharing, ownership, and group access.
• Inspect available agent conversation reviews and debug logs for unexpected retrievals, unusual summaries, external domains, or instructions that do not match the user’s request.
• Search for repeated agent runs, work performed outside normal hours, and activity inconsistent with the user’s job.
• Compare high-level Rovo events with Jira work-item history, Confluence page history, connected-app logs, and downstream changes.

Do not overstate what the audit log can prove. High-level events may not contain the complete prompt, response, fetched URL, or data returned. PromptArmor showed that a user reopening the chat could see a normal-looking result rather than visible evidence of the hidden transfer. An empty or ordinary chat history is therefore not enough to close the investigation.

3. Inspect automation and autonomous agent paths

Atlassian says agents cannot operate autonomously unless an administrator connects them to an automation rule. That makes automation a concentrated review point. Export every rule that uses a Rovo agent and document its trigger, actor, prompt, knowledge scope, secondary actions, destinations, and owner. Prioritize rules triggered by Jira Service Management submissions, incoming email, webhooks, new attachments, public forms, external comments, or other attacker-influenced fields.

Review each rule’s audit log for trigger time, run status, steps attempted, elapsed time, and any “send web request,” email, comment, page, Slack, Teams, or other publishing action. Atlassian notes that automated agents operate on behalf of the flow creator and assume that creator’s application permissions. Replace personal administrator identities with narrowly scoped service identities where supported, and require review before a model-generated response is sent outside a controlled workspace.

4. Hunt for suspicious prompt and endpoint artifacts

• Search email, chat, proxy, browser, and ticket records for crafted home.atlassian.com/chat links containing rovoChatPrompt, including URL-encoded and shortened variants.
• Review files uploaded to Rovo and documents processed during suspicious sessions for tiny, hidden, white-on-white, off-page, or otherwise concealed instructions.
• Search Jira Service Management tickets, externally created Jira work items, Confluence comments, connected Slack messages, and web content for instruction-like text that attempts to override the task, collect unrelated data, construct a URL, or hide output.
• Hunt secure web gateway, DNS, CASB, browser, and source-system telemetry for unusual domains, long query strings, encoded values, unexpected image requests, or retrievals that immediately follow broad Jira or Confluence access.
• Review connected Microsoft 365, Google Workspace, Slack, Salesforce, ServiceNow, and GitHub logs for unusual searches, bulk reads, exports, or OAuth use by the same identity and time window.

Some Rovo URL requests may originate from Atlassian infrastructure rather than the employee’s endpoint, so endpoint or proxy logs may not contain the full egress event. Ask Atlassian whether it can identify URL-retrieval or image-rendering activity for the affected tenant, provide any indicators, and preserve relevant backend telemetry. Absence from the local proxy is not proof that no server-side request occurred.

5. Reconcile integration scopes with business need

For every connected service, compare the configured OAuth scopes and source permissions with the approved use case. In Microsoft 365, review the enterprise application, admin consent, delegated permissions, sign-ins, SharePoint and OneDrive scope, mailbox access, and any sensitivity-label exclusions. In Google Workspace, review OAuth grants, shared-drive scope, application access controls, and Drive audit activity. In Slack, review installed app permissions, workspace access, and audit events. Repeat the same exercise for every connector in the register.

Use allowlists for SharePoint and Google Drive where practical, and exclude legal, HR, finance, executive, security investigation, credential, and regulated-data repositories unless Rovo has a defined need to read them. A connector approved for search does not automatically need mail, calendar, write, or automation privileges. Good Microsoft 365 governance treats AI connector consent as a privileged application decision, not a convenience toggle.

When Should You Disable Browsing, Automation, Connectors, or Rovo?

Containment should match evidence and uncertainty. Disabling the organization’s Rovo web-search option reduces exposure to public web content and is appropriate when teams do not need that feature. However, PromptArmor reported that this setting did not stop its August test because the separate URL-retrieval capability remained available. Treat web-search disablement as attack-surface reduction, not proof that outbound retrieval is blocked.

Atlassian’s Rovo access controls allow organization admins to block Rovo by app. If several Jira-family apps are present, blocking only one may leave common Rovo features available through another, so verify the complete site configuration. Restrict who can create agents and automations in Studio, delete unknown agents, remove unneeded tools, and disable rules individually when a narrower action is sufficient.

Connector containment also has timing caveats. Atlassian says most Teamwork Graph disconnects can take 48 hours to complete and cached data may remain for up to five minutes after disconnect is initiated. Hiding an app from Search can reduce visibility sooner, but Chat runtime access and source-side authorization must still be considered. When suspected exposure is serious, revoke the authorization or application access in the source platform as well as disconnecting it in Atlassian.

What Should Be Rotated After Suspected Exposure?

Do not rotate every credential simply because Rovo was enabled. Rotate based on what the affected identity and content could expose. If Confluence pages, Jira tickets, SharePoint files, Slack messages, or connected mailboxes contained passwords, API keys, signing secrets, recovery codes, private links, or customer access tokens that Rovo could retrieve during the exposure window, treat those secrets as potentially disclosed and replace them.

1. Revoke active Atlassian and source-system sessions for identities tied to suspicious activity when session misuse cannot be excluded.
2. Revoke connector OAuth grants and tokens that were over-scoped, unknown, or used outside the approved pattern.
3. Rotate reachable application secrets found in pages, tickets, documents, messages, or agent knowledge sources.
4. Replace automation credentials and webhook secrets if a manipulated workflow could read or send them.
5. Validate rejection of old credentials in the source service’s authentication logs and monitor for reuse attempts.

Preserve evidence before mass revocation when active theft is not underway. If exfiltration appears ongoing, containment takes priority; document what was revoked and when. Password changes alone may not invalidate existing OAuth grants or sessions, and disconnecting a connector does not automatically rotate credentials stored elsewhere.

Questions to Put to Atlassian and Your Service Provider

• Was the July 8 server-side RovoBlast remediation applied to every site associated with our organization, and can Atlassian confirm the effective time?
• What is the current remediation status of the URL-retrieval and Markdown-rendering paths described by PromptArmor?
• Can Rovo fetch a dynamically constructed external URL when web search is disabled in our current configuration?
• Which Rovo chats, agent runs, tool calls, URL retrievals, and connector accesses can Atlassian preserve or export for our exposure window?
• Are there tenant-specific indicators of suspicious prompts, external destinations, unusual retrieval volume, or agent behavior?
• Which connectors are synced, direct, Smart Link, or individually authorized, and how quickly can each path be disabled?
• What controls prevent model-generated content from causing an external fetch or action without human confirmation?

Ask for answers in writing and attach them to the risk register. A statement that Rovo “respects permissions” is relevant but incomplete. The control question is whether untrusted content can influence an authorized agent to use those permissions for an unauthorized purpose or destination.

Long term, treat enterprise AI as privileged integration infrastructure. Pilot with a small group, narrow every data source, keep sensitive repositories out of scope, require human approval for consequential or external actions, maintain independent logs, and test emergency shutdown. ITECS can help organizations map this AI trust boundary through AI consulting and governance aligned with broader cybersecurity controls.

Sources

• Varonis Threat Labs — RovoBlast: How One Click Triggered Atlassian’s AI Assistant to Leak Data
• Atlassian Bugcrowd Disclosure — One-Click Data Exfiltration via Rovo Chat Prompt URL Parameter
• PromptArmor — Atlassian Rovo Exfiltrates Data, Bypassing Controls
• Atlassian Support — Rovo data, privacy, and usage guidelines
• Atlassian Support — Manage Teamwork Graph connectors
• Atlassian Support — Manage connector blocklists and allowlists
• Atlassian Support — Audit log activities database
• Atlassian Support — Automation audit logs
• Atlassian Support — Manage Rovo web search
• Atlassian Support — Disconnect an app from Teamwork Graph