What does your Rovo pre-activation permission audit actually cover?

[Prashanth]

Hi All,

Greetings for the day!

I reckon there’s a conversation that needs to happen more openly before organizations activate Rovo: what does data hygiene really mean at the permission level, not just the content level?

In several Cloud migration and governance discussions, I’ve seen teams focus heavily on content sensitivity, while spending less time examining the permissions that ultimately govern what Rovo can retrieve.

The Atlassian Graph indexes the permission reality of your site, not the permission intention. Runtime security trimming then enforces that reality at query time for every user.

Some of the areas I’ve been examining include:

Jira permission schemes with overly broad Browse Project grants

Confluence spaces that still allow authenticated-user or anonymous access

Page-level restrictions that have drifted over time

Group memberships that accumulate access through multiple inheritance paths

Legacy permissions carried forward from Server or Data Center migrations

I’m curious what others are including in their Rovo pre-flight reviews.

Have you identified specific Jira permission patterns that create unexpectedly broad visibility once Rovo is enabled?

Has anyone found an effective way to simulate what a specific user could retrieve through Rovo before a wider rollout?

Interested to hear what governance, platform engineering, and migration teams are seeing in practice.

[Gina Paciulli - XALT]

Hi @Prashanth

This is an excellent point and one that I believe many organizations underestimate when evaluating AI readiness.

In my experience, the biggest risk isn't necessarily sensitive content itself—it's the years of permission drift that accumulate as organizations grow, reorganize, and migrate platforms. By the time Rovo enters the conversation, many teams have never fully audited who can actually see what across Jira and Confluence.

I particularly like your statement that Atlassian Graph indexes the permission reality rather than the permission intention. That's a distinction many administrators miss. Organizations often assume permissions are operating as designed, when in reality inherited groups, legacy project roles, and historical access decisions have created a very different visibility model.

A few patterns I've encountered during governance reviews include:

• "Browse Project" permissions granted to broad authenticated-user groups

• Confluence spaces that were intended for specific teams but remain open to all licensed users

• Legacy migration groups that nobody owns but still provide access

• Project role assignments that have expanded over time without periodic review

• Archived projects and spaces that still contain discoverable information

One recommendation I often make before enabling AI capabilities is to perform access reviews from the perspective of representative user personas rather than administrators. What a project manager, developer, contractor, executive, or support analyst can access is often very different from what administrators believe they can access.

I would also be interested to hear whether anyone has developed a repeatable methodology for validating permission models at scale before a Rovo rollout. As AI adoption increases, permission governance feels less like a security exercise and more like a foundational requirement for successful AI implementation.