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.
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.
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.
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:
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.
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.
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:
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.
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.
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:
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.
The output of the review is a short register. One row per agent is enough:
| Agent | Owner | Identity | Purpose | Apps | Writes? | Automation | Next review |
|---|---|---|---|---|---|---|---|
| Release notes drafter | Named person | User's account | Drafts notes from closed work items | Jira, Confluence | Creates pages | None | Next quarter |
| Request triage | Named person | Agent account | Suggests request types in JSM | Jira Service Management | Updates status | On new request | Next quarter |
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.
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.
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
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.
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.
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.
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.
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.
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.