Configure Atlassian Rovo MCP server permission
As an organization admin, you use the Permissions tab within the Admin settings to control what data the Atlassian Rovo MCP server can read, write, and search across your organization’s Atlassian apps and connected tools. You can turn permissions on or off from the table, or open Edit details to choose more specific permissions.
The Permissions tab found via Atlassian Administration > Rovo > Rovo MCP server is now the primary way to control what the MCP server can access across your organization. Going forward, permissions configured here will take precedence over settings in Connected Apps or individual app permissions in Marketplace. To restrict or allow specific actions — such as preventing the MCP server from creating or editing content — use the Permissions tab.
Learn more about tools supported by Atlassian Rovo MCP server
What you can configure
Permission | What it controls |
|---|---|
Read | Whether the server can view and read data from Atlassian apps |
Write | Whether the server can create and modify data in Atlassian apps |
Search | Whether the server can search data across Atlassian apps |
Status in the table
Status | Meaning |
|---|---|
Allowed | The setting is on for all relevant permissions |
Blocked | The setting is off for all relevant permissions |
Partially allowed | The setting is on for some permissions but not all |
Change permissions from the table
Step 1. Open Permissions
In Administration, open Atlassian Rovo MCP server for your organization.
Select the Permissions tab.
Step 2. Review Read, Write, and Search
Check the Status column for each permission.
Use the row checkboxes to turn a permission type on or off for all permissions where the UI allows it, or use Select all permissions in the header when you want to apply a bulk change.
Apply to future additions: When you allow an intent, that access is automatically granted to any new permissions that request the same permission. New permissions won’t require manual review by admins and will be available to users as soon as they’re added. Admins can change this behavior at any time in the “Edit details” modal.
If an update fails, try refreshing the page. If the problem continues, contact Atlassian Support.
Edit permissions per app (Edit details)
Use Edit details when you need different settings per app (for example Jira vs Confluence).
Step 1. Open Edit details
On the Permissions tab, find the permission type (Read, Write, or Search).
Select Edit details.
Step 2. Choose apps (permissions)
In the modal, review each app row and use the checkboxes to allow or block that permission for that app.
Optionally turn on Allow all, apply permissions to future additions automatically so new apps or permission sets inherit these settings. (Confirm final in-product wording.)
This Apply to future additions control is the same idea as turning the permission on from the main table row checkbox: both mean new permission for that intent will receive access unless you change the setting again.
Step 3. Save and dismiss
Save your changes in the modal.
Read the confirmation banner and dismiss it with Understood when you're done.
What users see when a permission is blocked
When a permission is blocked, users connecting through an AI client (such as Claude, Cursor, or another MCP-compatible tool) will see the following error message:
Access denied: Your organization admin has not authorized the [permission name] permission.
For example: Access denied: Your organization admin has not authorized the write permission.
If users report this error, check the Permissions tab to confirm the relevant permission is set to Allowed. Changes take effect immediately — no restart or reconnection is required.
FAQ
This section lists the exact error messages that users or admins may encounter as a result of this change.
End-user facing errors (shown in AI client e.g. Claude, Cursor)
Q: A user reports they can't use a tool and sees an error. What does it say?
There are three possible error messages depending on the scenario:
Scenario | Exact error message |
|---|---|
A toolset is blocked by the org admin |
|
The user's org cannot be determined (e.g. account not mapped to an org) |
|
A transient backend error occurred during the permission check |
|
Resolution for each:
"Access denied: Your organization admin has not authorized..." — The admin needs to go to Atlassian Administration > Atlassian Rovo MCP server > Permissions and set the relevant permission to Allowed. Changes take effect immediately.
"We are having trouble verifying your organization permissions..." — Confirm the user's Atlassian account is associated with the correct organization. If the issue persists, escalate to engineering.
"We are having trouble completing this action..." — Ask the user to retry. If persistent, contact Atlassian Support.
Admin-facing errors (shown in Atlassian Administration UI)
These are the exact error messages an org admin may see in the Atlassian Administration UI when managing the Rovo MCP Server Permissions tab.
Permissions tab — loading error
Shown as a full-page empty state when the Permissions tab fails to load toolset data (e.g. network or API error):
Scenario | Title | Body |
|---|---|---|
Permissions tab fails to load |
|
|
Permissions tab — toggle / save errors
Shown as a flag (toast notification) when an admin tries to enable or block a permission row (Read, Write, Search) and the mutation fails, or when saving changes in the "Edit details" modal fails:
Scenario | Flag title | Flag body |
|---|---|---|
Toggling a permission (Read/Write/Search) on or off fails |
|
|
Saving changes in the "Edit details" modal (per-product toolset configuration) fails |
|
|
Resolution: Ask the admin to refresh the page and try again. If the problem persists, contact Atlassian Support.
Other policy-related errors (not specific to toolset enforcement)
These may be seen by users in other scenarios and should not be confused with toolset permission errors:
Scenario | Exact error message |
|---|---|
User connecting from a blocked IP address |
|
User connecting via a disallowed auth method (e.g. API token when headless auth is blocked) |
|
Redirect URI not on the org's allowlist |
|
Was this helpful?