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.
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:
In simple terms:
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.
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.
When Rovo sends data to third-party LLM providers:
For organizations using Atlassian-hosted LLMs only, data does not leave Atlassian-controlled infrastructure for AI processing.
What Atlassian does collect:
This information supports product operation and improvement, not AI training.
Rovo works by indexing content from connected tools. By default, it indexes the entire workspace of a connected third-party app, such as:
Admins can limit this behavior:
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.
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:
When content is deleted:
There are edge cases:
Rovo activity is logged in Atlassian’s organization audit logs.
Logged events include:
Admins can:
This supports internal audits, incident response, and compliance reviews.
Rovo supports data residency. When enabled:
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.
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 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.
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.
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.