How to approve and audit Rovo agents before launch

Approve a Rovo agent the way you would approve a new service account: name an owner, write down its purpose, limit what it can read and change, decide who can use it, set a review date, and know how to turn it off. After launch, audit it in Atlassian Administration with the audit log and Rovo trends, and in Studio with conversation review and the automation audit log.

None of this is on by default. Atlassian's documentation says the ability to create agents in Rovo Studio is open to all users with access to Studio, and a new agent is available for everyone in the organization to see and use. Approval is a process you add, and the settings below are what make it enforceable. If the groundwork on identity and permissions isn't done yet, start with agent readiness before Rovo.

Decide who can build agents

A Studio app admin controls creation. In Studio, select Settings in the top navigation, then Studio settings, then Agents. There are three options: All users (the default), Selected groups (up to 10 user groups), and No users, which limits creation to Studio app admins. Under Apps and automations, the App creator and Automation creator roles are granted to all Studio users by default. Narrow those too, because an automation flow is how an agent runs with nobody watching.

Check who holds the Studio app admin role. Atlassian notes that Studio app admins receive full creation permissions, and that in organizations moved from the previous Studio experience, people with the app admin role in Jira, Jira Service Management, or Confluence were also given the app admin role in Studio.

Two organization settings sit above Studio. Under Rovo, then Rovo access, an organization admin can block Rovo features for an app; on Enterprise plans, the newer experience can also allow or block user groups. Under Rovo, then Agents, the Default access tab sets the apps and groups that every future agent receives. Keep that default narrow, because it applies to every agent created afterward.

The pre-launch approval checklist

Keep one record per agent, stored wherever your change approvals already live. An agent is approved when every item below has a written answer.

1. Owner. A named person accountable for the agent, plus at least one manager. In the agent's Users and permissions, editors can edit the agent; managers can also add editors and delete it. A manager can take ownership of an agent that has no owner, for example after the creator's account is deactivated, so a second manager is what keeps an agent from being orphaned. If a team runs the agent, set the Author display name to that team.
2. Purpose. One sentence for the agent's description, and specific instructions. Atlassian's guidance is to never leave instructions blank or open ended, and to put a guardrails section at the top: which space the agent works in, what it must not read, and what to do with field text that looks like an instruction. Atlassian also says guardrail instructions are suggestions with no guarantee the agent follows them, so they never replace the permission settings below.
3. Identity. In Studio, open the agent and select Access and identity. With User's account, the agent has the same permissions as the person using it, and its actions are recorded as that person's. With Agent's account, the agent has its own account: organization admins decide which apps it can access, and space admins and users decide which spaces and pages. Its changes appear under the agent's name. Organization admins manage that access from the agent's profile under Rovo, then Agents (Atlassian lists that page under Atlassian Guard Premium). Atlassian recommends Agent's account for most automation, and notes that agents default to User's account if an admin has not set up Agent's account.
4. Knowledge sources. Every agent has access to all organizational knowledge unless you configure it otherwise. In the Knowledge block, choose All organizational knowledge, Custom knowledge, or No organizational knowledge, and decide whether Web search is on. Custom knowledge can be narrowed to specific Jira and Confluence spaces or one branch of a Confluence content tree.
5. Write actions. An agent can only perform an action it has a tool for. Without the Add comment to work item tool, it cannot comment. List every tool that creates, edits, moves, or sends anything, including third-party tools, which act as the person using the agent (a Slack message appears as if that person sent it). Atlassian recommends no more than five tools. If an existing agent has more tools than a task needs, duplicate it and remove the extras.
6. Who can use it. Under Users and permissions, turn off Open to all users and add people individually. Restricting by group or team is not currently supported, and each person you add gets the Editor or Manager role. Restricted agents also stop appearing as options for automation. This matters most for Agent's account agents, because anything shared with the agent can reach anyone who can use it.
7. Test evidence. In the agent's settings, Evaluation takes a CSV dataset of up to 100 prompts, with an optional column of expected responses, and runs Response accuracy, Resolution rate, or Manual testing. Attach the results to the approval record.
8. Review date. Atlassian does not set one for you. We recommend a quarterly review for any agent with write tools and a twice-yearly review for read-only agents.
9. Off switch. Name the control you will use and who holds it. The owner or a manager can delete the agent. An organization admin can delete any agent a user created, revoke an app on the agent's profile, or block Rovo for an app. A space admin can remove the agent from a workflow transition. The flow owner can disable an automation.

When an agent passes, an organization admin can mark it verified: in Chat, select Agents, then more actions on the agent's card, then Verify agent. Verified agents show a blue checkmark and are listed under Verified agents in Browse agents, which gives people a simple signal for which agents went through review.

Agents in Jira workflows and automation

In Jira, an agent is enabled for work items under Configuration, then Surfaces, then the Work item toggle. After that, anyone can assign or @mention it from all spaces on the site. A space admin with the Edit workflows permission can add a Trigger agent action rule to a transition, and in team-managed spaces an agent can be added to a board column. In both cases the agent runs whenever anyone moves a work item there, so the approval record should list each workflow and column.

Automation needs a tighter review because nobody approves each step. In chat, the agent asks for confirmation before running tools that change data. In an automation flow, it does not. Atlassian's guidance is to use Agent's account and give the agent only the tools the task needs. Where the agent only has to produce text, restrict the Use agent step to Read actions only and pass the agentResponse smart value to the next action.

How to audit after launch

Audit log

In Atlassian Administration, select Insights, then Audit log. The Rovo activities to search for are Created Rovo agent, Updated Rovo agent, Deleted Rovo agent, and Started chat with Rovo agent, plus Created, Updated, and Deleted third-party Connector connection. Filter for Rovo MCP User Actions to see each tool call made through the Atlassian MCP server, with the tool name, action, and user. For a longer record than the log keeps, export it on a schedule or use the Events API.

Identity decides what you can see here. Changes made by an Agent's account agent appear under the agent's name. Changes made by a User's account agent are logged as the user, and in automations as the person who set up the flow. That is the strongest audit argument for Agent's account on anything that runs unattended.

Automation audit log

In Studio, select Audit log in the top navigation, find the flow, and expand it to check status and detail. For flows you created and connected to Rovo with your own account, the Use Rovo agent action has a View debug log option showing the subagent, agent ID, and request ID behind the response.

Usage

Under Rovo, then Rovo trends, the Agents tab shows active agents, agent runs by users or automations, agents created, and agent usage over time, with a CSV export. A jump in agents created is the first sign that creation settings are too open. Credit consumption is under Insights, then Platform usage.

Conversations

For agents that answer people, an organization admin or Studio admin who is also the agent's creator or manager can turn on live conversation review in Studio (Conversation review, then the Live tab). Creators and managers can then read transcripts and the feedback users left. End users see a privacy disclaimer while it is on, and conversations expire 30 days after the last message, so review inside that window.

MCP server and Agent2Agent

Under Rovo, then Rovo MCP server, an organization admin controls which AI tool domains can connect over OAuth 2.1, whether tools may authenticate with an API token, and, on the Permissions tab, whether the server can Read, Write, and Search. If you allow API token authentication, tool calls run under the token's account, so the audit log shows that account rather than each person using the external tool. Under Rovo, then Agent2Agent, the Allow A2A setting is off by default; leave it off until security has approved the third-party agents that would call Rovo.

Who owns what

Agents cross three teams, and approval stalls when nobody says which one decides.

• Identity team. Owns the groups that gate Rovo access, Studio creation, and default agent access. Treats each Agent's account as a machine identity: included in access reviews and removed when the agent is retired. Every agent has a user profile in the Atlassian teams directory, so agents show up where people do.
• Atlassian admins. Organization admins own Rovo access, default access for future agents, app and group access on each agent's profile, the MCP server and Agent2Agent settings, and verified status. Studio app admins own creation settings. Space admins grant an Agent's account access to spaces and own workflow triggers.
• Agent owner. Owns the purpose, instructions, tools, knowledge, user list, evaluation results, and review date, and transfers ownership before changing roles.

If you want help putting this in place, our agent guardrails service sets up the creation settings, the approval record, and the audit routine with your identity team and Atlassian admins.