Summary

• Atlassian Rovo Model Context Protocol (MCP) Server is now generally available and intended for production use.
• It lets approved external AI tools like ChatGPT and Claude work with Jira, Confluence, Compass, and other Atlassian platforms — without bypassing your existing permission model.
• All requests run as an authenticated user via OAuth 2.1 with PKCE, and all actions are auditable.
• Atlassian states the MCP layer does not store or cache your data.
• Delete operations are not supported via Rovo MCP Server, which limits destructive actions.
• As a 2024–25 Atlassian Partner of the Year AI Innovation finalist (Global), Togetha is watching this closely and helping customers use AI with Atlassian safely.

Keeping control of your Atlassian data

AI assistants are everywhere. Your people are using them, but maybe not in the safest way.

You’ve got users pasting Jira work items into ChatGPT. Someone else testing a browser extension that can “read Confluence”. And another quietly generating an API token to pipe Jira data into an external AI tool for faster reporting.

None of this is happening with central oversight. So executives are asking:

How do we use AI with Atlassian Cloud without weakening security, governance, or auditability?

That is the problem Atlassian’s Rovo Model Context Protocol (MCP) Server is trying to solve.

Atlassian has announced the general availability (GA) of Rovo MCP Server. In this article, we will break down what Rovo MCP Server is, how it works, and what it means for organisations seeking the benefits of AI in Jira and Confluence without introducing unnecessary risk.

What is Atlassian Rovo MCP Server?

Rovo MCP Server is Atlassian’s managed implementation of the Model Context Protocol.

The Model Context Protocol is a standard way for external AI tools like ChatGPT and Claude to talk to your internal systems, e.g. your Atlassian products.

So, the Rovo MCP Server is a way for approved external AI tools to get access to your Atlassian data via a safe, controlled gateway. Instead of each AI assistant or vendor plugging straight into your sites in their own way, they are expected to go through this controlled layer.

For you, that means one standard way of handling authentication, enforcing permissions, and logging activity.

GA status matters here. This is not an experiment in a lab. Atlassian is positioning Rovo MCP Server as part of the core infrastructure that underpins how AI works with their cloud products.

Does the AI tool get access to more data?

No.

A key design choice is that Rovo MCP Server does not give AI assistants or tools any special privileges.

Everything they do is constrained by the permissions of the user who invokes them.

Every action:

• uses Atlassian OAuth 2.1 authentication
• runs on behalf of a user who has signed in
• respects existing Jira and Confluence permissions and scopes.

If a user cannot see a space, they cannot ask a tool to look at it. If a user cannot edit a page, they cannot ask a tool to edit it on their behalf.

In other words, Rovo MCP Server does not introduce a new “super-user” that can see across your whole instance. It just gives approved tools a more standard and governed way to act as the users who are already there.

How is authentication handled?

Rovo MCP Server uses OAuth 2.1 with Proof Key for Code Exchange (PKCE).

This is the modern pattern for protecting browser and native applications, and it reduces the risks around stolen tokens and intercepted authorisation codes.

From your perspective, there are two important points. Authentication and consent are handled by Atlassian’s own authorisation services, and the AI tool provider does not get to bypass that flow.

You keep a single place where access is granted and revoked, and the same identity story applies regardless of which AI assistant or integration you are testing.

Is customer data stored or retained?

According to Atlassian, Rovo MCP Server does not store or cache customer data.

Instead, it acts as a secure broker between external AI tools and your Atlassian Cloud applications in real time.

That means data remains in Atlassian Cloud, existing data residency settings still apply, and the MCP layer is not an extra database you have to assess or track.

This is particularly important for regulated and government customers who already have to map data flows and prove where information lives.

You are not adding a second copy of your Jira or Confluence content inside an AI “data lake”. You are letting approved tools talk to Atlassian Cloud through a managed, stateless layer.

Where can you see Atlassian’s security and compliance detail?

If you are running a risk assessment or doing formal vendor due diligence, the best starting point is Atlassian’s Trust Centre.

You will find information about security architecture and controls, compliance frameworks such as SOC 2 and ISO 27001, and privacy and data protection commitments.

This is the canonical place Atlassian maintains for auditors, security teams, and procurement.

Are actions via Rovo MCP Server auditable?

Yes.

Rovo MCP Server activity is recorded in your organisation audit log. That includes which tool was used, what action it performed, and which user initiated it.

On top of that, Jira and Confluence continue to log their own activity in the usual way.

For you, this means that AI-driven changes are not happening “off the books”. If a tool edits a Jira work item, creates a Confluence page, or updates a Jira field, there is a record of who asked it to do that and when.

Can tools delete data through Rovo MCP Server?

No.

Even if a user has delete permissions, delete operations are not supported by Rovo MCP Server. Interactions are limited to reading, creating, and updating data. This design choice deliberately lowers the blast radius of any mistake.

You are not handing an external AI tool the ability to bulk-delete your Jira work items or wipe out your Confluence spaces. That work still has to happen through the existing interfaces and controls.

Why this matters if you work in a regulated or government environment

If you are in a regulated or government setting, you are probably facing two pressures at once. Leadership wants to “do something with AI”, and your security, governance, or privacy teams need clear answers as to “how”.

Rovo MCP Server does not magically solve every AI risk, but it does give you some tangible guardrails:

• Atlassian permissions and scopes still apply
• data is not cached or stored by the MCP layer
• all activity by external AI tools is auditable
• destructive actions like delete are blocked
• authentication stays centralised in Atlassian’s existing services.

That makes it easier to draw a line between “responsible experimentation” and “uncontrolled access”.

Where Togetha fits in

As a 2024–25 Atlassian Partner of the Year AI Innovation finalist (Global), Togetha is working with customers who want the productivity gains of AI in Jira and Confluence, without undermining their security and governance.

In practice, that means helping you:

• understand what Rovo MCP Server does and does not do
• map AI use cases to your existing permission and risk frameworks
• pilot AI assistants in a way that is auditable and reversible
• align Atlassian’s features with your internal security and governance controls

If you are looking at Rovo MCP Server and wondering “is this safe enough for us?” or “how do we roll this out in stages?”, that is exactly the kind of question we spend our time on.