Product and intended use
Define the configuration, people, information and tasks being assessed.
What Rovo covers and which parts are always on
Public claim only
The vendor FAQ (read 2026-09-27) states Rovo is available to customers on a Standard, Premium or Enterprise Cloud plan of Jira, Confluence, Service Collection or Teamwork Collection, and that 'AI is automatically activated for all apps on Standard, Premium, and Enterprise plans, including Rovo'. The trust page adds that Rovo Apps 'are a core part of the Atlassian Cloud Platform ... These Platform apps are not removable' and that 'non-AI powered Rovo features, such as Rovo Search, cannot be disabled', while an organisation admin can deactivate the AI-powered parts. Rovo Dev, Rovo Studio, the Chrome extension, CLI, MCP, mobile and desktop apps are separate surfaces.
Ask: On our plan, exactly which Rovo apps and surfaces are switched on, which cannot be turned off, and who holds the organisation-admin control?
Cloud only; Data Center reaches it by synchronising to cloud
Public claim only
The vendor FAQ states 'To fully leverage all of the AI features of Rovo, including Search, Chat, Agents, and Studio, an Atlassian Cloud Standard, Premium, or Enterprise plan is required', and that 'Rovo Data Center connectors for Jira, Confluence, and Jira Service Management enable seamless data synchronization between Data Center and cloud environments'. So a Data Center customer reaches the AI features by sending content to Atlassian Cloud rather than by running them on its own infrastructure.
Ask: If any of our Atlassian products is on Data Center, what content would the Rovo connector copy into Atlassian Cloud, and in which region would it then sit?
Named components and AI dependency
Public claim only
From the vendor's own pages (read 2026-09-27): Rovo Search across Atlassian and named third-party tools; Rovo Chat grounded in the customer's data; Rovo Agents that search and act across connected apps; Rovo Studio, a no-code agent builder; and Rovo Dev for IDEs and the command line, with context drawn from the Teamwork Graph. The vendor's llms.txt also lists AI in Jira (natural language to JQL, summaries, backlog and sprint assistance), Confluence (page summarisation, writing assistance, content generation, question answering over the knowledge base) and Jira Service Management (virtual service agents, intelligent ticket routing, AI-generated knowledge articles). The FAQ states that if AI is deactivated 'Rovo's core apps like Search and Studio will still work, but AI-powered apps including Rovo Chat and Agents will be unavailable'.
Ask: Which of these features would our teams actually have, and which stop working if the organisation admin deactivates AI?
Australian residency for stored app data; inference is a separate question
Public claim only
The vendor's data residency page (read 2026-09-27) states 'You can choose to pin your data to our US, EU, Australia, Germany, Singapore, Canada, UK, Japan, India, South Korea or Switzerland locations' and that residency is available on Enterprise, Standard and Premium cloud plans. The trust page states 'Yes, data residency support is available for Rovo. With data residency for Rovo turned on, all of your in-scope app data will remain stored in the region you've selected.' Separately it states 'By default, when using Rovo, data is transferred outside of the current site to third party LLM providers (e.g., OpenAI) in order to generate a response', and that for organisations using Atlassian-hosted LLMs no data goes to third-party hosted LLMs. Residency therefore governs stored in-scope app data, not by default where inference happens.
Ask: With residency pinned to Australia, in which countries is a Rovo prompt actually processed, and can inference be confined to Australia?
What the vendor says Rovo is for
Public claim only
The vendor's own llms.txt describes Rovo as 'AI-powered knowledge discovery, search, and virtual agent platform. Searches across Atlassian and third-party tools to find information, answer questions, and automate tasks using AI agents. The foundation of Atlassian's AI agent ecosystem.' Section 6.2 of the Customer Agreement places on the customer the responsibility for 'determining whether the Products meet Customer's requirements and any regulatory obligations related to its intended use', and Section 6.3 prohibits uploading protected health information without a Business Associate Agreement.
Ask: Does Atlassian place any restriction on using Rovo output in regulated professional advice, and what does it expect the customer to assess first?
Check for vendor content directing how AI describes the product
Public claim only
Checked deliberately on 2026-09-27. Atlassian publishes https://www.atlassian.com/llms.txt (HTTP 200, 26,607 bytes): a structured file of product descriptions and links addressed to large language models, with sections including Products, AI, Agents and Automation, Pricing, Deployment Options, and Security, Compliance and Trust. Its Rovo entry reads 'Rovo: AI-powered knowledge discovery, search, and virtual agent platform. Searches across Atlassian and third-party tools to find information, answer questions, and automate tasks using AI agents. The foundation of Atlassian's AI agent ecosystem.' Searching the file for directive language returned no block telling AI models how to characterise the company or its products, so this is a machine-readable product description rather than content directing how to describe it. A second file, llms-full.txt, also returns HTTP 200 and was not retrieved. /ai-info and /for-ai return 404; robots.txt returns 200 with User-agent groups for '*' and 'atlassian-bot' only, so no AI-crawler allow or disallow directives.
Ask: Does Atlassian maintain any guidance, in llms-full.txt or elsewhere, telling AI assistants how to describe Rovo?
Data, controls and requirements
Compare the actual configuration with firm, client and jurisdiction requirements, supported by evidence.
Default transfer of content to third-party LLM providers
Public claim only
The vendor trust page states 'By default, when using Rovo, data is transferred outside of the current site to third party LLM providers (e.g., OpenAI) in order to generate a response', and that Rovo 'may also process organizational data from within your site that the user has permission to view and include that data with the user inputs'. The published sub-processor list shows the generative AI providers and their processing locations: AWS Bedrock (many countries including Australia), Google Vertex AI (USA, EEA, Singapore, Taiwan) and OpenAI, L.L.C. (USA). Whether any client material is disclosed therefore depends on what sits in the firm's Jira, Confluence and connected apps.
Ask: What client or matter material is stored in our Atlassian sites and connected apps today, and do we hold authority for it to be sent to OpenAI, Google or AWS for processing?
Providers named by the vendor versus the published list
Not confirmed
The vendor trust page (read 2026-09-27) states 'We use a diverse range of open models, including models from the Gemma series, GPT-oss series, LLama series and Nemotron series, alongside third-party hosted LLMs from OpenAI's GPT series of models, Anthropic's Claude series of models, and Google's Gemini series of models', with dynamic routing selecting the mix. The published sub-processor list, however, names as generative AI services providers only Amazon Web Services, Inc. (AWS Bedrock), Google Vertex AI and OpenAI, L.L.C.; Anthropic does not appear anywhere on that list. The two sources differ on whether Anthropic is a sub-processor in its own right; the pages read do not reconcile them, and no inference is drawn here.
Ask: Is Anthropic a sub-processor in its own right, or are Claude models reached only through AWS Bedrock or Google Vertex AI, and why is Anthropic absent from the published sub-processor list?
Published sub-processor list with locations and notice period
Public claim only
The Atlassian sub-processor list (read 2026-09-27) names, for Rovo: Amazon Web Services, Inc. as cloud hosting provider with processing locations including Australia; Amazon Web Services, Inc. (AWS Bedrock) as 'Generative AI services provider for intelligence product features' for 'All Atlassian Cloud Products with enabled Atlassian Intelligence or Rovo', locations including Australia; Google Vertex AI in the same role, locations USA, EEA, Singapore and Taiwan; OpenAI, L.L.C. in the same role, location USA; Databricks, Inc. as 'Infrastructure provider for machine learning development, processing and training', location USA; Clumio, Inc. for backup; Cloudflare, Ltd. as content delivery network and host of the Remote MCP Server, processing 'globally at the data center closest to the end user'; and e-Core and Telus for customer support. Atlassian Group companies listed include Atlassian Pty. Ltd. (Commonwealth of Australia).
Ask: Does Databricks process any of our Rovo content, and what exactly does Cloudflare see when the Remote MCP Server is used?
No provider training; vendor fine-tuning on metadata is setting-dependent
Public claim only
The vendor trust page states 'The data you submit and the responses you receive from Rovo are not shared with third-party-hosted LLM providers for them to use to train or improve their services', that partners including OpenAI, Anthropic and Google 'operate under strict zero data retention (ZDR) agreements', and separately that 'Atlassian may use metadata to fine-tune open-source models that operate strictly within Atlassian's infrastructure, solely to improve the quality of responses and experiences we deliver to customers. This use of contributed data is subject to data contribution settings, and we apply robust safeguards, including de-identifying and aggregating all contributed metadata before use.' What counts as metadata, and whether the data contribution setting is on or off by default, was not established: the linked data-contribution FAQ was not read within the credit cap.
Ask: What does 'metadata' include for Rovo fine-tuning, is the data contribution setting on by default for our organisation, and how do we turn it off?
No feedback-use statement found
Not confirmed
Nothing was found on the pages read about in-product feedback on Rovo output - thumbs up or down, ratings, or reported answers - or about whether such feedback, and the prompt and output attached to it, is retained or used to improve the service. The trust page addresses training and retention by LLM providers and Atlassian's metadata fine-tuning, but not user feedback as a separate channel.
Ask: When a user rates or reports a Rovo answer, what is captured, where is it stored, who can read it and how is it used?
Provider zero retention; in-tenant retention not published
Public claim only
The vendor trust page answers 'Do any of the LLM providers store customer data?' with 'No, none of our LLM providers store the data you submit or the responses you receive', and states that third-party hosted partners operate under zero data retention agreements, with each request 'sent to the external provider individually over an SSL-encrypted service to process and send back to Atlassian'. Nothing on the pages read states how long Rovo chats, agent runs, search indexes or Teamwork Graph enrichment are retained inside Atlassian Cloud.
Ask: How long are Rovo chat histories, agent run logs and the search index retained in our Atlassian site, and can we set that period?
Deletion deferred to the Documentation
Public claim only
Section 12.4 of the Atlassian Customer Agreement provides that on expiration or termination the customer's rights cease, it must stop accessing the Cloud Products and delete or return license and access keys, and that 'Following expiration or termination, unless prohibited by Law, Atlassian will delete Customer Data in accordance with the Documentation'. The agreement itself sets no period, and the Documentation that does was not read within the credit cap. Section 4.5 separately lets Atlassian limit access to or remove Customer Data where it may violate law or the Acceptable Use Policy, or where use threatens the security or operation of the Cloud Products.
Ask: Which document sets the post-termination deletion period for Rovo data, what is that period, and does it cover backups and the search index?
Access limited to instruction; support entities named
Public claim only
Section 4.2 of the Customer Agreement commits Atlassian to maintain an information security program with 'appropriate physical, technical and organizational measures designed to protect Customer Data ... from unauthorized access, destruction, use, modification or disclosure', and Section 16 makes Customer Data the customer's Confidential Information, disclosable to employees, agents and contractors with a legitimate need to know under equivalent confidentiality obligations. The published sub-processor list identifies the entities that may see Customer Data when providing support, including e-Core (Brazil, Mexico) and Telus (Romania) 'if shared with Atlassian via attachments in support tickets', and Atlassian Group companies including Atlassian Pty. Ltd. in Australia.
Ask: Which Atlassian personnel or support partners can read Rovo prompts and outputs without our approval, and is that access logged and reportable to us?
Existing permissions are enforced, including through connectors
Public claim only
The vendor trust page states 'Rovo honors all existing permissions within each feature. Users will not be able to create or generate content based on resources they do not have access to', gives examples for Jira and Confluence, and says two users may receive different results. It extends the policy to third-party connectors: 'All permissions set in our platform and your third-party connector source will be respected as long as they are set accordingly.' For agents it states they 'can only access and act on information that you, as the user, already have permission to see or modify', and that when automation rules call agents the agent's access follows the permissions of the connecting user named in the Rovo node.
Ask: Have our Jira, Confluence and connector permissions been re-reviewed since Rovo Search was enabled, and which connecting user is named in any automation rule that calls an agent?
Transport encryption to providers; no key control published
Public claim only
The vendor trust page states that for Rovo 'each data request is sent to our LLM providers individually, over an SSL-encrypted service, to process and send back to Atlassian', and that features follow the existing Atlassian security practices for each app. Section 4.2 of the Customer Agreement commits Atlassian to appropriate technical measures described in its Security Measures. No statement about encryption at rest for Rovo data specifically, and no customer-managed encryption key option, was found on the pages read.
Ask: Is Rovo data encrypted at rest with a key we can manage or revoke, and where are those key controls documented?
SOC 2 and ISO 27001 for Rovo; HIPAA boundaries
Public claim only
The vendor trust page states 'Rovo has completed the external assessment and compliance certifications for SOC 2 and ISO 27001' and that 'Moving forward, Atlassian's AI capabilities will be included as part of Atlassian's annual compliance audit'. It also states Rovo can be used in a HIPAA-compliant manner within boundaries: Rovo Chat, Rovo Agents and Rovo Search are supported in HIPAA-enabled environments of Jira, Jira Service Management, Confluence and Jira Product Discovery, while the Rovo Chrome Extension, CLI, MCP, mobile app and desktop app are 'currently out of scope and must not be used with Protected Health Information (PHI)'. Certificate numbers and audit scope are not published on the pages read.
Ask: Provide the SOC 2 report and ISO 27001 certificate showing Rovo and the Australian realm inside the audited scope, and the equivalent boundary list for confidential legal material.
Agreement documents and the entity question
Public claim only
The vendor trust page states 'Yes, the Atlassian Customer Agreement covers Rovo', together with the Privacy Policy, Acceptable Use Policy, Data Processing Addendum and Product-Specific Terms. The agreement itself (effective 1 October 2026, read 2026-09-27) adds at Section 4.6 that Cloud Products 'may be, or include access to, AI Offerings. Atlassian provides AI Offerings under the AI Terms', and at Section 4.7 that Usage-Based Offerings are provided under separate Usage-Based Offering Terms; neither the AI Terms nor those terms were read. 'Atlassian' is defined as the entity that owns or operates the Products used, listed on a product-terms page that was not read, so the Australian contracting entity is not established. Section 20.4(a) applies California law and San Francisco venue to customers domiciled outside Europe, the Middle East and Africa.
Ask: Which Atlassian legal entity would we contract with, what is its ABN or ACN, and what do the separate AI Terms and Usage-Based Offering Terms add for Rovo?
Cross-border processing on the published list
Public claim only
The sub-processor list gives processing locations per sub-processor: AWS hosting spans the EEA (Sweden, Ireland, Germany), Switzerland, UK, Canada, Australia, Singapore, South Korea, USA, India and Japan, noting that with data residency enabled certain in-scope data is hosted in the chosen region; AWS Bedrock for generative AI spans eighteen named countries including Australia; Google Vertex AI is USA, EEA (Belgium, Netherlands, Finland), Singapore and Taiwan; OpenAI, L.L.C. is USA. Cloudflare processes 'globally at the data center closest to the end user'. The trust page confirms that by default data leaves the site for third-party LLM providers.
Ask: For our site with residency in Australia, which of these providers would a Rovo request actually reach, and can we exclude the USA-only providers by electing Atlassian-hosted models?
No incident-notification clause in the agreement read
Not confirmed
The Atlassian Customer Agreement read on 2026-09-27 contains a security-program obligation (Section 4.2) and a liability regime for 'Special Claims', defined in Section 14.4 as 'any unauthorized disclosure of Customer Data or Customer Materials caused by a breach by Atlassian of its obligations in Section 4.2', capped at the lesser of twice the fees paid in the preceding twelve months and US$5,000,000. It contains no breach-notification obligation or timeframe; Section 2.3 states the Data Processing Addendum forms part of the agreement, and that addendum was not read within the credit cap.
Ask: Where in the Atlassian DPA is the security-incident notification obligation, what triggers it and within how many hours would we be told of an incident affecting Rovo?
Thirty days' notice of terms changes; effective at renewal for paid plans
Public claim only
Section 20.9 of the Customer Agreement provides that Atlassian may modify the agreement, including the Policies, Product-Specific Terms and DPA, by posting the modified portions, using 'commercially reasonable efforts to post any such modification at least thirty (30) days prior to its effective date', and that for paid subscriptions modifications take effect at the next Order or renewal unless a party elects not to renew. Section 11.1(b) warrants that Atlassian will not materially decrease the functionality or overall security of the Products during a Subscription Term. Separately, the vendor states that the documented Rovo credit pricing applies to usage from 31 August 2026.
Ask: How will we be notified when the AI Terms, the sub-processor list or the Rovo credit rates change, and will a mid-term change to credit consumption count as a decrease in functionality?
Data retrieval described in the Documentation
Public claim only
Section 4.4 of the Customer Agreement states only that 'The Documentation describes how Customer may retrieve its Customer Data from the Cloud Products'; the Documentation was not read. Section 12.2 lets the customer terminate for convenience at any time with no refund except under the thirty-day return policy in Section 10.3, and Section 12.3 gives refunds of pre-paid unused fees only where the customer terminates for cause. Nothing read commits Atlassian to export Rovo-specific artefacts such as agent definitions, Studio configurations or chat histories.
Ask: On exit, can we export Rovo agent and Studio configurations and chat histories, in what format, and is anything Rovo-specific lost?
Third-party connectors and indexing limits
Public claim only
The trust page states admin-managed connectors are not enabled by default and must be connected by an organisation admin, that they respect existing user permissions, and that Smart Link connectors need no admin setup and surface results based on an individual user's permissions and history. It advises reviewing the types of data stored in a third-party app before connecting. An allowlist or blocklist can limit the content Rovo indexes from Google Drive or Microsoft SharePoint. Section 7.2 of the Customer Agreement puts use of Third-Party Products under the relevant provider's terms rather than the Atlassian agreement, while data sent from them into the Atlassian account is subject to the agreement.
Ask: Which third-party apps would be connected, who approved each one, and is an allowlist in place for Drive and SharePoint indexing?
No public web search published for Rovo
Not confirmed
Nothing on the pages read states that Rovo searches the public internet or grounds answers in web content. What is published is search across Atlassian products and named third-party connectors, with context from the Teamwork Graph. The absence of any statement either way means the question remains open rather than answered in the negative.
Ask: Can Rovo Chat or a Rovo Agent retrieve content from the public internet, and if so can that be disabled organisation-wide?
Agents act within the user's permissions
Public claim only
The vendor describes Rovo Agents as configurable agents that 'search and take action' across Atlassian and connected apps, and states on the trust page that 'your existing access controls govern all actions available to agents', that agents 'can only access and act on information that you, as the user, already have permission to see or modify', and that 'when automation rules call agents, the agent's access to knowledge is determined by the permissions of the connecting user specified in the Rovo node'. Rovo Studio is a no-code builder for creating and publishing agents. No published list of the write actions an agent may perform, and no approval-before-action control, was found on the pages read.
Ask: Which write actions can a published Rovo agent take in Jira, Confluence or a connected app without human approval, and which connecting user's permissions does each automation rule run under?
Review is left to the user, and the vendor says so
Not confirmed
The vendor trust page tells users to 'review the quality of the responses you receive before sharing them with others' and to think about the situations in which the features are used, 'for example, not in cases where you need current and accurate information about people, places, and facts'. No human-review or approval step is described inside the product, and Section 6.2 of the Customer Agreement places responsibility for determining fitness and regulatory obligations on the customer.
Ask: Who inside the firm checks Rovo output before it is relied on or sent externally, and how is that check recorded?
