Atlassian Rovo brings AI-powered search, assistance and agents into Jira and Confluence, where many organisations manage delivery, document procedures and co-ordinate operational work. For regulated organisations, adopting it means deciding which information AI can use, which actions it can take and what evidence is needed to trust the results.
Rovo respects configured access permissions. But those permissions may be outdated or too broad and accessible information may be inaccurate or superseded. An agent’s ability to act also needs a clear boundary. What a user can do is not necessarily what an AI agent should be authorised to do on their behalf.
For CTOs, Heads of Platform & Tools and CISOs, the starting point is the estate itself. Are its information, permissions and workflows governed well enough to support the intended use of AI?
What is Atlassian Rovo?
Atlassian Rovo helps teams find information, ask questions about their work and carry out tasks across Atlassian products and connected applications. Its core capabilities include:
- Rovo Search. Find information across supported Atlassian products and connected sources.
- Rovo Chat. Ask questions in natural language and receive AI-generated answers using accessible information.
- Rovo agents. Use agents configured for specific tasks, including actions within applications and workflows where tools and permissions allow.
Rovo is available through eligible paid Atlassian Cloud subscriptions, including Jira and Confluence. Features, usage allowances and administrative controls vary by plan.
For organisations using Jira or Confluence Data Center, this matters. Connectors can make supported Data Center content available to Rovo in Cloud. They do not provide the full Rovo AI feature set within the Data Center environment.
Confluence AI and Jira automation. What changes with Rovo?
Finding information, executing a rule and interpreting a request require different controls. The distinction matters when deciding how Rovo should support operational work.
| Capability | How it works | Example | Main governance consideration |
|---|---|---|---|
| Rovo Search and Chat | Search finds accessible information; Chat can use it to generate answers and summaries. | Find and summarise an incident escalation procedure. | Are access permissions appropriate and is the source current and authoritative? |
| Conventional Jira automation | Executes configured triggers, conditions and actions. | Assign an issue when its priority changes. | Is the rule correctly configured, tested and maintained? |
| Rovo agents | Interpret instructions and use available tools within configured permissions. | Review an issue and create a follow-up task based on its context. | Which actions are permitted and how are approval and oversight enforced? |
A conventional Jira automation rule can be misconfigured, but its behaviour follows explicitly configured logic. A Rovo agent introduces interpretation. The same instruction may lead to different responses or actions depending on the context.
That flexibility can help with tasks that do not fit a simple rule. It also means organisations must test how agents handle ambiguity and enforce limits through permissions, tool access and workflow controls. Written instructions alone should not be treated as an authorisation boundary.
A practical Jira and Confluence example
Consider an organisation using Jira to manage operational incidents and Confluence to document response procedures.
An employee could use Rovo Chat to summarise an escalation procedure found in Confluence. But if two accessible pages give conflicting instructions, a fluent answer is not enough. The employee needs to identify the approved procedure and verify that it applies to the incident.
An agent configured to create follow-up Jira tasks introduces a further decision – when can it act and when must someone review its proposal? Preparing proposed task details for someone to review has different consequences from creating or changing a live Jira record or triggering another workflow. Permissions, tool access and approval controls should reflect those consequences.
This illustrative scenario also provides a practical test of value. Can employees find the correct procedure faster and can the agent produce useful follow-up tasks with fewer manual corrections? Actual capabilities depend on configuration, available tools and permissions.
For Catapult CX, these questions connect directly to the permissions, workflows and governance addressed through its Atlassian services. As explored in our guide to why organisations use an Atlassian Solution Partner, business-critical use of Jira and Confluence requires confidence in how the whole estate operates.
Atlassian Rovo permissions. Inherited access needs scrutiny
Rovo respects configured access permissions in Jira, Confluence and supported connected applications. When an agent acts on a user’s behalf, its access is constrained by that user’s permissions.
Enforcing a permission does not establish that the access is still justified.
A Confluence space may contain years of project documents, operational procedures and commercially sensitive information. As employees change roles and groups accumulate access, permissions can drift beyond current business needs.
Rovo can make that information easier to discover and summarise. Content that was previously overlooked may become readily available to anyone whose existing permissions allow access. An access-governance weakness can therefore become more consequential without any permission being bypassed.
Before enabling broad AI-assisted retrieval, review:
- Ownership. Who is accountable for each Jira project, Confluence space and connected repository?
- Access. Do individual, group and guest permissions reflect current responsibilities?
- Sensitive information. Is it identified and restricted appropriately?
- Obsolete permissions. Have redundant groups and access grants been removed?
- Connected sources. Are equivalent access reviews applied beyond Jira and Confluence?
Atlassian’s Rovo data and privacy guidance explains how permissions are synchronised. Organisations should also test access changes in their deployment, including whether revoked access is reflected as expected.
Confluence AI and knowledge quality. Which sources should Rovo trust?
Confluence often holds the procedures, standards and decisions that employees need to do their work. It also holds superseded policies, unfinished drafts and documents whose owners have left.
When Rovo draws on this material, the challenge is distinguishing approved guidance from everything else. An answer that combines an old approval process with its replacement could sound convincing while directing someone to follow the wrong procedure.
Source references help users check an answer. They do not establish that the cited guidance is current or authoritative.
Before relying on Rovo for operational questions, organisations should establish:
- Which content is approved for the intended use.
- Who owns it and when it must be reviewed.
- How superseded material is archived or clearly distinguished.
- How conflicting sources are resolved and uncertainty is escalated.
These are core knowledge-management disciplines, explored in our guide to Confluence knowledge management at enterprise scale. They also provide a basis for testing Rovo. Compare its answers with approved guidance and check how it responds when sources conflict or no reliable answer is available.
Making documentation easier to search only delivers value if employees can trust what they find.
Atlassian Rovo data residency, connectors and AI processing
Data residency does not establish where AI processing takes place.
Atlassian offers data residency for in-scope Rovo data. Selecting a region does not establish that all AI processing takes place there.
By default, Rovo can use both Atlassian-hosted and third-party-hosted large language models. Atlassian states that third-party LLM providers do not retain Rovo inputs and outputs or use them to train their models. Organisations must still account for those providers’ involvement when assessing where and how information is processed.
Atlassian separately retains Rovo Chat and agent inputs and outputs for 30 days, for safety and security purposes, as documented in its Rovo data, privacy and usage guidelines.
Assess these arrangements against the information involved and the organisation’s processing, retention and records requirements. The 30-day period applies to the specified inputs and outputs; it should not be treated as a retention policy covering indexed content, audit records, backups or other Atlassian data.
Atlassian-hosted LLMs for Enterprise customers
Eligible Cloud Enterprise customers can request an Atlassian-hosted LLM configuration. With this enabled, prompts and context used for LLM processing remain within Atlassian’s Cloud boundary rather than being sent to external LLM providers.
According to Atlassian’s guidance, this option:
- Requires a request through the Atlassian account team or Support.
- Applies across the organisation, rather than to an individual site.
- Is not available on Atlassian Government Cloud.
- Uses higher Rovo credit rates for billable actions.
- May change feature availability, performance and response quality.
Atlassian-hosted does not mean processing is confined to the selected data-residency region. The models run on Atlassian-managed infrastructure across multiple global regions.
For organisations that need to exclude external LLM providers, this option may address a specific requirement. It still requires assessment of processing locations, feature coverage and suitability for the intended use. Existing agents and workflows should also be retested after a change in model configuration.
Connectors extend the information Rovo can use
Connecting an external application can bring a broad set of documents into Rovo’s index. Some connectors support restrictions on indexing scope, but organisations should verify the controls available for each source.
Before approving a connector, establish:
- Which content will be indexed and stored by Atlassian.
- How source permissions are applied and updated.
- Whether sensitive content can be excluded.
- What happens to indexed content when the connector is disconnected.
Where the available controls do not meet the organisation’s requirements, exclude the repository or narrow the proposed use until the gaps are resolved.
The architecture also matters. Rovo is an Atlassian Cloud capability; connecting an internally hosted repository does not keep AI processing within that repository’s environment.
Our guide to private AI deployment in regulated environments explains the different boundaries and operating requirements of hosted, private and air-gapped approaches.
Third-party risk and operational resilience
Assess Rovo as part of the organisation’s wider supplier dependencies, including Atlassian, connected applications and any external AI processing. Consider what would happen if the service became unavailable or produced an incorrect result. Which activities would be affected and could teams continue using approved procedures?
UK financial services provides a specific regulatory example. The FCA’s outsourcing and operational resilience guidance distinguishes outsourcing from other third-party arrangements. Firms remain responsible for managing the operational risks relevant to their use of the service.
Where Rovo supports an important business service, assess the dependency and potential disruption against applicable obligations. Relevant references include the FCA’s PS21/3 operational resilience policy and, for PRA-regulated firms, applicable supervisory expectations such as SS1/21.
Using Rovo does not automatically constitute material outsourcing. Classification depends on the arrangement, its purpose and the firm’s regulatory circumstances.
Atlassian Rovo agents. Define authority before enabling action
Rovo agents can create or modify records where their tools and permissions allow. Before introducing them into operational workflows, organisations need to decide who can build them, what they may do and who is accountable for the results.
Atlassian’s agent governance documentation states that agent creation in Rovo Studio is open to users by default. Administrators can restrict creation, while separate settings govern agent visibility and access. Review these controls before adoption spreads.
Each production agent should have clear answers to four questions:
- Who owns it? Name an owner responsible for its purpose, configuration, changes and continued suitability.
- What may it do? Define permitted information sources and actions. Enforce boundaries through permissions, tool access and workflow controls; written instructions alone are insufficient.
- Which actions require approval? Specify who must approve consequential actions and how the workflow prevents execution before approval.
- How will it be tested and monitored? Evaluate ambiguous requests, conflicting sources, misleading instructions embedded in retrieved content and attempted actions beyond its remit. Establish what evidence is available to investigate errors and how the agent can be suspended.
An agent’s production remit should reflect the consequences of an incorrect action and the controls the organisation can demonstrate, rather than the full range of tasks the agent is capable of performing.
Atlassian Rovo rollout. What regulated organisations should review first
A rollout decision should relate to a defined use case – the information Rovo will access, the people who will use it and the actions it may perform. Use the following checklist to identify the evidence needed before proceeding.
| Area | Question to answer | Evidence to review |
|---|---|---|
| Ownership | Who approves the use case and remains accountable? | Named owners, responsibilities and decision authority. |
| Permissions | Does access reflect current business needs? | Access reviews, remediation records and permission tests. |
| Knowledge quality | Can Rovo retrieve current, approved guidance? | Content owners, review dates and tests against approved answers. |
| Data processing | Do storage, processing locations, retention and supplier arrangements meet requirements? | Data-flow mapping, configuration records and supplier assessments. |
| Connectors | Which repositories and content may be indexed? | Approved connector inventory, indexing scope and verified restrictions. |
| Agent governance | Which agents and actions are authorised? | Agent register, tool permissions and enforced approval controls. |
| Operational assurance | Can errors be detected, investigated and contained? | Test results, available logs, escalation procedures and suspension arrangements. |
| Value and cost | Does the benefit justify consumption and operating effort? | Baseline measures, pilot results, usage monitoring, budgets and spending controls. |
Where personal data is involved, assess whether a data protection impact assessment is required. The ICO’s AI governance guidance provides a reference for assessing risks, assigning responsibilities and evaluating safeguards.
Record the decision. What is approved, under which conditions, who accepts any remaining risks and when the use case will be reviewed. Where evidence is missing, resolve the gap or narrow the deployment before proceeding.
Rovo licensing and usage costs
Rovo uses credits to measure certain activities, with included allowances determined by the organisation’s subscriptions and plans. Atlassian’s Rovo credit guidance states that additional usage billing takes effect on 3 December 2026.
Before expanding adoption, assign responsibility for monitoring consumption, setting spending controls and assessing whether the time saved and improvements in work justify the cost. Check Atlassian’s licensing information for current terms.
How to introduce Atlassian Rovo with proportionate controls
1. Define a limited use case and its success criteria
Choose a workflow with a clear benefit and manageable consequences if an answer or action is wrong. Finding approved internal guidance can provide a starting point before introducing agents that modify operational records.
Record current performance so you can assess improvement. Time spent finding the correct information, answer accuracy and the manual corrections required.
2. Prepare the information and access
Identify the sources the use case needs, confirm their owners and resolve outdated or conflicting guidance. Review permissions and exclude content that should not be available.
Keep the initial scope small enough to test thoroughly. Widen it as the evidence supports doing so.
3. Configure and verify the controls
Confirm the processing arrangements, connector scope, agent tools, approval requirements and spending controls available on the organisation’s subscription.
Test that restrictions work in practice. Where an action requires approval, verify that the workflow prevents execution until approval is given.
4. Test failure cases as well as useful outcomes
Use representative questions and tasks with approved reference answers or clearly defined acceptance criteria. Include missing information, superseded procedures, conflicting sources and misleading instructions embedded in retrieved content.
Check access restrictions and attempted actions beyond the agent’s remit. Assess whether errors can be detected and investigated using the evidence available.
5. Review results before expanding
Compare the pilot with the baseline, including time saved, accuracy, correction effort and running costs. Agree who maintains the sources, permissions and agent configuration and who can suspend use if problems emerge.
Expand only when the results meet agreed acceptance criteria. Repeat relevant tests when sources, permissions, tools or model configurations change.
Assess your Atlassian estate before introducing Rovo
Start with one use case. Establish which information Rovo needs, who may use it, what it may change and how you will judge whether it improves the work.
Our Atlassian Healthcheck reviews the permissions, workflows, applications, reporting and governance that support a dependable estate. Our Atlassian Consulting Services help organisations address weaknesses and configure the platform around operational needs.
Talk to us about preparing your Atlassian estate for Rovo, so adoption can proceed with clear boundaries, accountable owners and evidence of value.
Frequently asked questions
Does Atlassian Rovo respect Jira and Confluence permissions?
Yes. Rovo respects configured permissions in Atlassian and supported connected applications. Organisations still need to check that access reflects current roles and business needs.
Does Rovo use company data to train AI models?
Atlassian states that third-party LLM providers do not use Rovo inputs and outputs to train or improve their models. Those providers may still process requests under the default configuration. Atlassian separately documents retaining Chat and agent inputs and outputs for 30 days for safety and security purposes.
Can Atlassian Rovo be used in regulated environments?
Yes, where the intended use and deployment arrangements meet the organisation’s requirements. Suitability depends on the data involved, configuration, contractual terms and applicable obligations. Vendor certifications support that assessment but do not establish suitability for every use case.
Is Rovo the same as Jira automation?
No. Conventional Jira automation follows configured triggers, conditions and actions. Rovo includes search, AI-generated responses and agents that can interpret requests and use available tools. Agents can also operate within automation workflows, so controls must cover how these capabilities work together.
