Governing Rovo: The Permission Model and Control Levers in One Place

[#1]

Hi Atlassian Community 👋

This article began with a question I was trying to answer for myself:

If an organisation wants to adopt Rovo responsibly, where exactly does Rovo governance happen?

I found plenty of useful information, but it was spread across different product documentation, administration guides, announcements, and Community discussions. Rovo’s permission model was explained in one place; connectors and web-search controls in another; agent creation, access, and tools elsewhere; and automation, the MCP server, auditing, data protection, and Atlassian Guard each introduced additional considerations.

Each source answered part of the question. What I was missing was a single, end-to-end view of how all these pieces fit together.

So I created the guide I wished I had when I started: a practical map of governance across Rovo Search, Chat, Agents, Automation, and external access through the Rovo MCP server.

Executive Summary

Atlassian Rovo brings generative AI — enterprise search, conversational chat, and configurable agents — directly into the tools where work already happens. Its value comes from its ability to reach across an organisation's connected knowledge; that same reach is precisely why it must be governed deliberately.

This paper explains, in plain terms, how governance works in Rovo. The foundation is a single principle: Rovo acts on behalf of each user, and can only see or do what that user is already permitted to. On top of that automatic foundation sits a set of administrative levers — controlling what Rovo can reach, who can build and use agents, what actions those agents may take, and how all activity is audited and protected.

The central message is simple: governing Rovo is less about switching AI "on or off" and more about consciously setting each lever to match your organisation's risk appetite. The sections that follow walk through Rovo's surfaces (Search, Chat, Agents, and Automation), the risks that come with generative AI, and the full set of controls available to administrators

What is AI Governance

AI governance is the set of policies, processes, roles, and controls an organisation uses to ensure its AI is used responsibly, safely, legally, and in line with its values — across the whole lifecycle of an AI system, from selection and configuration through everyday use and ongoing monitoring.

The need arises because generative AI introduces risks that conventional software does not. These cluster into five recurring categories: data & privacy, accuracy & reliability, fairness & bias, security, and compliance. Importantly, governance addresses both malicious misuse and accidental harm — and it is the accidental kind (a confident but wrong answer acted upon, or sensitive information surfaced to the wrong person) that accounts for most real-world incidents.

Governance is best understood as the balance between innovation — adopting AI quickly to capture its benefits — and accountability — remaining safe, compliant, and trustworthy. Done well, it is an enabler rather than a brake: clear guardrails are what allow an organisation to adopt AI with confidence.

Several widely recognised frameworks give this discipline structure:

• NIST AI RMF — a voluntary US framework organised around four functions: Govern, Map, Measure, Manage.

• ISO/IEC 42001 — the first international standard for AI management systems, and a certifiable one.

• EU AI Act — legislation that imposes risk-based obligations on AI systems.

A useful way to relate them: the EU AI Act defines what must be achieved, ISO/IEC 42001 describes how to run a governance programme, and the NIST AI RMF helps identify and manage risk. The remainder of this paper applies these general principles to a concrete product — Atlassian Rovo — showing how each is realised through built-in behaviour and administrative controls.

What Rovo Is

Atlassian Rovo is a generative-AI capability embedded across Atlassian's cloud products (such as Jira and Confluence) and extendable to connected third-party tools. Rather than being a separate destination, it surfaces inside the applications teams already use.

Rovo has four capabilities relevant to governance:

• Rovo Search — enterprise search that finds information across Atlassian and connected tools.

• Rovo Chat — a conversational assistant that answers questions, summarises, and drafts, grounded in organisational knowledge.

• Rovo Agents — configurable "AI teammates" that can not only answer but take actions and complete tasks; built and managed in Rovo Studio.

• Automation — flows in which agents run unattended to carry out multi-step work, once an administrator has configured and pre-approved the rule.

Underpinning all of these is the Teamwork Graph, Atlassian's knowledge model that maps the relationships between an organisation's work, people, and content. Rovo draws on this graph to provide context-aware results.

Two characteristics of Rovo make governance essential rather than optional:

1. Breadth of reach — Rovo can draw on many sources at once, so a single request can bring together information that was previously scattered.

2. Ability to act — through agents and automation, Rovo can change data and trigger workflows, not merely display information.

These two characteristics are the reason the governance model described in the following sections exists.

The Foundation: The Permission Model

Every governance property of Rovo rests on one principle, applied automatically and without configuration, across every Rovo surface — Search, Chat, and Agents alike:

"Rovo acts on behalf of the user, and can only access or act on what that user is already permitted to access or act on."

In practice this means:

• If a user cannot view a page, Rovo will not reveal or summarise its contents to them.

• If a user cannot comment on or delete an item, an agent acting for that user cannot do so either.

• Two people asking Rovo the identical question may receive different answers, because each response is bounded by that individual's access.

This guarantee is feature-wide: it is not limited to custom-built agents. General Rovo Chat and Rovo Search are bound by the same rule — Atlassian's documentation describes the permission model as applying to "Rovo Search, Chat, and agents" collectively.

This behaviour extends beyond Atlassian's own products to connected third-party tools, and Rovo's view of permissions updates as those permissions change — so revoking a user's access to a document also removes it from what Rovo can surface to them.

The significance of this design is that Rovo does not create a new, parallel path to data. It inherits the organisation's existing permission model rather than bypassing it. For most organisations, this is the single most reassuring fact about Rovo's data handling.

There is, however, an important corollary. Because Rovo faithfully enforces existing permissions, it also faithfully reflects any weaknesses in them. If sensitive content has been over-shared — for example, a confidential page left visible to "anyone" — Rovo will surface it just as the existing settings allow. Rovo enforces permissions; it does not repair them. Consequently, reviewing and tightening existing access — "permission hygiene" — is the most valuable preparatory step before broad adoption.

Governance Across Each Surface

Rovo Search

Rovo Search provides enterprise-wide search across Atlassian products and connected third-party tools. Its governance profile is the simplest of the four surfaces:

• Permission-filtered results. Every result is bounded by the user's existing access. Restricted pages, spaces, and issues are excluded from that user's results automatically.

• Reach defined by connectors. The searchable universe equals what has been connected through the Teamwork Graph. Anything not connected cannot be searched — making connector scope the primary control over Search.

• Non-generative core. Search does not generate new content, so it remains available even where an organisation has disabled generative-AI features. This makes it the lowest-risk surface.

• Third-party permissions respected. For connected external tools, Search honours those tools' permissions too, kept current through continuous synchronisation.

Governance takeaway: Search's main lever is connector scope — deciding which sources exist in the index in the first place. Because it is read-only and permission-filtered, it carries the least risk of the four surfaces.

Rovo Chat

Rovo Chat is a conversational assistant that answers questions, summarises content, and drafts text, grounded in the organisation's knowledge. Its governance considerations are:

• Permission-bound answers. As with Search, every answer is limited to what the individual user can already access (Section 4).

• Source citations. Chat cites the sources behind its answers, so users can trace and double-check where information came from — a built-in aid to verification.

• Optional web search. Administrators can allow or disallow Chat (and agents) from drawing on the public web. Enabling it broadens answers but introduces exposure to external, untrusted content; it is an organisation-level toggle.

• Generative — and therefore fallible. Because Chat generates text, answers can be fluent yet inaccurate ("hallucination"). Atlassian notes that experience and quality can vary. As a matter of governance best practice, Chat should be treated as an assistant whose consequential outputs are verified — not as an authority.

• Prompt hygiene. Chat introduces a human-side risk no permission setting can prevent: users voluntarily entering sensitive data into prompts. This is governed by policy and training; Atlassian's usage guidelines direct users to follow the Acceptable Use Policy.

Governance takeaway: Chat's key levers are the web-search toggle (what it can reach beyond your walls) and organisational policy and training (how people use it). Its built-in source citations support verification.

Rovo Agents

Rovo Agents are configurable AI teammates that go beyond answering — they can take actions and complete tasks. Because acting on systems has consequences, agents are the highest-consequence surface, and they carry the richest governance model. Several controls apply:

• Capabilities come from tools. An agent cannot act until it is explicitly given tools — the specific actions it may perform (create a page, transition an issue, add a comment, and so on). Nothing is granted automatically; each tool is added deliberately in Rovo Studio. Atlassian recommends assigning fewer than five tools per agent to keep it focused — an application of least privilege.

• The permission cap still applies. Even holding a tool, an agent can only act where the invoking user has the corresponding right (Section 4). A tool does not grant new access; it enables an action within the user's existing permissions.

• Who can create agents. Administrators choose who may build agents at all: all users (default), selected groups, or no users (admins only). This is the primary control against "agent sprawl."

• Who can use a given agent. Each agent's owner controls its visibility and assigns roles (who can manage, edit, or use it). Agents can be kept private or opened up.

• App agents vs. global agents. Agents built in the Studio interface ("global") have broad reach on the user's behalf and are governed by the create/access controls above. Agents shipped inside installed applications ("app" or Forge agents) are scoped by default to where the app is installed, and are governed by app-install approval and the permissions (scopes) the app declares. App agents are naturally more contained; global agents more flexible.

Governance takeaway: Agents are governed on four axes — who can build them, who can use them, which tools they hold, and the permission cap that bounds every action. Configured with least privilege, an agent is powerful yet tightly scoped.

Automation

Rovo agents can participate in automation flows — rules that, once an administrator configures and pre-approves them, run unattended: the per-action confirmation that interactive agents request is granted in advance at rule setup. Governance here focuses on unattended action:

• Runs under a connected identity. When an agent participates in an automation rule, it executes using the permissions of the user who connected it to the rule. The permission model of Section 4 therefore still bounds what the automation can access and do.

• An organisation-wide action lever. Rovo provides an org-wide setting governing what agents may do inside automation flows: Read and write (the default — agents can both access information and take actions) or Restrict to read only (agents can read and process, but cannot act). Choosing read-only is a direct implementation of read/write separation, a recognised defence against unintended or manipulated actions.

• Higher inherent risk. Because automation can run unattended and repeatedly, an incorrect or manipulated action has more room to cause damage than a single interactive request. This is why the read-only lever exists, and why sensitive or irreversible actions warrant human review.

Governance takeaway: Automation's key lever is the org-wide read-and-write / read-only setting for agents in flows. Keeping interactive agents capable while constraining unattended ones is a practical way to balance usefulness against risk.

External Access via the Rovo MCP Server

Beyond Atlassian's own interfaces, Rovo exposes a Model Context Protocol (MCP) server that lets approved external AI tools — assistants, editors, and other clients — connect to Atlassian data. Because this opens a door to data from outside Atlassian's products, it is an important governance surface in its own right:

• Permission-bound, like everything else. External tools act using the requesting user's current permissions. When a tool sends a request, the server checks that the tool is allowed and confirms the user's permissions before returning any data. The Section 4 model therefore extends to external clients too.

• Administrators control which tools may connect. Organisation admins authorise the specific domains that external AI tools use, and choose how tools authenticate — per-user OAuth 2.1 consent, or API tokens for non-interactive/service tools. These controls integrate with existing security measures such as IP allowlisting and app-management policies.

• Activity is auditable. Connections and actions made through the MCP server are recorded in the organisation's audit log, so administrators can see which external tools accessed what, and when.

Governance takeaway: The MCP server extends Rovo's reach to outside AI tools without weakening the permission model — but it introduces a decision every organisation should make deliberately: which external AI clients, if any, are authorised to connect, and how they authenticate. Left unmanaged, it can become a path for unsanctioned "shadow AI"; managed well, it is a governed, audited gateway.

Data Protection & Compliance

Beyond the per-user permission model, Rovo is governed by a layer of organisational data-protection and compliance controls. These determine where data lives, whether it is reused, and how activity is recorded and protected.

• Data is not used to train third-party models. The large-language-model providers Rovo relies on do not use an organisation's inputs and outputs to train or improve their models. (This is a distinct guarantee from where data is stored.)

• Data residency. Organisations can pin Rovo data to a specific geographic region, aligned with the residency of their Jira and Confluence data — relevant where local law dictates where data must be held.

• Retention limits. Inputs and outputs for Chat and agents are retained for a limited period (30 days) for safety and security purposes, then removed.

• Certifications. Rovo falls under Atlassian's enterprise compliance programme, including SOC 2 and ISO 27001; HIPAA considerations are addressed separately.

• Audit logging. Rovo activity — chats started, agents created or updated, connector changes, and tool invocations — is captured in the organisation's audit log, providing the accountability record that governance depends on.

• Atlassian Guard (advanced governance). For organisations needing more, Atlassian Guard adds capabilities that strengthen AI governance. Guard Standard provides identity and single sign-on (SAML), user provisioning (SCIM), authentication policies, the organization audit log, and data security policies. Guard Premium adds data classification, content scanning (sensitive-data detection), and threat detection. Because restricting AI from sensitive or classified content depends on classification and content scanning, that particular capability sits at the Premium tier.

Governance takeaway: Rovo's baseline protections — permission model, no-training guarantee, residency options, retention limits, certifications, and audit logging — are built in. Data classification and content scanning, which let an organisation actively restrict AI from sensitive content, are an added layer available through Atlassian Guard Premium.

Risk Landscape & Mitigations

Generative AI introduces a recognisable set of risks. This section names each, notes how it manifests with a tool like Rovo, and identifies the governance response — most of which map back to controls described earlier.

Risk	How it manifests	Governance response
Hallucination	Fluent but inaccurate output presented confidently	Human review of consequential outputs; use Chat's source citations to verify
Direct prompt injection	A user types instructions to make the AI bypass its rules	Vendor guardrails + monitoring/audit logs; the permission model still caps what any prompt can reach
Indirect prompt injection	Malicious instructions hidden in content the AI reads, causing an agent to act unintentionally	Limit what agents can reach and do — fewer connectors, least-privilege tools, and read-only automation. Human review helps for interactive actions, but automations run unattended, so keep those especially tightly scoped and monitored. Ranked #1 LLM risk by OWASP
Over-permissioned data	Rovo surfaces content that was over-shared	Permission hygiene before rollout; Guard data classification / content scanning to fence sensitive content
Shadow AI	Staff use ungoverned external AI tools, with no logs or oversight	Provide a governed alternative (Rovo); govern external access via the MCP server; an approved-tools policy
Prompt oversharing	Users paste sensitive data into prompts	Training, policy, Acceptable Use Policy — no technical control fully prevents it

Governance takeaway: Nearly every response traces back to the same small set of disciplines — permissions, connector and tool scoping, human oversight, monitoring, and training. A modest number of well-set controls defends against a wide range of risks.

The Control Levers

Organisation-level (Admin Hub → Rovo)

Lever	Controls	Default
Rovo access (blocklist)	Which apps have Rovo AI features (opt-out; blocking cuts external AI models off from that app's data)	On for all apps
Connectors (Teamwork Graph)	Which third-party sources Rovo can reach — upstream control over the whole tool/search universe	Per connection
Web search	Whether Chat/agents can use the public web	On
Beta features	Whether unreleased AI features auto-appear	On
Data residency	Geographic region for Rovo data	May be unpinned
Rovo MCP server	Which external AI clients may connect, and how they authenticate	Configurable

Agent-level (Rovo Studio)

Lever	Controls	Default
Who can create agents	All users / selected groups / no users	All users
Per-agent access	Who can view/use an agent + role	Set by owner
Tool assignment	Which actions an agent holds	None until added
Agents in automation	Read + write vs read-only	Read + write

 Security & Guard (Admin Hub → Security)

Lever	Controls	Tier
Authentication & SSO, SCIM provisioning	Who the users are	Guard Standard
Data security policies	Control export / app access / data-loss risk	Guard Standard
Organization audit log	Record of admin & Rovo activity	Guard Standard
Data classification	Label sensitive content	Guard Premium
Content scanning (sensitive-data detection)	Find sensitive content automatically	Guard Premium
Threat detection	Anomalous behaviour, alert investigations, SIEM	Guard Premium

Governance takeaway: Together, these levers let an organisation tune Rovo anywhere from fully open to tightly restricted. The recommended posture is neither "all on" nor "all off," but a conscious setting of each, matched to the organisation's risk appetite.

A Recommended Approach

Before rollout  

• Permission hygiene. Review and tighten existing access — over-shared spaces, stale guest accounts — before Rovo makes content easier to find.

• Connector governance. Connect only the sources you intend Rovo to reach, and review each connected tool's data-handling terms.

• Set tenancy controls. Decide who can create agents, whether web search and beta features are on, and pin data residency if required.

• Assign ownership. Name a person or team accountable for Rovo governance.

During rollout

• Pilot with one team and confirm the guardrails work — permissions behave as expected, and audit logging captures activity.

• Train users on prompt hygiene, and set an approved-tools policy (including external AI access via the MCP server).

Ongoing

• Monitor. Review audit logs; where possible, export them to a central security system and alert on unusual activity.

• Re-verify periodically. Watch for permission drift, new connectors, and newly created agents; revisit each lever as needs change

Governance takeaway: Do the unglamorous data hygiene first, roll out gradually, and treat governance as continuous. The technology's guardrails are built in; the organisation's discipline determines the outcome.

 Closing Remarks

Atlassian Rovo is designed so that its core protection — acting only on behalf of each user, within that user's existing permissions — is automatic and applies across every surface. Around that foundation sits a coherent set of levers: what Rovo can reach, who can build and use agents, what those agents may do, how external tools connect, and how activity is audited and protected.

Where Rovo governance actually lives. In practice, governing Rovo means working across three layers, not flipping a single switch:

• Your existing permissions (the foundation). Rovo inherits them automatically — so the first "control" is simply keeping your Jira, Confluence, and connector access tidy. No Rovo setting required.

• Rovo's own controls (where you'll spend most of your time). Admin Hub → Rovo for organisation-wide levers (app access, connectors, web search, data residency, the MCP server) and Rovo Studio for agents (who can build them, who can use them, which tools they hold, and read-only vs read-and-write in automation).

• Atlassian Guard (the security overlay). Admin Hub → Security adds identity, the organisation audit log, and data-security policies (Guard Standard), plus data classification, content scanning, and threat detection (Guard Premium) to actively fence and monitor sensitive content.

So the answer to "do I govern Rovo through Guard or through admin settings?" is both, in layers: Rovo's admin and Studio settings are the primary dials, resting on well-managed permissions, with Guard as the enterprise-grade security and monitoring layer on top.

The practical conclusion for any organisation is the one stated at the outset: governing Rovo is not a matter of switching AI on or off, but of setting each lever deliberately to match its risk appetite. Approached that way, Rovo can be adopted with confidence — capturing the benefits of generative AI while keeping data safe, compliant, and under control.

Rovo continues to evolve quickly, so I also see this as a living reference. If your organisation has discovered additional controls, implementation patterns, or governance gaps, I would welcome your experience in the comments. 

[MeghnaP_LogicLemur Labs]

Great perspective on Rovo governance. I especially liked the point that governance isn't a one-time setup and needs ongoing monitoring.

I think there's another piece worth looking at after deployment: how well are AI agents actually performing, and do users find their outcomes useful?

That's an area we've been exploring with AgentWorkLog for Jira, particularly around execution data, user feedback on AI Agent's execution and performance trends across teams and projects.

[Mia Tamm _Simpleasyty_]

Really useful overview. I like how this brings the different pieces together instead of looking at each feature in isolation.

The practical examples make it much easier to see where Rovo can actually help in day-to-day work. Thanks for sharing @Ajay _view26_!