Rovo turns the whole Atlassian site, plus every connected external app, into one searchable and actionable knowledge layer, so its security depends on the permissions people already hold, the connectors an organisation switches on and the agents and AI tools allowed to act for users. Atlassian Rovo brings AI search, chat, agents and an MCP server to Jira, Confluence, Jira Service Management and other Atlassian Cloud apps. Because Rovo acts within each user's existing permissions, the work of securing it is mostly about tidying those permissions, deciding which apps and connectors take part, controlling who builds and shares agents, and governing outside AI tools that reach Atlassian data through the Rovo MCP server. This guide is for Atlassian organisation admins, collaboration platform owners and security teams. For the Atlassian Cloud platform controls underneath Rovo (identity provider, managed accounts, authentication policies), see the Atlassian Cloud Security Guide.
This is an independent guide from NHI Mgmt Group, based on Atlassian's public documentation as of November 2026. It is not sponsored or reviewed by Atlassian. Product features change, so confirm settings against Atlassian's current documentation.
Key takeaways
- Rovo inherits permissions, so fix permissions first. Search, chat and agents only use content the user can already access, which means over-shared Confluence spaces and open Jira projects become easier to find once Rovo is on.
- Turn Rovo on app by app. Under Atlassian Administration, AI and Rovo then Access, organisation admins can block Rovo per app, and the documentation notes that AI active on any app on a site can read data from any app on that site.
- Treat connectors as data imports. A connector indexes the whole workspace of the connected app (for example all of Google Drive or SharePoint) unless a blocklist narrows it, and indexed content is deleted within 30 days of disconnecting.
- Decide who can build agents. Rovo Studio is open to everyone by default; Studio admins can limit agent creation to selected groups or to organisation admins only.
- Govern the Rovo MCP server. OAuth 2.1 is the default, admins choose which AI tool domains may connect, can switch API token access off and can enforce IP allowlists, and every MCP tool invocation is written to the audit log.
How identity and access work in Rovo
Rovo has no separate permission model for content. Atlassian's data privacy page states that Rovo mirrors access controls from connected Atlassian and third-party apps, so users see only content they can already access, and that Rovo monitors permission changes and updates its index to match. Agents follow the same rule: the agent governance page says the agent is acting on that person's behalf and can only use information that user can access. The MCP server documentation says OAuth tool calls act with the user's existing permissions, not elevated ones.
| Rovo surface | Whose identity it uses | Customer control |
|---|---|---|
| Search and Chat | The signed-in user | App-level Rovo access, space and project permissions |
| Agents | The user chatting with the agent | Studio settings for creation, agent visibility and roles, agent instructions and tools |
| Third-party connectors | The user's own connected account on the external app (or admin-synced results where enabled) | Which connectors are set up, blocklists, the synced-results option, disconnection |
| Agents in automations | The automation rule | Agents triggered in automations return a text response through {{agentResponse}} and run without their tools |
| Rovo MCP server | The user who consented through OAuth 2.1, or the owner of an API token | Allowed domains, API token toggle, IP allowlists |
The practical consequence is simple: Rovo makes existing access visible. A Confluence space set to anyone in the organisation, or a Jira project open to all licensed users, was always readable; Rovo makes it answerable in one question. Before enabling Rovo widely, run a permission review of spaces and projects that hold HR, legal, security, customer or credential material, and close anonymous or organisation-wide access that has no reason to exist. See the Embedded AI in SaaS Guide for the general pattern.
Connectors and the synced-results option
For third-party content, the default is that each user connects their own Atlassian account to the external app, which is how Rovo knows what that person may see. Atlassian also documents an admin option that lets users see synced connector results without connecting their account, with the external app's permissions still applied. For Google Drive and SharePoint a blocklist can narrow what is indexed. Atlassian notes that connecting an app may give that third party access to information used with it, under the third party's own terms, and recommends reviewing what an app stores before connecting it.
Admin roles and privileged access
Several Atlassian roles shape Rovo, and each should be held by a short, named list.
| Role | Rovo-relevant powers (per Atlassian docs) | Guidance |
|---|---|---|
| Organisation admin | Blocks or allows Rovo per app under AI and Rovo then Access; configures the Rovo MCP server under Connectors; reads the audit log; sets IP allowlists | Two or three people with phishing-resistant MFA, reviewed quarterly |
| Studio admin | Sets who may create agents in Rovo Studio: all users, selected groups (up to 10) or no users (organisation admins only) | Pick a small agent-builder group for the first phase |
| Agent owner, manager and editor | Owners add editors (edit the agent) or managers (also add editors and delete the agent); owners set visibility | Every agent has a named owner and a backup manager |
| Bitbucket workspace admin | Turns AI on or off under Workspace settings, AI, AI features | Align with the organisation decision for code |
| Site admin | Manages user-based OAuth connections under Apps, Sites, site settings, Connected apps | Review connected apps monthly |
Availability: Atlassian lists Rovo and Studio controls on Atlassian Cloud Standard, Premium and Enterprise plans; Enterprise plans use a separate access process, and Atlassian Government Cloud has its own feature list. For the identity provider and admin account controls that protect these roles, see the Atlassian Cloud Security Guide.
Agent visibility and sharing
Agents are visible to everyone by default and attributed to their owner. Owners can turn off Open to all users so that only people they add (each with a role) can use the agent. Access is granted per user rather than per group, so for an agent that works on sensitive content, keep the list short and pair it with knowledge sources the intended users can already read. Agent behaviour can also be narrowed through its instructions and the tools configured for it.
Integrations, API tokens and service accounts
Rovo creates new paths for data and actions to cross system boundaries. Each one needs an owner and a decision.
Agent tools and confirmation
Agents act through tools: creating Jira work items, updating status, searching with JQL, creating, editing and moving Confluence pages, raising service requests, and tools that reach third-party apps such as sending email or creating calendar events. Atlassian documents that the agent asks for confirmation before running consequential tools that may change data across systems, caps Jira bulk actions at 20 work items at a time, and limits agent-created calendar invites to four attendees. Actions through third-party tools appear as if the user performed them, and users can revoke access under Account settings, Connected apps. Train users that confirming an agent action is the same as doing it themselves. Forge developers can publish tool modules that stay visible only to their organisation unless published on Atlassian Marketplace, which makes internally built tools a code review item.
The Rovo MCP server
The Atlassian Rovo MCP server lets outside AI tools and developer environments reach Jira, Confluence and Teamwork Graph data. Atlassian lists three conditions for a tool call to succeed: for OAuth, the tool's domain is allowed in the MCP server Domains settings; the request comes from an IP permitted by organisation IP allowlists, if configured; and the authentication method is enabled.
| Setting | Where | Recommended stance |
|---|---|---|
| Allow Atlassian supported domains | Atlassian Administration, Connectors, Atlassian MCP server | Allowed by default. Keep it if the supported list matches your approved AI tools; otherwise deselect and add your own. |
| Add domain | Same page | Add only AI tools that passed your review. Domain controls apply to OAuth 2.1 clients. |
| API token access | Same page, Authentication | Switch off unless a reviewed non-interactive integration needs it; activity under API tokens may show a service account rather than an individual. |
| IP allowlists | Atlassian Administration security settings | Apply to MCP requests for both OAuth and API tokens. Allow *.atlassian.net for interactive widgets and add any AI tool outbound ranges you approve. |
| User-based OAuth connections | Site settings, Connected apps, Settings | Can be blocked entirely where external AI tools are not approved. |
API tokens used with the MCP server are long-lived user credentials. Manage them with the practices in the Atlassian API Tokens Security Guide, and for MCP server review criteria see the MCP Security Guide.
Logging and detection
- Audit log: in Atlassian Administration, Insights then Audit log, filter for Atlassian MCP User Actions or search for MCP. Every tool invocation through the MCP server is recorded with the tool name, the action and the user. The first OAuth authorisation of the Atlassian MCP app is also recorded; Availability: that event requires Atlassian Guard Standard, while tool invocation logging is on all tiers.
- Usage meters: Usage then Meters shows Rovo credit consumption, including MCP calls that retrieve data. A sudden rise is a useful signal of new automation or a new AI tool.
- Agent insights: an agent's owner, managers and editors can view usage insights (average daily users and total conversations, in beta as of November 2026), which helps confirm an agent is used by its intended audience. See Atlassian: Track how often a Rovo agent is used.
- Connected apps: review user-authorised apps on each site for AI tools that were not approved.
| Metric | Target | Source |
|---|---|---|
| Apps with Rovo access matching the approved list | 100% | AI and Rovo, Access table |
| Sensitive spaces and projects reviewed before enablement | 100% | Permission review record |
| Agents with a named owner and restricted visibility where they touch sensitive content | 100% | Agent directory |
| MCP tool calls from users outside approved groups | 0 | Audit log |
| Connectors with a blocklist or documented scope decision | 100% | Connector configuration |
Hardening baseline
- Review permissions before switching on. Find Confluence spaces and Jira projects with anonymous, organisation-wide or all-licensed-users access and confirm each is intended. Move secrets out of pages and tickets altogether.
- Enable Rovo per app in phases. Under AI and Rovo, Access, block apps that are not in scope for the first phase. Remember that for Jira family apps on one site, shared features (search, chat and Create with Rovo) stay on while any Jira app on that site has Rovo enabled, so block every Jira app if the goal is off.
- Check data location. Atlassian notes that some AI providers may process data outside the EU, and documents that Rovo supports data residency. Confirm both against your data residency commitments before enabling.
- Scope connectors. Connect only the external apps that are in scope, apply the blocklist for Google Drive and SharePoint, and decide deliberately whether to turn on synced results without per-user account connection.
- Limit agent creation. In Studio settings, set creation to selected groups for the first phase. Require every shared agent to have an owner, a manager and a stated purpose.
- Configure the MCP server. Set allowed domains, turn API token access off unless needed, apply IP allowlists, and block user OAuth connections on sites where external AI tools are not approved.
- Govern the browser extension. Atlassian documents admin control over whether users can install the Rovo browser extension and a Use current tab as context toggle that is on only when enabled. Decide both in line with your browser extension policy; see the Browser Extension Security Guide.
- Set up monitoring. Save an audit log filter for MCP activity, review usage meters monthly and export audit events to your SIEM.
Testing and rollback: pilot with a test user who has deliberately limited permissions and confirm that Rovo search and chat return nothing from restricted spaces. Test an agent action and confirm the confirmation prompt appears. Rolling back is quick: block the app under AI and Rovo, Access, which disables current and upcoming AI features for that app (content already generated remains), disconnect a connector (indexed content is deleted within 30 days), or remove a domain from the MCP server settings.
Data handling to record
Atlassian's data privacy page states that Rovo stores content from each indexed file, usage data and permission settings; that chat and agent inputs and outputs are retained for 30 days for safety and security; that it uses Atlassian-hosted open-source models and third-party hosted models from OpenAI, Anthropic and Google; and that those providers do not retain inputs and outputs or use them to improve their services. Record these points in your supplier assessment and privacy notice. See the AI and GDPR Guide.
Common misconfigurations
- Enabling Rovo before a permission review: organisation-wide spaces with sensitive pages become one question away. Review and tighten first.
- Blocking one Jira app and assuming Rovo is off: shared features stay on while any Jira app on the site keeps Rovo. Block every Jira app on that site.
- Connecting a whole workspace without a blocklist: an entire Google Drive or SharePoint is indexed. Apply the blocklist and connect only what is in scope.
- Open agent creation with default visibility: many agents visible to everyone, with unclear owners. Limit Studio creation and require owners.
- API token access left on for the MCP server: long-lived tokens reach Jira and Confluence from anywhere the IP allowlist permits. Turn it off unless a reviewed integration needs it.
- No MCP audit filter: tool invocations are logged but nobody looks. Save the filter and review it.
Framework mapping
| Control area | Rovo setting | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | Other |
|---|---|---|---|---|
| Permission hygiene | Space and project permissions | AC-3, AC-6 | PR.AA-05 | ISO/IEC 27001:2022 A.5.15 |
| Feature enablement | AI and Rovo Access, Studio settings | CM-7 | PR.PS-01 | OWASP LLM06:2025 Excessive Agency |
| Third-party data flows | Connectors, MCP domains | SA-9, AC-20 | GV.SC-07 | ISO/IEC 27001:2022 A.5.23 |
| Credentials | API token toggle, OAuth connections | IA-5 | PR.AA-05 | ISO/IEC 27001:2022 A.5.17 |
| Monitoring | Audit log, usage meters | AU-2, AU-6 | DE.CM-03 | ISO/IEC 27001:2022 A.8.16 |
| Sensitive data exposure | Blocklists, permissions | AC-3 | PR.DS-01 | OWASP LLM02:2025 Sensitive Information Disclosure |
Practitioner checklist
- Run a permission review of Confluence spaces and Jira projects holding sensitive material before enabling Rovo.
- Enable Rovo per app under AI and Rovo, Access, and block every Jira app on a site where Rovo should be off.
- Confirm data residency and AI provider processing locations against your commitments.
- Connect only in-scope external apps, apply blocklists and decide on synced results.
- Limit Rovo Studio agent creation to a named group and require an owner and manager for every shared agent.
- Set MCP server allowed domains, switch API token access off unless needed and apply IP allowlists.
- Decide the Rovo browser extension and current-tab context settings.
- Save an audit log filter for MCP activity, review usage meters monthly and forward audit events to the SIEM.
Standards and references
- Atlassian: Rovo data privacy and usage guidelines
- Atlassian: Manage Rovo access
- Atlassian: Rovo agent permissions and governance
- Atlassian: Agent actions
- Atlassian: Understand Atlassian Rovo MCP server
- Atlassian: Control Atlassian Rovo MCP server settings
- Atlassian: Monitor Atlassian MCP server activity
- OWASP: Top 10 for LLM Applications 2025
Related NHI Mgmt Group resources: Atlassian Cloud Security Guide · Atlassian API Tokens Security Guide · MCP Security Guide · Embedded AI in SaaS Guide · Confluence Data Center Hardening Guide