nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What are the permission limits of the native Rovo MCP server for Claude?

Utkarsh Chandel

Hello everyone,

I'm looking into connecting Anthropic's Claude with Jira and Confluence using Atlassian's native Rovo MCP server. I'm still learning how this setup works and wanted to check a few things with people who have experience using it.

If a user has permission to edit or delete Jira issues and Confluence pages, is there a way to keep Claude read-only without changing the user's permissions?

Also, does Rovo MCP support masking sensitive information like PII, API keys, or credentials before sending it to Claude? Can we restrict Claude from accessing specific Jira projects or Confluence spaces, even when the connected user has access to them?

If these controls aren't available out of the box, are there any Marketplace apps or third-party tools that can help manage what AI agents can access and do?

Would appreciate any suggestions or examples from teams that have already worked on this. Thanks!

Comments

Josh

Hi @Utkarsh Chandel , taking these one at a time. I've split them into what an org admin can control and what they can't.

Keep Claude read-only without touching the user's permissions: yes. In Atlassian Administration go to Rovo > Rovo MCP server > Permissions. There are three permission types, Read, Write and Search. Set Write to blocked and leave Read and Search on. You can also open Edit details to block write for one app (for example Confluence) and keep it for another. Atlassian says these settings now override Connected apps and per-app settings, and they take effect straight away.

Limit which tools can connect and from where. On the Domains tab you allowlist the AI clients allowed to connect over OAuth 2.1 (claude.ai, for example). You can also turn off API-token (headless) auth. Your org IP allowlist applies to MCP calls too, whichever auth method is used.

Limit Claude to certain projects or spaces: not as a per-tool setting. MCP calls run as the user who signed in, so Claude can see whatever that user can see. To keep it out of a space today, use the usual permission levers: Confluence space or page restrictions, Jira project permissions or issue security. Another option is a dedicated account with narrower access that's used only for the AI connection.

PII and secret masking: I'm not aware of any built-in redaction in the MCP server. Content goes back to the client as stored. If you have Atlassian Guard, check whether data classification plus a data security policy that restricts AI access covers MCP traffic for your plan before you count on it. Otherwise, the real fix is to keep credentials out of tickets and pages in the first place.

For governance, MCP activity shows up in the org audit log, so you can check what was read or changed after a pilot.

Sami Shaik

@Utkarsh Chandel ,

@Josh has covered the Permissions and Domains tabs correctly. One update on the point he flagged as “check before you count on it”: there is a control that keeps MCP out of specific spaces even when the signed-in user can open them, and it is documented.

The Atlassian Rovo MCP server control in Data security policies. Path: admin.atlassian.com, Security, Data protection, Data security policies, select the Atlassian Rovo MCP server control, create a draft, set the organisation-wide default to Allowed or Blocked, then add overrides at app level, space level, or classification level, and activate. Atlassian’s page states that it “works alongside existing user permissions” and that “Blocking MCP access doesn’t change what users can do directly in Jira or Confluence”, which is exactly your case: the user keeps edit rights, the AI client does not get the content.

What it covers, from the same page:

Confluence: pages, spaces and classified content.
Jira: blocked work items are excluded from MCP results; when blocked, the client gets a “does not exist or you don’t have permission” response even though the user could view the item directly.
Prerequisites: Atlassian Guard Standard for the control; Guard Premium for classification-level overrides. Organisation admin to configure.

Three limits to design around:

It is enforced only for OAuth authentication, not API-token authentication. If you leave API-token access on under Rovo MCP server, Authentication, the policy does not apply to those calls. Turn it off, as Josh said, or the control has a hole in it.
A blocked Confluence space still allows a few actions (listing spaces, creating a space, global templates), so it hides content, not the space’s existence.
It covers the Atlassian Rovo MCP server only: not custom MCP servers, not the REST API, not the UI.

On masking: Josh is right that there is no redaction layer. The classification override is the nearest thing: classify the sensitive pages and block MCP for that classification, which removes them from AI results wholesale rather than masking fields inside them.

Reference: https://support.atlassian.com/security-and-access-policies/docs/prevent-atlassian-rovo-mcp-server-access/

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

jira

jira-cloud

marketplace-apps

ai-apps