How Atlassian Rovo Handles Data Privacy and Security

Data security remains a central concern as organizations look to bring AI into everyday workflows. Leaders want tools that reduce manual effort and help teams move faster, but not at the expense of exposing sensitive data or weakening existing controls. Without clear safeguards, even useful AI features can become difficult to justify.

Rovo is Atlassian’s cross‑product AI layer designed to work across Jira, Confluence, and other Atlassian products. It also extends beyond the Atlassian ecosystem by connecting to third‑party systems such as Google Drive, SharePoint, and GitHub. This broad reach is what gives Rovo much of its value. It allows teams to search, chat, and automate work across multiple tools from a single interface. At the same time, this architecture makes privacy, security, and permissions management especially important.

This article takes a closer look at how Atlassian AI and Rovo address those concerns. We examine how data is used and stored, how access controls are enforced, how third‑party integrations are handled, and what compliance measures are in place.

The goal is to give organizations a clear understanding of where their data goes, how it is protected, and what level of control administrators retain when using Rovo.

How Atlassian Rovo Handles Data Privacy and Security

1. Your Data Is Not Used to Train AI Models

Atlassian draws a firm line around model training.

Customer data submitted to Rovo, both inputs and outputs, is not used to train, fine-tune, or improve:

• Atlassian-hosted models
• Open-source models hosted by Atlassian
• Third-party LLMs such as OpenAI GPT, Anthropic Claude, or Google Gemini

In simple terms:

• Your prompt is used to answer your question
• The response is returned to you
• That data is not retained for training

This same rule applies across Atlassian AI features, not just Rovo.

Important note:
Rovo does retain chat inputs and outputs for up to 30 days. This is for safety, security, and troubleshooting, not for model training. Atlassian states this explicitly, but organizations with strict retention policies should still account for it.

2. Rovo Uses a Hybrid LLM Architecture

Rovo is not tied to a single large language model. Instead, Atlassian uses a documented hybrid architecture that can select from multiple LLM families depending on the task being performed. This approach is designed to balance response quality, latency, and operational efficiency rather than forcing every request through the same model.

Depending on the use case, Rovo may route requests to either Atlassian‑hosted or third‑party models, including OpenAI’s GPT series, Anthropic’s Claude models, Google’s Gemini models, and Atlassian‑hosted or open‑source options such as LLaMA, Phi, and Mixtral or Mistral variants. Model selection happens automatically through Atlassian’s orchestration layer, and customers do not currently have the ability to choose or pin a specific model.

From a security and risk perspective, this design has trade‑offs. Routing some requests to Atlassian‑hosted models can reduce reliance on external providers and limit data movement. At the same time, using multiple model providers makes it important for organizations to understand which services are in scope for their tenant and how those providers are covered contractually. Teams evaluating Rovo should confirm which LLMs may be used in their environment and ensure those providers align with their internal security and compliance requirements.

3. Data Is Transmitted Securely and Minimally

When Rovo sends data to third-party LLM providers:

• Each request is sent individually
• Traffic is encrypted using SSL
• Providers do not retain inputs or outputs
• Providers do not use the data to improve their services

For organizations using Atlassian-hosted LLMs only, data does not leave Atlassian-controlled infrastructure for AI processing.

What Atlassian does collect:

• Metadata about feature usage
• Interaction patterns (for example, which features are used)
• Feedback users choose to provide

This information supports product operation and improvement, not AI training.

4. You Control What Rovo Can Index

Rovo works by indexing content from connected tools. By default, it indexes the entire workspace of a connected third-party app, such as:

• Google Drive
• SharePoint
• Confluence spaces
• Jira projects

Admins can limit this behavior:

• Certain connectors support blocklists
• Blocklists restrict which folders, libraries, or areas Rovo can index

Rovo does not invent missing data. If content is blocked or unavailable, it simply does not appear in results.

Operational risk to note:
If you connect a large workspace without scoping or blocklists, you may index more data than intended. Connector setup deserves the same review as any other data integration.

5. Rovo Respects Existing Permissions

Rovo inherits permissions from Atlassian products and connected third-party apps

Users only see content they already have access to. Two users can ask the same question and receive different answers because their permissions differ.

Examples:

• A user must authorize Google Drive access before seeing Drive content
• Private documents remain private
• Permission changes are monitored and reflected in the Rovo index

When content is deleted:

• Rovo updates its index
• Deleted content no longer appears in results

There are edge cases:

• Smart Links may still appear, but break when clicked
• GitHub data deletion depends on both disconnecting Rovo and uninstalling the GitHub for Jira app

6. Auditability and Admin Visibility

Rovo activity is logged in Atlassian’s organization audit logs.

Logged events include:

• Chat sessions started
• Agents created, updated, or deleted
• Connectors created or removed
• Bookmarks and definitions changed

Admins can:

• Filter by product (“Atlassian Rovo”)
• Export logs using Atlassian audit tooling

This supports internal audits, incident response, and compliance reviews.

7. Data Residency and Compliance Status

Rovo supports data residency. When enabled:

• In-scope Rovo data stays in your pinned region
• Residency aligns with Jira and Confluence settings

Residency support was rolled out gradually through 2025 and is now generally available in supported regions, making it a practical control for organizations with data locality requirements.

From a compliance standpoint, Rovo adheres to established international security standards, including SOC 2 and ISO 27001. As with all Atlassian products, data processed or transmitted for Atlassian Intelligence and Rovo is handled in accordance with Atlassian’s Privacy Policy, Data Processing Addendum, and GDPR commitments. These frameworks define how customer data is protected, processed, and governed across Atlassian services, providing a consistent baseline for security and privacy controls.

8. Browser Extension and Web Content Handling

The Rovo browser extension extends Rovo Chat and agents beyond Atlassian products into the browser itself. When users are allowed to install the extension, they can interact with Rovo on public web pages, such as documentation sites or knowledge bases, as well as on pages connected through approved Rovo connectors. For example, if an organization connects SharePoint to Rovo, a user viewing a Word document in their browser can ask Rovo to summarize or explain that content directly from the page. 

When the Use current tab as context setting is enabled, the browser extension can read the contents of the active tab to fulfill a specific user request. In practice, this means:

• The page content is accessed only to answer the user’s request, such as summarizing a page or extracting key points
• The content is processed temporarily for that interaction
• The data is not stored by Atlassian after the response is generated
• The information is used only to fulfill the request and is then discarded

The extension also has limited access to private Google Docs for a very specific purpose: enabling in‑browser definitions. In this case, the document content is read only to detect terms that can be defined. That content is sent to Atlassian solely for this detection step, is not stored, and is not shared with or sent to third‑party LLM providers.

From a security perspective, this design minimizes data persistence and reduces long‑term exposure. However, it still requires user awareness. When users choose to share the current tab as context, they are explicitly allowing Rovo to read that page for the duration of the request. Organizations should account for this behavior in user training and browser extension policies to ensure it aligns with internal data handling standards.

What Organizations Should Understand Before Enabling Rovo

Rovo’s value comes from its reach. It spans Atlassian products and can extend into third‑party systems, giving teams a single way to search, interact with knowledge, and automate work. That same reach means organizations need to approach adoption deliberately.

Atlassian has put clear boundaries in place around data use. Customer data is not used to train AI models, whether those models are Atlassian‑hosted or provided by third parties. Data is transmitted securely, retained only for limited operational purposes, and governed by existing permissions. These controls address many of the core risks that slow AI adoption in the enterprise.

At the same time, Rovo is not a “set it and forget it” feature. Administrators still play a critical role. Decisions around which systems to connect, how much data to index, whether to use blocklists, and which regions to enable for data residency directly affect an organization’s risk posture. Connector configuration and permission hygiene matter just as much as the AI itself.

The takeaway is straightforward. Rovo can be a powerful and secure addition to the Atlassian platform when it is implemented with intention. Organizations that take the time to understand data flows, enforce permissions, and align AI usage with internal policies are far more likely to see real value, without introducing unnecessary risk.

Adopting AI is not about turning on every feature. It is about making informed choices, setting clear boundaries, and ensuring the technology works within the controls you already trust.

The Role of Atlas Bench

As an Atlassian Platinum Solution Partner with deep Cloud specialization, Atlas Bench helps organizations adopt Atlassian AI in a way that is secure, intentional, and aligned with business objectives. Our work goes beyond simply enabling features. We focus on how AI fits into existing workflows, permission structures, and compliance requirements so it can be used with confidence.

We support teams as they move from Data Center to Atlassian Cloud, ensuring privacy controls, data residency settings, and access permissions are configured correctly from the start. This includes helping organizations understand how data flows through Atlassian AI and Rovo, where it is stored, and how it is protected.

Atlas Bench also works with teams to identify practical, high‑value use cases for Rovo, including automation and purpose‑built agents. The focus is on applying AI where it delivers measurable benefit, without expanding access to sensitive data or introducing unnecessary operational risk.