Is Atlassian Rovo safe to use?

By the usual enterprise checklist, yes — Rovo and the AI features around it have SOC 2 and ISO 27001 certifications, and Atlassian states third-party LLM providers don't retain or train on your inputs and outputs. That answers the compliance question. It doesn't answer the operational one: what an admin has to configure — connector blocklists, data residency, disconnect behavior, audit scope, permission model — before a rollout is actually safe for your org, not just certified in the abstract.

Does Rovo respect existing Jira and Confluence permissions?

Yes, per Atlassian's own docs on agent permissions and governance: an agent acts on behalf of the user who invoked it, so it can only return or interact with spaces, pages, and work items that user already has permission to access. If a user can't see a page, an agent can't surface it to them; if a user can't delete something, an agent can't delete it either. Rovo Search works the same way — it's scoped to what the searching user is already authorized to see. There's no separate, broader Rovo-level access to police on top of your existing permission scheme, which is one less thing to audit before rollout.

What happens to indexed content when you disconnect a Rovo connector?

Atlassian states it will delete the content indexed from that third-party app within 30 days of disconnection, with cached data persisting for up to 5 minutes immediately after and the disconnection process itself taking up to 48 hours to complete. GitHub is the one named exception: because GitHub content is integrated through the GitHub for Jira app, data is only deleted if you both disconnect GitHub from Rovo and uninstall the GitHub for Jira app — disconnecting the Rovo side alone isn't enough.

Can you control what content Rovo indexes from SharePoint or Google Drive?

Yes. Atlassian's own data-privacy documentation says admins can refine the scope of data indexed from specific connectors — SharePoint and Google Drive are the two it names — using a blocklist. That's a real, admin-facing control, not just a setting buried in the connector's own third-party permissions, and it's worth configuring before you turn a connector on, not after content is already indexed.

Can Rovo data be pinned to a specific region for data residency?

Mostly. Org admins can choose where in-scope Rovo data is stored via the Data residency controls at admin.atlassian.com, across the same regions Atlassian's other cloud products support (Australia, Canada, EU, Germany, India, Japan, Singapore, South Korea, Switzerland, UK, USA). Two carve-outs to know before you assume full coverage: apps built with Forge in Rovo Studio can't be pinned — their source and configuration aren't covered by data residency — and Atlassian-native content (say, a Confluence page) indexed into Rovo's search index follows that source app's own residency setting rather than a separate Rovo-level one.

Rovo Security Checklist: What to Decide Before Rollout

Every “is Rovo safe” search lands on the same non-answer. Atlassian’s own docs are the one page that will always rank first for it, and that’s fine — cede it, it’s their product and their compliance page. What’s missing is everything after the partner blog posts that stop at “yes, it’s SOC 2 certified.” That’s a real answer to a compliance question nobody in IT actually asked. The question a Jira or Confluence admin has open in a tab before rollout is narrower and more useful: what do I have to decide, or turn off, before I let this touch my org’s data?

This is that list — five decisions, each backed by what Atlassian’s own docs actually say, not a vendor’s reassurance paragraph.

The five things to decide before rollout

1. Blocklist third-party content before you index it, not after

Rovo’s Teamwork Graph connectors don’t index a folder at a time — a synced connector to SharePoint or Google Drive can pull in an entire workspace. Atlassian’s data-privacy documentation states admins can “refine the scope of the data indexed with some specific connectors (such as Google Drive and SharePoint) using a blocklist” (Rovo data, privacy, and usage guidelines). That’s a real, admin-facing control — configure it before you enable the connector, because a blocklist scopes what gets indexed going forward, not a retroactive filter on content Rovo already has.

The decision underneath the blocklist: connectors come in two kinds, and which one a given tool uses changes what you’re actually agreeing to.

Synced connectors store and index a copy of the content using a service or admin account — best search quality, but Atlassian is now holding a copy of that data, and it counts toward your org’s indexed-objects allowance.
Direct connectors query the source system’s own search API live and store nothing — data isn’t copied into Atlassian’s index at all, at some cost to search quality and latency.

(Full detail: Teamwork Graph connector types.) If your security review cares about where a copy of the data lives, that’s the first question to ask about any connector before enabling it — not “is it certified,” but “synced or direct.”

2. Pin data residency — and know the two carve-outs

Org admins can choose where in-scope Rovo data is stored using the Data residency controls at admin.atlassian.com, across the same region list as Atlassian’s other cloud products: Australia, Canada, EU, Germany, India, Japan, Singapore, South Korea, Switzerland, UK, USA (Understand data residency). For most compliance requirements, that’s coverage.

Two things worth confirming rather than assuming, because they’re carve-outs from the general rule:

Rovo Studio (Forge) apps aren’t covered. Source code and configuration for anything built in Rovo Studio can’t be pinned to a region.
Atlassian-native content follows its own app’s setting, not a separate Rovo one. A Confluence page indexed into the Rovo search index inherits Confluence’s residency configuration — there’s no independent “Rovo residency” toggle sitting on top of it.

If your legal or security team is asking “where does this data live,” the honest answer is “wherever you’ve pinned the underlying app, plus the region you pick for the rest” — not a single Rovo-wide setting.

3. Know the disconnect-and-retention window before you trial a connector

Connectors get trialed and killed more often than admins expect — a security review flags one, or the pilot just doesn’t earn its keep. What happens to the content Rovo already indexed matters for anyone who trials first and asks permission later.

Per Atlassian’s own docs: disconnecting an app deletes the content indexed from it within 30 days, with cached data persisting for up to 5 minutes right after you disconnect, and the disconnection process itself taking up to 48 hours to fully complete (Disconnect an app from Teamwork Graph; the 30-day figure is stated in the privacy and usage guidelines). GitHub is the named exception: because GitHub content flows in through the GitHub for Jira app, disconnecting the Rovo side alone doesn’t remove it — you also have to uninstall GitHub for Jira. If GitHub is one of your connectors, that’s a two-step teardown, not one, and it’s easy to miss the second step during a rushed offboarding.

4. Confirm your audit-log tier before you rely on it

Rovo activity is tracked in Atlassian’s audit log, but coverage is split by subscription tier, not universal. Per Atlassian’s own announcement of the feature: Rovo admin actions — agent created/updated/deleted, connector created/updated/deleted, definition created — are visible to Atlassian Guard Standard and above. Rovo user actions — chat started, bookmarks created/updated/deleted — require Atlassian Guard Premium (Rovo activities are now live in the Audit log — Atlassian Community).

The practical read: if you’re on Guard Standard, you can see what got configured (agents, connectors) but not who used Rovo Chat and when — that visibility gap only closes on Premium. Check which tier you’re actually on before you promise a security review “we have full audit coverage of Rovo usage.”

5. Understand the permission-inheritance model — it’s simpler than it sounds, but verify it

This is the question every admin actually has in their head under “is it safe”: can Rovo surface something to a user that user couldn’t otherwise see? Per Atlassian’s own docs on agent permissions and governance: no. An agent acts on behalf of the person using it — “it therefore can only return or interact with spaces, pages, work items, and other information that the user has permission to access.” If a user can’t view a page, the agent can’t respond with anything about that page; if a user can’t delete a Confluence page, the agent can’t delete it either. Rovo Search works on the same principle — results are scoped to what the searching user is already authorized to see.

That means the permission model you already run in Jira and Confluence is the Rovo permission model — there’s no parallel access scheme to design from scratch. What’s worth doing is verifying it, not just trusting the doc: spot-check with a low-privilege test account against a space it shouldn’t see, both before rollout and again after you add a new connector, since a synced connector bringing in third-party content is the one place a permissions mismatch (their access model vs. yours) could theoretically create a gap.

One adjacent control worth setting on day one: who can build a Rovo agent at all. Studio admins can restrict agent creation to all users (the default), selected groups (up to 10), or org admins only — worth tightening before agent sprawl becomes the actual governance problem, separate from the data-access question above.

The checklist, quick-reference

Blocklist scoped for every synced SharePoint/Drive connector, set before enabling it
Synced vs. direct confirmed for each connector you’re turning on
Data residency region pinned — and Rovo Studio / native-app carve-outs understood, not assumed away
Disconnect-and-retention window (30 days; GitHub’s two-step teardown) documented in your offboarding runbook
Audit log tier confirmed (Guard Standard = admin actions; Premium = user actions too)
Permission inheritance spot-checked with a low-privilege test account, not just trusted from the docs
Agent-creation governance set (all users / selected groups / admins only) before rollout, not after sprawl

What this page is deliberately not

Not a “is Rovo GDPR/HIPAA compliant” survey — Atlassian’s own data usage and privacy guide and Trust Center cover that ground better than a third party can. And not a guide to building a Rovo agent — that’s a different job with its own decisions, covered separately. This page is the narrower, more useful thing: the list an admin actually needs before flipping the switch on connectors and agents. For the rest of the Rovo landscape — what Rovo actually is, what it costs, how it plugs into DevOps, how it stacks against Microsoft Copilot — see What is Rovo?, Rovo pricing and credits explained, and Rovo DevOps integration.

If your rollout decision turns into “we need a custom Rovo agent with tighter guardrails than the default,” we build those.