Rovo agents inherit the existing Jira and Confluence permission model by default, so an agent's access to a space, project, or issue is scoped to whatever the invoking user could already see. That default is sound. The control surface that actually needs deliberate governance is Rovo's extensibility layer — custom agents and Forge app integrations that call external actions or third-party APIs — because that layer is governed by its own configured permission scope, not by Confluence or Jira's native access model.
What Rovo's native permission inheritance covers
Atlassian built Rovo on top of the access controls its customers already run, rather than introducing a parallel permission system specific to AI features:
- Search and retrieval respect existing space and project permissions. A Rovo agent answering a question by searching Confluence content or Jira issues surfaces results filtered by the same permissions that already govern what the invoking user's own search would return.
- Cross-product context stays within the Atlassian permission boundary. Rovo's ability to draw context across Jira and Confluence together is a genuine usability advantage, and it does not require expanding what a user or agent can see beyond their existing access — it aggregates within that access, rather than around it.
- No default privilege escalation. An agent grounded this way cannot become a route for a user to see restricted content their role does not already permit, which is the same fundamental governance property that matters for any agent operating over an organization's internal documentation and issue tracking.
For the default Rovo chat and search experience, answering questions from content the user already has access to, this is a low-risk, well-integrated model, consistent with how most vendor-native agent platforms handle grounding correctly by inheriting rather than reinventing access control.
Where the extensibility layer changes the picture
Atlassian's platform is built to be extended — through Forge apps and Rovo's own agent-building capabilities that let teams create custom agents wired to actions beyond the default chat experience. That extensibility is a real strength of the platform generally, and it is also where governance responsibility shifts away from Atlassian's native permission model:
- A custom Rovo agent's actions are governed by whatever permission scope was configured for that specific integration, which may be broader or narrower than the building team intended, and is not automatically reconciled with the invoking user's own Jira or Confluence permissions.
- Forge apps and connected third-party tools reach outside the Atlassian cloud instance the moment they call an external API, at which point Confluence and Jira's own access logging and permission enforcement no longer apply to what happens next — the same structural pattern seen whenever a platform's native governance stops at its own product boundary. MCP server vetting and registry risk covers the review discipline needed for any tool integration reaching outside a platform's native boundary, applicable here regardless of whether the specific mechanism is Forge, a webhook, or an MCP connection.
- Confluence and Jira content is frequently sensitive in ways that are easy to underweight. Product roadmaps, security incident postmortems, architecture decision records, and vulnerability tracking commonly live in these tools, which makes an extensibility integration that reaches outside the Atlassian boundary a meaningfully higher-stakes surface than it might first appear.
- Ownership of custom agents and Forge integrations tends to sit with individual teams, which is efficient for building but means no central function necessarily has visibility into what every custom agent across the organization can actually reach.
This is a general pattern across every collaboration platform that has built an extensibility layer to let teams customize their own workflows — the platform's core product remains well governed while the extensions built on top of it accumulate their own, less centrally visible permission decisions. Atlassian's platform is not unusually risky in this respect; it is simply representative of what happens whenever a productivity tool is deliberately designed to be extended by the teams using it rather than only by a central platform team.
A cross-boundary risk checklist
| Question | Why it matters |
|---|---|
| Does the custom Rovo agent or Forge app call any external API or third-party service? | That call is the point where Confluence and Jira's own access logging stops covering what happens to the data. |
| Is the integration's permission scope reconciled with the invoking user's own space and project permissions? | A mismatch can let an agent surface or act on content the user would not otherwise access directly. |
| Is there a central inventory of every custom Rovo agent and Forge integration across the organization? | Without one, a security review has no starting point for identifying what to check. |
| Does the integration touch content classified as sensitive, such as incident postmortems or security documentation? | Those categories warrant a higher bar for review than a general-purpose productivity integration. |
| Is there a named, current owner for each custom agent, accountable if its configuration changes or its team moves on? | Ownership gaps are a common source of unreviewed access accumulating quietly over time. |
Why cross-product reach is the axis that matters here
A central inventory, audit trail coverage, and a cross-platform control-plane view are the same shared controls covered in building an AI agent inventory and what is an AI control plane — every collaboration platform with an extensibility layer needs some version of them.
What is specific to Rovo is the cross-product reach its default grounding already has, and what that implies once an agent gets extended: a Rovo agent can aggregate context across Jira and Confluence in one answer, which means a single custom extension or Forge app's misconfigured scope has a wider native blast radius than an equivalent extension on a single-product platform would. Two controls follow from that:
- Independent vetting for any integration reaching outside the Atlassian boundary, treating a Forge app's external API call with the same scrutiny given to any third-party tool integration, and explicitly reviewing whether that integration's scope was set with the cross-product context in mind or only for the one project it was originally built against. The MCP server governance guide covers the broader review discipline this fits inside, even where the specific mechanism is not MCP.
- Regular ownership review for custom agents and Forge integrations, catching orphaned or stale configurations before they become the thing an incident review has to explain after the fact — a Rovo agent's cross-product reach means an orphaned integration's blast radius spans more content than a single-space Confluence permission gap would.
What good looks like
- Every custom Rovo agent and Forge integration is inventoried with a current owner and a documented list of what it can reach outside native Atlassian permissions.
- Integrations reaching outside the Atlassian cloud instance are reviewed with the same rigor as any third-party API integration elsewhere in the organization.
- Sensitive content categories — incident postmortems, security documentation, roadmaps — are flagged for a higher review bar when a custom agent or integration touches them.
- Audit coverage spans Atlassian's native activity logs and any external system a custom agent's actions reach.
- Ownership of custom agents is reviewed on a defined cadence, not left unmanaged after the building team moves on to other work.
Common questions
Does Rovo's default chat experience expose content a user could not otherwise access? No, by design — Rovo's retrieval is scoped to the invoking user's existing Jira and Confluence permissions, and a well-configured deployment should not surface content outside that scope through the default experience.
Is a Forge app the same governance risk as a third-party MCP server? They share the same underlying risk shape — both extend a platform's native capability by reaching outside its own access control boundary — even though the specific technical mechanism differs. Both need independent review of what they can reach once invoked, rather than being assumed safe because the platform hosting them is well governed.
What is the first thing to check in an existing Rovo deployment with custom agents? Start by asking whether a central inventory of custom agents and Forge integrations exists at all. Most organizations extending a collaboration platform this way have not centralized that list, and building it is the prerequisite for every other control described above.
Does upgrading Atlassian's own security settings reduce the need for this review? Tightening space, project, and admin-level permissions in Jira and Confluence reduces what a custom agent could reach even in a misconfiguration, so it genuinely helps. It does not substitute for reviewing what each extensibility integration was separately configured to reach outside those native permissions, since that configuration lives in the integration itself, not in the underlying Atlassian permission settings.