Before you turn on Rovo: check who can see what in Jira and Confluence
Rovo, and AI tools such as Claude, Cursor or ChatGPT connected through the Atlassian MCP server, only show people what they can already see. That sounds safe, and it is, as long as your permissions are right. The problem is old over-sharing: a space that was open to everyone for years, but nobody found it. With AI search, people find it with one question. This guide lists what to check in Confluence and Jira before you roll Rovo out, how to check it with the built-in screens, and which settings you have for Rovo itself.
We build AccessLens, a permission audit app, so read the last section with that in mind. Everything before it works without any app.
What Rovo can see
Atlassian’s Rovo data, privacy and usage guidelines say Rovo follows the access settings of Atlassian and connected apps, so that “users only see content they have access to”. The Atlassian MCP server says the same for outside AI tools: access is granted only to data the user can already view.
So Rovo does not open anything new. But it changes how easy it is to find what is already open:
- Before, a person had to know a space existed, open it and read. Now they ask “what are this year’s salary bands?” and get an answer from any page they can read, in any space.
- A space open to every logged-in user is open to every Rovo user, and to every AI tool those users connect.
- Rovo enforces permissions, it does not repair them. If a page should not be readable by everyone, the fix is the permission, not a Rovo setting.
Five things to check
- Confluence spaces with anonymous access. Anyone on the web can read them, and so can every user’s AI tools.
- Confluence spaces open to all logged-in users. Often set years ago “so people can find things”. Check that HR, finance, security, legal and customer spaces are not among them.
- Jira spaces (projects) open to the public or to everyone with Jira. Permission schemes are often shared by many spaces and give browse access to everyone with Jira. That is fine for most work and wrong for an HR or security space.
- Who is in the groups that reach sensitive content. A group named “finance” may hold contractors, or people who moved team two years ago.
- Spaces with no admin, guests and leavers. A space nobody owns has nobody to fix it. Guests and accounts of people who left still count as users.
Check Confluence
Anonymous access, site level.
- Open Confluence administration from the cog in the top-right corner.
- Go to Settings, then Security, then the Anonymous access tab.
- If Use Confluence is off, no space can be public. If it is on, each space decides for itself.
Atlassian’s page on controlling anonymous access tells you to check which spaces have it before you change the site setting, but it does not describe a list of those spaces. You check them one by one.
Each space.
- In the space sidebar, open More actions (•••), then Space settings.
- Open Users. Look for the Anonymous users class and for grants to all logged-in users, and check which groups have access.
- Note any space where nobody holds the admin permission.
Page restrictions only narrow what the space allows; they never open a page to more people. So start with space permissions. The restrictions inside a space matter for the next step: a sensitive page in an open space is only safe if it is restricted. And in Confluence Cloud a view restriction is passed down to child pages, but an edit restriction is not (CONFCLOUD-5095).
Check Jira
Jira now calls projects spaces and issues work items in its menus, so the steps use those words.
- Select Settings, then Work items. Under Work item attributes, open Permission schemes (near the bottom of the list).
- For each scheme, select Permissions and look at who holds Browse spaces. Watch for the broad holders: Public (anyone on the web), Any logged in user and Application access (everyone with Jira).
- Note which spaces use each scheme. One scheme is often shared by many spaces, so one broad grant can cover fifty of them.
- In each sensitive space, open its settings and check who is in each role.
See Atlassian’s Grant or revoke permissions in a scheme. Jira has no screen that starts from a group and lists every space it can reach (JRACLOUD-71967). Our Jira permission audit guide shows the native screens, a REST API script and an app side by side.
Settings for Rovo itself
Rovo has a few controls of its own. None of them replace fixing permissions.
- Rovo MCP server. In Atlassian Administration, open Rovo, then Rovo MCP server, then Permissions. You can allow or block read, write and search, for each app such as Jira or Confluence (Atlassian’s guide).
- Connectors. For some connectors, such as Google Drive and SharePoint, you can block folders or sites from being indexed.
- One space or project. As of October 2026 there is no setting to keep Rovo out of a single space or project. The request is ROVO-974. Until then, the only way to keep a space out of Rovo answers is to limit who can see it.
- Sensitive data. Atlassian Guard Premium, a paid add-on, can scan content for sensitive data and label it. It looks at what pages contain, not at who can open them, so it is a second check, not a replacement for the five above.
A rollout checklist
- Record today’s state. Export or note the permissions of every Confluence and Jira space before you change anything, so you can show what you fixed.
- Close anonymous access wherever it is not meant to be public.
- Remove “everyone” from sensitive spaces and give access to named groups instead.
- Read the members of those groups with the owners of the content. Remove guests and leavers.
- Give each space without an admin an owner.
- Restrict the pages that must stay private inside spaces that stay open.
- Record the state again, compare it with step 1, and keep both.
- Then turn on Rovo, or allow the MCP server, for a pilot group first.
Where AccessLens fits
AccessLens for Confluence reads every non-personal space in one scan and flags spaces that anonymous users can read, spaces granted to every logged-in user, and spaces with no admin. It answers which spaces a group or a person can reach, with group membership expanded, and lists restricted pages with what locks them. AccessLens for Jira flags projects (spaces) that anonymous users can browse or that are granted to every licensed user, and lists every project a group or person can reach.
Both take a snapshot before you start and another when you finish, and show the difference one row per space or project and group. That is the “record today’s state” and “record it again” steps above, with a signed review if you need one for an auditor.
What they do not do: they do not read page content for sensitive data, they do not change any setting (both are read-only), and they do not control Rovo. Personal spaces are skipped, and on some Confluence sites anonymous access cannot be read through the API; AccessLens then says so instead of reporting “none”. Both run on Atlassian Forge with no external calls and are free for sites of up to 10 users.