Restricting sensitive data from surfacing via Rovo MCP Server

[Ben Spillane]

Hi, 

I'm working on a threat and risk assessment for work. The assessment focuses heavily on Rovo and Atlassian AI features, Rovo MCP Server and also 3P MCP connectors as well as marketplace apps.

The question I can't get a definitive answer to is this:

Can we enforce data security policies that map data classification levels to Rovo MCP Server permissions, restricting sensitive data from being surfaced by connected AI clients?

The closest concept is data security policies to restrict access by marketplace and custom apps, of which Rovo MCP Server is neither.

The Problem: Our current DLP (Data Loss Prevention) rules stop users from exporting sensitive content, but a security gap exists where this same data can still flow to third-party clients via the Rovo MCP Server.

The Challenge: Broadly blocking access at the space or app level is not feasible. The target data contains critical business context that varies in sensitivity item-by-item, making blanket restrictions impractical.

Is there any short term plans for features in this area? I've found the Atlassian Cloud roadmap has the line items:

• Connector data security, and
• Rovo chat security

Should I be hopeful these might be the features I'm looking for?

[zoltanersek _outpostlabs_dev_]

I'm also interested in this, the mcp should impersonate the user using it from my opinion.  

[Jatin K Malik]

Hey Ben, 

Thanks for raising this, it's a great question and one we're hearing from many enterprise customers.

Today, the Atlassian Rovo MCP Server enforces access based on:

• The user's existing Jira/Confluence permissions (via OAuth 2.1 scoped tokens)
• IP allowlisting policies
• Organization-level Read/Write/Search permission controls (configurable by admins in Atlassian Administration)
• Audit logs of all MCP tool invocations 

What's not yet available is the ability to enforce Data Security Policies (DSPs) , specifically, restricting MCP access based on data classification levels, workspaces, or containers. You're correct that the existing "App Access" DSP rule doesn't apply to the MCP Server, as it's not a Marketplace or Connect app.

What's coming: We're actively building a dedicated MCP rule within Data Security Policies. This will allow admins to govern MCP access using the same DSP model they already use for exports, downloads, public links, and third-party app access which is scoped by workspace, container, and classification level. This is on our near-term roadmap and is our highest-priority enterprise governance item.

The roadmap items you've spotted are related to this effort. We don't have a public date to share yet, but this is being treated as a must-have for enterprise adoption.

In the meantime, the controls listed above (permissions tab, IP allowlisting, OAuth scoping, and audit logs) are the available levers to manage MCP access. 

[Ben Spillane]

Hi Jatin - Thanks for the swift and precise answer.

I didn't want to assume the controls are on the horizon, so it's great to know they are and are of highest priority.