How to Review Rovo Agent Access in Jira and Confluence

A Rovo agent access review checks four things: who can create agents, who can use each one, what each agent can reach and change, and whether you can trace what it did. Start by finding out which identity each agent uses, because an agent either borrows the permissions of the person using it or runs under its own agent account.

This guide walks through the review step by step, using the settings Atlassian gives you today in Atlassian Administration and Rovo Studio. It is the same sequence Atlas Bench runs before a customer switches agents on across Jira and Confluence. You can run it yourself in an afternoon for a small estate, or over a couple of weeks for a large one.

Why agents need their own access review

Your existing access review covers people. Agents change four things about it.

First, agents reach further than people usually do. A person opens a few pages a day. An agent can search everything that person is allowed to see and summarize it in seconds. A group that grants more than its name suggests was a quiet problem before. With agents, it becomes a visible one.

Second, agents can write. Atlassian documents write actions such as creating a Jira work item, updating a status, and creating, editing, or moving Confluence pages. In chat, the agent usually asks for confirmation before it runs an action that changes data. In automation rules, agents can be set up to act without asking.

Third, the defaults are open. Anyone with access to Rovo Studio can create an agent, and new agents are open to all users unless the owner changes that. None of this is wrong. It just means the review has to happen on purpose.

Fourth, agents come in two kinds. When someone builds an agent, they choose which account it uses. With a user's account, the agent takes on the identity and permissions of the person using it. With its own agent account, it has only the access that admins, space admins, and content owners grant it, and anything it creates or edits is credited to the agent. The review is different for each, so every step below covers both.

What you need before you start

• Organization admin access in Atlassian Administration, and Studio admin access in Rovo Studio.
• A user export with last active dates, so you know which accounts are real and current.
• A list of your groups and what each one grants in Jira and Confluence.
• One person who will own the result. A review without an owner does not repeat.

Step 1: Decide who can create agents

In Rovo Studio, go to Settings, then Studio settings, then Agents. You have three choices: all users, selected groups (up to 10), or no users, which leaves creation to Studio admins.

For most organizations starting out, selected groups is the right answer. Pick the teams that have a real use case and someone accountable for what they build. Everyone else can still use the agents those teams publish.

Step 2: Inventory the agents you already have

With Atlassian Guard Premium, org admins can manage agents in Atlassian Administration under Rovo, then Agents. From there they can grant or revoke an agent's app access, add it to groups, and set default access for future agents. Without Guard Premium, build the inventory from Rovo Studio and your agent owners.

For each agent, record six things:

1. Owner. A named person, not a team alias.
2. Purpose. One sentence on what it is for.
3. Apps. Which of Jira, Confluence, and your connected tools it can reach.
4. Write actions. Whether it can create or change work items or pages.
5. Automation. Any rule or flow that triggers it.
6. Identity. Whether it uses the account of the person using it or its own agent account.

Agents with no owner or no clear purpose go on a list to retire. If nobody claims one within a set window, turn it off.

Step 3: Check who can use each agent

Agents are open to all users by default. An owner can turn off open access and add named people as editors or managers. Atlassian's documentation says restricting an agent to specific groups or teams is not supported yet.

How much this matters depends on the agent's identity. For an agent that uses the person's account, the sharing setting is a minor control. The main control is what each person is allowed to see, which is the next step. For an agent with its own account, sharing the agent also shares everything the agent can reach with everyone who can use it. For those agents, keep the list of people short and named.

Step 4: Check what each agent can reach

For an agent that uses the person's account, this step is really a review of your permission model. Atlassian puts it plainly: if a user cannot delete a Confluence page, the agent cannot either.

For an agent with its own account, review what the agent itself has been granted. That access comes from three places: the default access org admins set for agents, the spaces app and space admins open to it, and content individual users choose to share with it. Check each agent account the way you would check a service account: named owner, narrow scope, and a reason for every grant.

Look at the places where access is wider than intended:

• Jira permission schemes that grant browse access to large groups by default.
• Confluence spaces open to everyone on the site when they hold HR, finance, or security content.
• Groups that were created for one project years ago and still carry broad grants.
• Connected tools. For third-party sources such as Google Drive and SharePoint, Rovo only shows restricted content to people who already have access in the source. Confirm that permission sync covers the connectors you use.

If you find a problem in the permission model, fix the permission, not the agent. Fixing the permission protects every person, and every agent that uses a person's account, at once. This is the same work our Guard cleanup and access reviews service does for human accounts.

Step 5: Check what each agent can change

List every agent that has write actions turned on. For each one, confirm the owner expects it to create or change content, and that the change is reversible.

Then look at automation. Agents can be started from an automation trigger or called as a step in a flow, and in automation they can be set up to act without confirmation. Admins and users can also prevent agents from acting in automations. For every rule that calls an agent, record who owns the rule and whether the agent needs to write at all. If it only needs to draft text, restrict it to read actions in the rule, or prevent it from acting and use its response in the next step instead.

Watch the identity here too. If an agent in an automation uses a user's account, it runs with the permissions of whoever set up the rule, not the person whose change triggered it. Atlassian's guidance is to give agents that run in automations their own account, so their access is scoped to the job.

Step 6: Check the MCP door

The Atlassian Rovo MCP server lets outside tools and assistants reach Jira and Confluence. It uses OAuth 2.1 with per-user consent by default, so each person's existing permissions still apply. Admins can also allow API token authentication for tools that run without a person, and they can keep an allowlist of domains for tools that connect with OAuth. The domain allowlist does not apply to tools that connect with API tokens.

Three checks here:

• Is API token access turned on, and if so, whose token is each tool using, a person's or a service account's? Activity through API tokens is logged under the account that owns the token, not under each person using the tool.
• If you use IP allowlisting, which needs a Premium or Enterprise plan, MCP requests must also come from an allowed address.
• Are you reviewing the audit log? Tool calls through the MCP server are logged as "Rovo MCP User Actions." Atlassian's MCP page lists this for all plans, but its audit log page says organization-level logs need Atlassian Guard or an Enterprise plan, so confirm the events actually appear in yours.

Step 7: Test before you widen access

Rovo includes agent evaluations. You upload a CSV of up to 100 test prompts, with expected answers if you have them, and run the agent against them. You can score response accuracy or resolution rate, or test by hand.

Use evaluations as the gate between a pilot group and a wider rollout. An agent that gives wrong answers to its own test set is not ready for more users, whatever its permissions look like.

Step 8: Write it down and set the cadence

The output of the review is a short register. One row per agent is enough:

Run the review on the same cadence as your human access review, and at least before each renewal. Add a trigger too: any new agent with write actions, or any new automation that calls one, gets reviewed before it goes live.

Where this fits in a wider rollout

An agent access review is one part of getting ready for agents. The other parts sit underneath it: whether every human account is explained, whether provisioning from your identity provider actually removes leavers, and whether your permission model is something you would defend in an audit. Atlas Bench, an Atlassian Platinum Solution Partner, covers those layers in its agent usage policy and guardrails work and in a fixed-scope agent readiness assessment. If you want the broader picture first, our Rovo agent governance guide covers the controls in more depth.

Want a second pair of eyes on your agents?

Atlas Bench runs this review as part of a fixed-scope agent readiness assessment. We check identity, permissions, and governance before any agent is switched on, and you get the findings, the ownership gaps, and the order to close them in.

Get an agent readiness assessment  Or talk to an architect

Questions we get

Do Rovo agents have their own permissions?

They can. When an agent is built, its creator chooses whether it uses the account of the person using it, with that person's permissions, or its own agent account, with access that admins, space admins, and content owners grant. With Atlassian Guard Premium, org admins can also manage an agent's app access and group membership in Atlassian Administration.

Can we stop some people from creating agents?

Yes. In Rovo Studio settings, you can limit agent creation to selected groups, up to 10, or to no users, which leaves it to Studio admins.

Can we restrict an agent to one team?

Not by group today. An owner can turn off open access and add named people as editors or managers. For agents that use the person's account, the stronger control is making sure each team's permissions are right, because the agent inherits them. For agents with their own account, keep the list of people who can use them short.

Do agents ask before they change something?

In chat, agents usually ask for confirmation before they run an action that changes data. In automation, agents can be set up to act without confirmation, which is why every rule that calls an agent needs an owner.

How often should we review agent access?

At least as often as your human access review, and before each renewal. Also review any new agent with write actions before it goes live.

Where does Atlas Bench start?

At the identity layer. If human accounts and groups are not explained, the agent review inherits every gap. Our readiness assessment checks identity, platform, and governance before any agent is switched on.